Age | Commit message (Collapse) | Author |
|
also seems we can use INDX_OFFSET if start != 0
|
|
We weren't choosing the right XRGB span functions for reading the
framebuffer. XRGB formats still aren't turned on yet though.
|
|
* Add an extra argument to configure which allows for specifying
different DRI driver search paths to libGL (FDO #24766)
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
Pass a gl_format to intel_create_renderbuffer() instead of GLenum.
Add cases for MESA_FORMAT_XRGB8888 textures and renderbuffers.
However, we don't yet create any renderbuffers or textures with that
format. It seems the default alpha value is zero instead of one.
Need to investigate that first.
|
|
|
|
|
|
This has been lifted into core Mesa where it can be used for all drivers
that use the _mesa_get_teximage() fallback for ctx->Driver.GetTexImage().
|
|
|
|
Shrinks size of key to 8 bytes from 12.
Note that progs/demos/spriteblast.c is still broken.
|
|
GLushort is big enough for the swizzle and origin fields.
The key could probably be made smaller still by re-ordering things.
I'll hold off on that until after the outputswritten64 branch is merged.
The key will get a little larger again with the GLbitfield64 fields.
|
|
Fixes piglit tex1d-2dborder test.
|
|
Previously, S8_Z24 depth textures would always be treated as intensity.
Fixes piglit depth-tex-modes.
|
|
If the fragment shader doesn't use FRAG_ATTRIB_WPOS (gl_FragCoord) we
don't need to worry about the window size and origin in
brw_wm_populate_key().
This avoids re-generating the i965 shader code when a window is resized.
Issue spotted by Keith Whitwell.
|
|
i965 might support more than 4 color draw buffers. But if not, this protects
from breakage if the Mesa limit is raised.
|
|
|
|
Put the state that we care about in the hash key.
Issue spotted by Keith Whitwell.
|
|
This makes things a bit easier to remember/understand.
|
|
|
|
This gets us expected behavior for clamping between mipmap levels, and
avoids relayout of textures for doing clamping.
Fixes piglit lodclamp-between.
|
|
|
|
|
|
If a backwards glDepthRange was supplied (as with the old Quake no-z-clearing
hack), the hardware would have always clamped because we weren't clamping to
the min of near/far and the max of near/far. Also, we shouldn't be clamping
to near/far at all when not in depth clamp mode (this usually didn't matter
since near/far are usually the same as the 0.0, 1.0 clamping you do for
fixed-point depth).
This should fix funny depth issues in PlaneShift, and fixes piglit
depth-clamp-range
|
|
We only need it when drawing to the front buffer, which we never do for
DRI2. No significant performance difference, but the flush is definitely
gone from the end of every batchbuffer.
|
|
|
|
|
|
|
|
And update error message.
|
|
These were removed from master but a few files came back from the
texformat-rework branch.
|
|
Conflicts:
src/mesa/drivers/dri/radeon/radeon_fbo.c
src/mesa/drivers/dri/s3v/s3v_tex.c
src/mesa/drivers/dri/s3v/s3v_xmesa.c
src/mesa/drivers/dri/trident/trident_context.c
src/mesa/main/debug.c
src/mesa/main/mipmap.c
src/mesa/main/texformat.c
src/mesa/main/texgetimage.c
|
|
|
|
Based on initial patch from Stephan Schmid <stephan_2303@gmx.de>.
Basic idea is to dump the zpass count at the start and end of the query
and subtract to get the total number of visible fragments. HW writes
alternating qwords for up to 4 DBs. On the first pass, we start at
buffer address + 0; on the second pass, we start at buffer address + 8
(bytes). The resulting buffer at the end of the query looks like:
qw[0]: db0 start
qw[1]: db0 end
...
qw[6]: db3 start
qw[7]: db3 end
The MSB of each qword is the valid bit and the lower 63 bits are
the zpass count for that DB.
OQ on RV740 is disabled at the moment as it only seems to report
results for half of its DBs. This needs further investigation.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Conflicts:
src/mesa/shader/lex.yy.c
src/mesa/shader/program_lexer.l
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Bug #24435
(cherry picked from commit d56125a298106d81e10674f1c4b3b43b51a5139d)
|
|
This fixes the second part of bug 23552.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use src->draw_offset intead of zero. Zero usually worked, except when
the src renderbuffer is actually a texture mipmap level higher than zero.
Fixes progs/test/blitfb.c test.
|
|
Bug #24734.
|
|
|
|
This reverts commit 8810b8f67135185d1044746bb861fe2ff997626c.
It turns out the i965 driver uses the intel->Fallback field as a boolean,
not as a bitmask. The intelFallback() function is a no-op in the i965
driver. It would have been nice if there were some comments about this.
I'll fix that next...
|
|
Need to push texture state and polygon state too.
Fixes rendering glitches seen in progs/demos/engine when changing
the rendering mode (wireframe, texture modes).
This makes bitmap rendering a little slower, unfortunately.
|
|
Use src->draw_offset intead of zero. Zero usually worked, except when
the src renderbuffer is actually a texture mipmap level higher than zero.
Fixes progs/test/blitfb.c test.
|
|
Bug #24734.
|