| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
Replace calls to ctx->Driver.CompressedTextureSize with calls to
_mesa_format_image_size. The former always called the later.
|
