| Age | Commit message (Collapse) | Author |
|---|
|
Seems INDX_OFFSET doesn't work properly on some cards,
so change back to immediate mode indices. Seems to only
affect DRI1. Needs more investigation.
Rework and clean up the draw functions.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
|
|
Before, if we just called glXMakeCurrent() and didn't render anything we'd
still trigger a flushFrontBuffer() call.
Now only set the intel->front_buffer_dirty field at state validation time
just before we draw something.
NOTE: additional calls to intel_check_front_buffer_rendering() might be
needed if I missed some rendering paths.
|
|
|
|
|
|
|
|
|
|
This improves piglit quick.tests runtime from 19:33 minutes to 6:06 on
my GM45. It should also hide most of the A17 swizzling issues, though
they'll still exist when swapping occurs (which is the kernel's problem
either way).
|
|
|
|
|
|
Part of fixing bug #24355.
|
|
This fixes a regression in piglit's tfp test as of
11caea687e3f10ae12d33e44edf84635f73047dd. Additionally, set the texture
format for the RGB textures to MESA_FORMAT_XRGB8888 and support it in the
hw paths so that hopefully sw fallbacks involving TFP get better alpha
behavior.
The radeon drivers appear to need the same fix.
Bug #24803
|
|
|
|
This improves shadowtex since the component ordering
is at least correct now, but I'm not sure how to
deal with texturing from a depth surface yet due to
differences in depth and color tile layouts.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
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
|
