| Age | Commit message (Collapse) | Author |
|---|
|
World position is calculated in the vertex shader and passed to the
fragment shader via an unused texcoord.
|
|
Makes the vertex program output from the fragment input.
It makes the driver capable of catching output-input mismatches safely. Primarily
based on some of Aapo Tahkola's code.
|
|
need to check for this condition before the later field has been computed.
Fixes logicop bug #8860.
|
|
|
|
Use the _mesa_little_endian helper function insted
of the MESA_BIG_ENDIAN flag. There is still place
using this flag but we need to find how to submit
16bits elements on big endian computer.
|
|
and fixing a couple of warning. More cleanup and shuffle
to come. I have tested this change they might broke things
especialy with r300_texstate.c change (format_x doesn't
seems to be use at all by r300).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ctx->_MaintainTnlProgram is set
|
|
|
|
|
|
|
|
|
|
- use macros to access and modify render inputs bit-field;
- un-alias generic vertex attributes for ARB vertex calls;
- use MAX_VERTEX_PROGRAM_ATTRIBS (NV code) or MAX_VERTEX_ATTRIBS
(ARB code) in place of VERT_ATTRIB_MAX;
- define VERT_ATTRIB_GENERIC0..15 for un-aliased vertex
attributes for ARB_vertex_shader;
- fix generic attribute index range check in arbprogparse.c;
- interface GLSL varyings between vertex and fragment shader;
- use 64-bit optimised bitset (bitset.h) for render inputs;
|
|
|
|
|
|
(reported by Jim Duchek). Fix some potential problems with strict-aliasing with r200 and radeon drivers in *UpdateViewportOffset, *PolygonOffset and *UpdateWindow functions (some compiler warnings about strict-aliasing remain in the codegen vertex code, and there may be more problems unnoticed by the compiler).
|
|
texrect and lighting needs was broken because of this.
|
|
|
|
|
|
|
|
known by ddx (probably secondary ids, non-existant cards and similar). Add rs400 to the family enum, and configure the rv410 like a 2 quad chip (?)
|
|
|
|
|
|
|
|
|
|
|
|
Lots of changes, and fixes for some badness on my behalf.
1. Disposable data used during fp compile is now per-context,
rather than per-program to save memory.
2. Track usage of INPUT/TEMP registers from Mesa program, free
them when no longer required so the hw temps can be re-used.
3. Changed LAST_NODE to OUTPUT_COLOR (see r300_reg.h)
4. Implemented remaining ARB_f_p instructions, with the exception
of the trig/LIT opcodes.
5. Treat ZERO/ONE swizzles the same way as other native swizzles.
6. emit_arith changes, basically a complete re-write. Should
produce cleaner instructions, but no real functional changes.
internal reg -> hw reg routines shared with emit_tex. A bit
messy still.
|
|
|
|
|
|
|
|
movement and 2d windows flashing on top of 3d windows. This problem was previously shadowed by r300ResetHwState as it gets called frequently.
|
|
|
|
sw tcl
|
|
Instructions, InputsRead, OutputsWritten, and Parameters.
Also, added debug functions: _mesa_print_instruction(),
_mesa_print_program_parameters() and revamp _mesa_print_program().
|
|
- 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.
|
|
|
|
-Use 16-bit elts in vtxfmt_a path if possible
-Optimize VSF param uploading
-return in r300DepthMask looks suspicious, use r300Enable instead
-Dont use r300ResetHwState in invalidate state(disabled, missing hooks, possible instabilities)
|
|
|
|
|
|
|
|
Changes to current operation:
-Elts are no longer converted to 16-bit format
-Cube maps
|
|
|
|
ctx->Driver.Stencil*Separate() functions.
|
|
for others, and being cleaner with types in fragment/vertex program structures.
One warning in r300_shader.c is still concerning.
|
|
either with software or hardware rendering.
|
