Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
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.
|
|
In addition, this pass fixes non-native swizzles.
|
|
This new generic transform replaces "special" instructions by more generic
variants. Hopefully, we will be able to share this code between r300 and r500.
|
|
Yes, I know it's massive. Imagine how I felt, auditing 3000 lines of code.
|
|
The idea/hope is that radeon_program will serve as an intermediate
representation for r3xx up to r6xx fragment and vertex programs.
Right now, it is nothing more than a simplistic wrapper around Mesa's
prog_instruction, together with the notion of clauses, taken from r6xx docs.
The clauses will eventually be used to represent the nodes that are used in
r300 family fragment programs.
|
|
|
|
|
|
This reverts commit 0aa998b2ab6fdfe139b54de9868e2383440685d0.
|
|
|
|
|
|
|
|
specific.
|
|
|
|
This was okayed by Jerome Glisse and Keith Whitwell on the dri-devel IRC channel
and list, respectively.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Makes all three drivers use the same screen structure and setup code, with a
few ifdefs for the separate compilation to deal with symbols not being
available to all drivers and the fact that we have no mechanism for dealing
with different config options for different chip families in the same driver.
These issues should be dealt with later.
- Introduces IS_R[123]00_CLASS(radeonScreenPtr) macro for code for taking
different paths depending on the general class of chipset.
- Adds many new R300-class PCI IDs, though not all those listed in
radeon_driver.c.
|
|
Changes to current operation:
-Elts are no longer converted to 16-bit format
-Cube maps
|
|
|
|
destroy __GLcontextModes structures. This eliminates the need for DRI
drivers to ever link with glcontextmodes.c.
|
|
for others, and being cleaner with types in fragment/vertex program structures.
One warning in r300_shader.c is still concerning.
|
|
generation in Mesa. Requires most recent Mesa cvs to work correctly.
Swizzle code is possibly slow/buggy and will probably be replaced.
Old behaviour can be controlled by a #define in r300_context.h, if
no-one minds I'll remove the old code later on.
Also, disabled cube map extension. AFAIK We don't support it yet,
and it causes issues with UT2004.
|
|
didnt want to build anymore.
|
|
|
|
|
|
|
|
tuxracer should render correctly. Immediate path was left enabled.
|
|
vertex buffer mode worked by accident.
Fix alu_offset in SINGLE_TEXTURE_PIPELINE.
|
|
|
|
Rework *vb* function to not use AOS_ARRAY structure, but rather work directly with r300->state.aos.
Remove references to r300_lib.h and r300_lib.c
Remove r300_lib.[c,h].
|
|
Hook it up, so lesson06 displays red colored textures.
|
|
|
|
- Install custom (though inactive) pipeline
- Track depth test and culling state in hardware registers
|
|
- Color buffer clear is accelerated, but flickers (possibly caused by a
recent DDX or Mesa change or bad merge)
- Everything else uses software fallback rendering
- There should be no clipping-related artifacts with the
sw-clipspan-fixes.patch against Mesa (posted on dri-devel)
- Multiple clients should be rock solid with a DDX patch that is soon to
come (soon = within the next hour or so)
|
|
|