- move vertex program related functions to r300_vertprog.c
- use _mesa_bitcount instead of self-made bit_count function
- remove duplicated field in r300_vertex_shader_fragment.body union
- rename r300_vertex_shader_fragment to r300_vertex_shader_hw_code
- rename r300_vertex_program field native to error
- remove unnecessary r300_vertex_shader_state structure
- remove unused r300_vertex_program and r300_vertex_program_cont fields
- remove disabled code
- remove unnecessary r300TranslateFragmentShader call from r300UpdateShaderStates (it is already called in r300UpdateShaders)
- remove unnecessary null ptr checks
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
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
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.
The current texture for any particular texture unit is given an additional
reference in update_texture_state(); but if the context is closed before
that texture can be released (which is quite frequent in normal use, unless
a program unbinds and deletes the texture and renders without it to force
a call to update_texture_state(), the memory is lost.
This affects general Mesa; but the i965 is particularly affected because
it allocates a considerable amount of additional memory for each allocated
texture.
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.
