Age | Commit message (Collapse) | Author |
|
|
|
Until now falling back to software rasterizer worked only for TCL enabled cards.
For non TCL cards we used to plug our rendering functions in r300InitSwtcl, and we had never restored original functions for software rasterizer.
|
|
|
|
|
|
- move extensions init into seperate function
- move options handling into seperate function
- create new structure to hold options values
- use context->options.hw_tcl_enabled field instead of global hw_tcl_on and future_hw_tcl_on variables
|
|
Instead, stash the debug info under the handy debug flag.
Bug #20053
|
|
Bug #21691.
|
|
The _Enabled field isn't updated at the point that DrawBuffers is called,
and the Driver.Enable() function does the testing for stencil buffer
presence anyway.
bug #21608 for Radeon
|
|
The docs actually explain this, but not in a terribly clear manner.
This nearly fixes the piglit cubemap testcase, except that something's
going wrong with the nearest filtering at 2x2 sizes in the testcase.
Looks good by visual inspection, though.
Bug #21692
|
|
I don't have a testcase for this, but it seems clearly wrong.
|
|
Before, if the VP output something that is in the attributes coming into
the WM but which isn't used by the WM, then WM would end up reading subsequent
varyings from the wrong places. This was visible with a GLSL demo
using gl_PointSize in the VS and a varying in the WM, as point size is in
the VUE but not used by the WM. There is now a regression test in piglit,
glsl-unused-varying.
|
|
|
|
This comes from a radeon-rewrite fallback fix, but may also fix stencil
clear failure when the polygon winding mode is flipped.
|
|
With 1D textures, GL_TEXTURE_WRAP_T should be ignored (only
GL_TEXTURE_WRAP_S should be respected). But the i965 hardware
seems to follow the value of GL_TEXTURE_WRAP_T even when sampling
1D textures.
This fix forces GL_TEXTURE_WRAP_T to be GL_REPEAT whenever 1D
textures are used; this allows the texture to be sampled
correctly, avoiding "imaginary" border elements in the T direction.
This bug was demonstrated in the Piglit tex1d-2dborder test.
With this fix, that test passes.
|
|
One warning message:
drm_i915_getparam: -22
was still being sent to fprintf(). This causes all Piglit tests to fail,
even with MESA_DEBUG=0.
Using _mesa_warning() to emit the message allows the general Mesa controls
for messages like this to be applied.
|
|
|
|
Fixes potential texture object leaks.
|
|
In r*00SetTexBuffer2(), if the passed in text glx_texture_format
is GLX_TEXTURE_FORMAT_RGB_EXT, then we should use an RGB-only
texture format, even if the DRI buffer has four channels.
https://bugs.freedesktop.org/show_bug.cgi?id=21609
|
|
When a NULL value of pixels is passed to TexImage2D and
SGIS_generate_mipmap is enabled, don't try to generate the
mipmap tree: we don't have data yet for the texture and will
crash.
https://bugs.freedesktop.org/show_bug.cgi?id=21648
|
|
In r300SetTexBuffer2(), if the passed in text glx_texture_format
is GLX_TEXTURE_FORMAT_RGB_EXT, then we should use an RGB-only
texture format, even if the DRI buffer has four channels.
https://bugs.freedesktop.org/show_bug.cgi?id=21609
|
|
ctx->Stencil._Enabled is derived state and not immediately updated
when the stencil parameters are changed; we need to make sure that
it is up-to-date before accessing it.
https://bugs.freedesktop.org/show_bug.cgi?id=21608
|
|
Remove an eigth-pixel offset of the viewport inherited from
R100 code. This seems not to be necessary and causes blurring
when sampling textures 1:1.
https://bugs.freedesktop.org/show_bug.cgi?id=20340
|
|
|
|
Fixes segfault in context tear-down when glClear was never called.
|
|
No special driver changes are needed for this extension.
|
|
Conflicts:
src/mesa/main/arrayobj.c
src/mesa/main/arrayobj.h
src/mesa/main/context.c
|
|
gl_array_object encapsulates a set of vertex arrays (see the
GL_APPLE_vertex_array_object extension).
Create a private gl_array_object for drawing the quad for intel_clear_tris()
so we don't have to worry about the user's vertex array state.
This fixes the no-op glClear bug #21638 and removes the need to call
_mesa_PushClientAttrib() and _mesa_PopClientAttrib().
|
|
Not 100% sure this is right, but the invalid assertion is fixed...
|
|
|
|
|
|
|
|
This looks to be a win of a few percent in cairogears with new vbo code,
thanks to not polluting caches.
|
|
|
|
This was broken with last merge see 62043b27575c378c027251316421e4699f461108
for explanations
|
|
This was broken with last merge see f48473e42511f8d37a239a07f791bc0a87209e5b
for explanations.
|
|
Basically the same as 43d9020ff1e975e7f4f9480d9ef24f0b9fb2141f for intel. Bug 21688.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
For non-stereo visuals, which is all we support, we treat
GL_FRONT_LEFT as GL_FRONT. However, they are technically different,
and they have different enum values. Test for either one to determine
if we're in front-buffer rendering mode.
This fix was suggested by Pierre Willenbrock.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2085cf24628be7cd297ab0f9ef5ce02bd5a006e2)
|
|
Fixes failed assertion in progs/glsl/twoside.c (but still wrong rendering).
|
|
|
|
Conflicts:
src/mesa/drivers/dri/r200/r200_state.c
src/mesa/drivers/dri/r300/r300_context.h
src/mesa/drivers/dri/r300/r300_fragprog.c
src/mesa/drivers/dri/r300/r300_state.c
src/mesa/drivers/dri/r300/r300_texmem.c
src/mesa/drivers/dri/r300/r300_texstate.c
src/mesa/drivers/dri/r300/r500_fragprog.c
src/mesa/drivers/dri/radeon/radeon_screen.c
src/mesa/drivers/dri/radeon/radeon_state.c
|
|
|
|
Looking for memory leaks that were causing crashes in my environment
in a situation where valgrind would not work, I ended up improving
the i965 debug traces so I could better see where the memory was
being allocated and where it was going, in the regions and miptrees
code, and in the state caches. These traces were specific enough
that external scripts could determine what elements were not being
released, and where the memory leaks were.
I also ended up creating my own backtrace code in intel_regions.c,
to determine exactly where regions were being allocated and for what,
since valgrind wasn't working. Because it was useful, I left it in,
but disabled and compiled out. It can be activated by changing a flag
at the top of the file.
|
|
A temporary change to the intelMakeCurrent() function to make
it work with frame buffer objects causes the static regions
associated with the context (the front_region, back_region,
and depth_region) to take on an additional reference, with
no corresponding release. This causes a memory leak if a
program repeatedly creates and destroys contexts.
The fix is the corresponding hack, to unreference these
regions when the context is deleted, but only if the
framebuffer objects are still present and the same
regions are still referenced within.
Both sets of code have comment blocks referring to each
other.
|
|
When out of memory (in at least one case, triggered by a longrunning
memory leak), this code will segfault and crash. By checking for the
out-of-memory condition, the system can continue, and will report
the out-of-memory error later, a much preferable outcome.
|
|
In addition to being HW accelerated, it avoids the incorrect
(black) rendering of the mipmaps that SW was doing in fbo-generatemipmap.
Improves the performance of the mipmap generation and drawing in
fbo-generatemipmap by 30%.
|
|
Make this be its own function for setup/teardown of the binding of these
texcoords. No performance difference in the engine demo (I just felt dirty
not using a VBO for this), and I think it should be more resilient to
interference from current GL state.
|
|
|
|
They seem to be used for something else and using them for shader temps
seems to lead to GPU lock-ups.
Call _mesa_warning() when we run out of temps.
Also, clean up some debug code.
|
|
|
|
Fixes piglit/texdepth
|