Michał Król wrote:
On 07/04/06, Brian Paul <[EMAIL PROTECTED]> wrote:
Before we get to that point, I'd like to reconsider a few things in
the code. Specifically, the way the tnl and swrast modules interface
in terms of vertex attributes. The span_arrays struct is getting
pretty big (over 800KB now) and the s_tritemp.h code is becoming
unwieldy. There's got to be a better way of handling all the
interpolants and use less memory.
The GLSL vertex attributes cannot alias with conventional attributes.
Right. That's not what I meant though.
It seems to me that generic (varying) interpolants, texcoords, fog
coord, colors, etc. could all be handled with the same code, rather
than a separate #ifdef for each type of attribute.
It would take some effort to do though because the attributes aren't
all the same:
- perspective correction?
- float vs. int/fixed-pt interpolation
- 1, 3 or 4 components per attributes
- clamping?
It's kind of a mess.
In the TNL module we used to treat all the vertex attributes with
special code (i.e. colors, normals, texcoord, etc). When I
implemented vertex programs I was able to replace a lot of specialized
code with generic attribute code (i.e. attrib[0], attrib[1], etc).
It would be nice to do that in the swrast code.
This makes a total count of 32 vertex attribute vectors.
The same apply to varyings, they cannot alias with texcoords.
I can only cut in half the fat by tightly packing varyings.
This gives 500K of varyings for 4096 viewport width.
When I started working with tnl to swrast interface I falsely
concluded, by quick look at the structures, that number of vertex attrib
slots must be equal to number of fragment attrib (varying) slots. Funny.
I suspect there can be an issue regarding vertex attrib aliasing in NV_vp.
I can be wrong, but some code assumes VERT_ATTRIB_MAX to be always
equal to MAX_VERTEX_PROGRAM_ATTRIBS. And now, when
VERT_ATTRIB_MAX is pumped up to 32, it can result in wrong behaviour.
Yeah, the code should be inspected for places where that's wrong.
There's a few things that didn't work.
First, the patch didn't apply cleanly the the CVS trunk. I had to
manually apply a few of the patches. t_vb_arbshader.c was the main one.
In r300_state.c you need to replace "r300_outputs_written" with "union
r300_outputs_written". In C++ you don't need the 'union', but you do
for C.
In savetris.c you need to replace _TNL_BIT_TEX1 with _TNL_ATTRIB_TEX1
at line 880.
BTW, I'd still like to see the code re-indented to the Mesa standard
someday (3-space indentation, etc) and filtered to remove the carriage
return chars.
Okay, I understand that with this changes I can safely commit the code now.
Sure. Please monitor the list, though, in case any new driver bugs
appear because of the changes.
-Brian
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
