Age | Commit message (Collapse) | Author |
|
we now get texrect + trivial textures working
|
|
|
|
|
|
|
|
If DRI2 is enabled then switch cmd assembly to directly build
hw packet.
|
|
This abstract memory management and command stream building so we
can use different backend either legacy one which use old pathway
or a new one like with a new memory manager. This works was done by :
Nicolai Haehnle
Dave Airlie
Jerome Glisse
|
|
Makefile.template
|
|
Is there some kind of git hook we could use to keep me from committing
after like 10PM or so?
|
|
|
|
This uses fog HW instead of fragment programs.
If it breaks you, let me know!
|
|
There are 6 subpixel units per pixel, not 16.
|
|
|
|
Share almost all code with r500_fragprog now.
This also fixes Piglit's texrect-many test, which means that the compiz
bicubic plugin should work with hardware acceleration now.
|
|
based on info from hw team
|
|
|
|
|
|
This isn't complete yet. It does cover the two most common usage cases,
though, and at least the third one (POINT_DISTANCE_ATTENUATION) is possible,
so I'll do that later.
|
|
|
|
. There is both a per-texture unit and a per-texture object (at least for
OpenGL 1.4); this should now be supported properly.
. The LOD bias calculation in r300_state has been simplified and corrected
(need to multiply by 32 instead of 31, and ensure clamping)
. do not clamp LOD bias in TexEnv, as that behaviour conflicts with what
the spec says
. set Const.MaxTextureLodBias properly
. remove the no_neg_lod_bias property; if somebody can explain what
it's good for, we can add it back in, but according to Google, nobody
seems to use it
. removed some dead code and unused variables
|
|
Okay, this time it's for real, and for good. This should be a perma-fix.
|
|
|
|
|
|
Per airlied's suggestion.
|
|
Yes, I know it's massive. Imagine how I felt, auditing 3000 lines of code.
|
|
|
|
Refactor so that r300_pfs_compile_state "owns"/holds a pointer to
r300_fragment_program instead of the other way round. This is more natural from
an object orientation point of view.
Move the compiled hardware state into r300_fragment_program_code, in
anticipation of on-the-fly program recompilation based on external OpenGL
state.
|
|
|
|
This also fixes a bug with Zfunc set to GL_NEVER in glean/paths.
|
|
This commit should not affect the functionality at all, just cleanup
some of the original texture filter guesswork using information from
the register documentation.
|
|
Thanks to nh for the r3xx version.
|
|
Setup fg_depth_src for depth writing programs and change early Z (ztop)
semantics.
Piglit's version of glean/fragprog test passes now (unlike Glean, its
dependency on EXT_fog_coord, which we don't support, is optional).
R3xx only at the moment, but should be straightforward to adapt to R5xx
(I don't own an R5xx, and I don't want to break anything.)
|
|
The KIL instruction only works if at least one texture unit is enabled
in hardware.
Texture instructions do not support swizzles, negations etc. natively,
so we now emit an explicit swizzling etc. operation when the texture coordinate
requires it.
This fixes the Piglit fp-kil test.
|
|
This fixes transparency issues on r500 by enabling
backwards compatibility with the r300 alpha compare value.
|
|
Bring in all the r500 3D code into master should be as stable as the r300
code it is landing on top off.
Conflicts:
src/mesa/drivers/dri/r300/r300_reg.h
src/mesa/drivers/dri/r300/r300_state.c
src/mesa/drivers/dri/radeon/radeon_screen.c
|
|
|
|
|
|
Also remove some unused bits of the r500 fragprog struct
|
|
|
|
Not sure if this is a good or bad plan, it certainly doesn't make things worse here.
|
|
|
|
|
|
|
|
So this appears to be my BUG. damn it to hell.
also fix sec color to be more like spec says.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|