Age | Commit message (Collapse) | Author |
|
Passes piglit pbo-read-argb8888, and doesn't otherwise regress quick.tests.
|
|
Conflicts:
src/mesa/drivers/dri/r600/r700_assembler.c
src/mesa/main/version.h
|
|
buffers."
This reverts commit 4598942b1b88a2a7d5af7febae7e79eedf00e385.
XRGB8888 doesn't work as intended. Revert this for now, and we'll revisit it
for 7.8 or something.
|
|
|
|
Conflicts:
src/mesa/main/version.h
|
|
|
|
i830 does not (and cannot!) support the any of the non-default
GL_POINT_SPRITE_R_MODE_NV settings. i915 and i965 could, but
currently do not. In both cases it would require mucking about with
the fragment shader.
|
|
bcbfda71b03303d3f008a6f3cf8cb7d9667bf8d2 left out many blit paths.
This fixes up more of them to get Blender to work again.
Bug #25030.
|
|
Conflicts:
src/gallium/drivers/svga/svga_screen_texture.c
src/gallium/state_trackers/xorg/xorg_composite.c
src/gallium/state_trackers/xorg/xorg_exa.c
src/gallium/state_trackers/xorg/xorg_renderer.c
src/gallium/state_trackers/xorg/xorg_xv.c
src/mesa/main/texgetimage.c
src/mesa/main/version.h
|
|
Conflicts:
progs/util/shaderutil.c
src/mesa/drivers/dri/r600/r600_context.c
src/mesa/main/version.h
|
|
This fixes an assertion failure in _mesa_MapBufferARB.
Fixes bugzilla #25253.
|
|
|
|
|
|
This really isn't supported at this point. GEM's been in the kernel for
a year, and the fake bufmgr never really worked.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Saves CPU time, resulting in a 2.5% FPS win on ETQW.
|
|
This cuts a massive number of waits in ET:QW, which uses a VBO ringbuffer.
Unfortunately it doesn't BufferData when wrapping back to 0, so we can't
be clever with tracking what's been initialized.
|
|
Thanks to Chia-I Wu's changes to the extension function
infrastructure, we no longer have to tell the loader which extensions
the driver might enable. This means that intelInitExtensions will
never be called with a NULL context pointer. Remove all the NULL checks.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
|
|
|
|
I fixed it properly as of 7216679c1998b49ff5b08e6b43f8d5779415bf54.
|
|
Otherwise, we could lose track of rendering to that image, which could
easily happen during mipmap generation.
|
|
|
|
|
|
|
|
|
|
This should do all the things that MI_FLUSH did, but it can be pipelined
so that further rendering isn't blocked on the flush completion unless
necessary.
|
|
gen2/3/4 are easier to say than "8xx, 915-945/g33/pineview, 965/g45/misc",
and compares on generation are often easier than stringing together a bunch
of chipset checks.
|
|
fixes bug 24953.
|
|
|
|
|
|
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).
|
|
|
|
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
|
|
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().
|
|
This gets us expected behavior for clamping between mipmap levels, and
avoids relayout of textures for doing clamping.
Fixes piglit lodclamp-between.
|
|
|
|
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.
|
|
|
|
|