Age | Commit message (Collapse) | Author |
|
Fixes
glxinfo: main/renderbuffer.c:2159: _mesa_reference_renderbuffer: Assertion
`oldRb->Magic == 0xaabbccdd' failed.
|
|
Conflicts:
src/mesa/drivers/dri/r300/r300_context.c
src/mesa/drivers/dri/r300/r300_texstate.c
|
|
This still need some work to actually report somethings reasonable
if no memory manager is available.
|
|
|
|
|
|
|
|
See sourceforge bug #2793846.
|
|
When we render to a depth/stencil texture there are stencil bits.
|
|
|
|
|
|
|
|
Again, thanks to agd5f.
|
|
It appears that that area of code "just works" much like classic Mesa's
version, so might as well not waste scrollback on it.
|
|
|
|
This makes glxgears draw properly with SW TCL.
|
|
Conflicts:
Makefile
src/mesa/main/version.h
|
|
The stride needs to be in texels, not bytes.
|
|
|
|
|
|
We were passing a GL texture target instead of a pipe_texture_target enum.
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21053 .
|
|
|
|
Before you get all excited, this is *not* to be construed as actual support
for GLSL shaders. The GL version is still 1.3, and stuff still sucks. Just
flicking it on so that it can be tested and developed a bit easier.
|
|
Oh, look, GLSL instructions. I wonder what I'll do next.
|
|
Oh, look, it's more features. :3
|
|
HW trig does a premultiply by 2pi, where Mesa does another premultiply by pi.
This is a problem.
|
|
|
|
See the previous commit for an explanation. This is just all the support code
for GB_TILE_CONFIG.
|
|
This accompanies kernel patches that make GB_TILE_CONFIG's various members
completely controlled in DRM.
GB_TILE_CONFIG has the following controls:
- The number of GB (pixel) pipes enabled
- The size and style of tiling
- Subpixel precision (either 1/12 or 1/16)
Per airlied and glisse, userspace and kernel will now agree (always) on
a subpixel precision of 1/12, and tiling will always be kernel-controlled.
|
|
GA_ENHANCE is now the kernel's problem.
|
|
Lops work fine as long as HW TCL is off. (I think I know why.)
|
|
Per agd5f.
|
|
Makes the last three commits suck much less. :3
|
|
Should work, but doesn't. Hm.
|
|
Those parts are nearly solid compared to the shaders.
|
|
|
|
Odds are good that we'll die later anyway, so we might as well do it before
we start dancing on random memory.
|
|
Even though we *can* render 10,000-pixel-wide lines, let's not advertise it.
|
|
Anisotropic filtering should work, and OQ is broken.
|
|
Compile-tested only, sorry.
|
|
|
|
BEGIN/END_CS pair, a few asserts, and a slightly more correct VTE setup.
|
|
Drivers can just keep track of whether they are within a query
by monitoring the begin/end query callbacks. The flag adds no
information beyond that.
Only softpipe was examining this flag -- it has been fixed up
and retested with demos/arbocclude.
|
|
- 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
|
|
|
|
Be consistent with function naming: use Setup/Emit names for functions that modify hardware state
|
|
|
|
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.
|