Age | Commit message (Collapse) | Author |
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Aim is to build as little state as possible in draw functions.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=32070
|
|
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
If querying the default/window-system FBO's attachment type, return
GL_FRAMEBUFFER_DEFAULT (per the GL_ARB_framebuffer_object spec).
See http://bugs.freedesktop.org/show_bug.cgi?id=31947
NOTE: This is a candidate for the 7.9 branch.
|
|
Return 0 instead of generating an error.
See http://bugs.freedesktop.org/show_bug.cgi?id=30993
Note that piglit fbo-getframebufferattachmentparameter-01 still does
not pass. But Mesa behaves the same as the NVIDIA driver in this case.
Perhaps the test is incorrect.
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
|
|
It was done in path-to-polygon conversion. That meant that the
results were invalidated when the transformation was modified, and CPU
had to recreate the vertex buffer with new vertices. It could be a
performance hit for apps that animate.
|
|
|
|
|
|
|
|
|
|
gl_FragCoord.y needs to be flipped upside down if a FBO is bound.
This fixes:
- piglit/fbo-fragcoord
- https://bugs.freedesktop.org/show_bug.cgi?id=29420
Here I add a new program state STATE_FB_WPOS_Y_TRANSFORM, which is set based
on whether a FBO is bound. The state contains a pair of transformations.
It can be either (XY=identity, ZW=transformY) if a FBO is bound,
or (XY=transformY, ZW=identity) otherwise, where identity = (1, 0),
transformY = (-1, height-1).
A classic driver (or st/mesa) may, based on some other state, choose whether
to use XY or ZW, thus negate the conditional "if (is a FBO bound) ...".
The reason for this is that a Gallium driver is allowed to only support WPOS
relative to either the lower left or the upper left corner, so we must flip
the Y axis accordingly again. (the "invert" parameter in emit_wpos_inversion)
NOTE: This is a candidate for the 7.9 branch.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
r600g might need something like that as well. This speeds up constant buffer
upload a bit.
|
|
Small perf improvement in ipers.
radeon_drm_get_cs_handle is exactly what this commit tries to avoid
in every write_reloc.
|
|
The field was redundant. Use the gallivm->builder value instead.
|
|
|
|
|
|
|
|
The other drivers need to be updated to do this, too.
|
|
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e.g. st_readpixels is trying to alloca() an huge ammount of memory from
the stack.
|
|
|
|
Right fix is probably stop C-preprocessor abuse and stick 100% with
scripted code generation.
|
|
Fixes more complaints by oglconform.
|
|
MAX_DRAW_BUFFERS is 8, so allow all 8 GL_DRAW_BUFFER# to be retrieved.
Fixes complaints by oglconform.
|
|
Fixes glsl-array-uniform.
|
|
Fixes nasty bug where some parts of the code didn't define WIN32_THREADS
and were using the integer mutex implementation, causing even confusion
to the debuggers.
And there is little interest of other thread implemenation on Win32
besides Win32 threads.
|
|
|
|
This allows 16K x 16K 2D textures, for example, but we don't want to
allow that for 3D textures. The new gl_constants::MaxTextureMBytes
field is used to prevent allocating too large of texture image.
This allows a 16K x 32 x 32 3D texture, for example, but prevents 16K^3.
Drivers can override this limit. The default is currently 1GB.
Apps should use the proxy texture mechanism to determine the actual
max texture size.
|
|
It was a no-op because all swizzles are native there.
|
|
To prevent a dangling pointer dereference.
|
|
|
|
|
|
|
|
|
|
Broken since 4c7001462607e6e99e474d6271dd481d3f8f201c.
|
|
|