Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
- 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
|
|
|
|
|
|
According to r300_reg.h from radeon drm module 0x4f30 is ZB_ZMASK_OFFSET.
Also cleanup as trailing whitespaces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- remove unused fields
- remove unused defines and macros
- flatten one structure
|
|
Conflicts:
src/mesa/drivers/dri/r200/r200_tex.c
src/mesa/drivers/dri/r300/r300_cmdbuf.c
src/mesa/drivers/dri/r300/r300_context.h
src/mesa/drivers/dri/r300/r300_swtcl.c
src/mesa/drivers/dri/r300/r300_tex.c
src/mesa/drivers/dri/r300/r300_texmem.c
src/mesa/drivers/dri/r300/r300_texstate.c
src/mesa/drivers/dri/radeon/radeon_tex.c
|
|
- remove unused variables
- silence compiler warnings
- fix twosided lighting
- fix point attenuation
- unify indentation
|
|
Context destruction was nearly the same over all the drivers,
so collapse it down.
|
|
Since core Mesa MAX_TEXTURE_LEVELS was bumped, we were incorrectly advertising
a maximum texture size of 4096 on older chips, causing corrupted menu text in
Extreme Tux Racer or Armagetron.
Also make sure our texture image array can actually hold all the mipmap levels
we support...
|
|
Flush the VAP the first time for each state atom we upload new
VAP data
|
|
|
|
|
|
This merges lots of the hw state atom emission and firevertices code.
it also removes a lot of the extra radeon crap from r300
and merge scissor
|
|
|
|
this gets back a lot of the lots speed in gears on r500 at least
I also fixed the legacy bufmgr to deal when the dma space fills up
|
|
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
|
|
|
|
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.
|
|
Use an abstracted instruction scheduling and register allocation algorithm
that we will be able to share with r300_fragprog.
Unlike the original emit code, this code tries to pair instructions that
only use the RGB part of the ALU with instructions that only use the alpha
part. However, the pairing algorithm still has some shortcomings;
for example, it doesn't generate optimal code for the emulation of LIT.
|
|
|
|
. 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
|
|
|
|
tests/bug_3195 doesn't render right, but at least it doesn't segfault this way.
|
|
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.
|
|
r500 code still used r300_pfs_compile_state, which contains some fields that
really only make sense on r3xx type hardware. In order to allow both fragprog
implementations to go forward without disturbing each other, I've pushed this
structure down into the respective r[3|5]00_fragprog.c
|