| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
| |
| |
| |
| |
| | |
Call the ctx->Driver.ChooseTextureFormat() function from core Mesa's
_mesa_[Copy]TexImage functions instead of in the driver functions.
One less thing for drivers to do.
|
| | |
|
| |
| |
| |
| | |
And fix incorrect first parameter.
|
| |
| |
| |
| | |
Use _mesa_format_image_size() instead.
|
| |
| |
| |
| | |
It always just called _mesa_compressed_texture_size() anyway.
|
| |
| |
| |
| |
| | |
Replace calls to ctx->Driver.CompressedTextureSize with calls to
_mesa_format_image_size. The former always called the later.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Now pass a specific MESA_FORMAT_x token to indicate the renderbuffer's
format. This is better than passing a GLenum and having to guess the
specific format.
I'm unable to test all the drivers, but any issues should be easy to fix.
|