From: Keith Whitwell <keith@tu...> - 2005-04-23 12:42:49
Felix K=FChling wrote:
> Am Freitag, den 22.04.2005, 23:04 +0100 schrieb Keith Whitwell:
>>Felix K=FChling wrote:
>>>Am Freitag, den 22.04.2005, 05:51 -0700 schrieb Keith Whitwell:
>>>>Module name: Mesa
>>>>Changes by: keithw@... 05/04/22 05:51:20
>>>> Simplify the pipeline_stage structure
>>>> - remove input/output fields, input tracking removed.
>>>> - remove state fields, the validate function now called
>>>> on every statechange.
>>>> - add an explicit 'create' function.
>>>Keith, are you aware that these changes break drivers that add their o=
>>>stages to the pipeline (radeon, r200, mga, savage, more?). Were you
>>>planning to fix these? Anyway, I'll try to fix up Savage over the
>>Ah, of course. I'll join you in fixing them up over the weekend.
> Thanks, Savage works again now. I haven't noticed any regressions so
I've got a couple more things that I plan to do:
1) Make the "pipeline" behave more like a vertex program - in particular=20
it will produce a the same outputs that vertex programs produce:=20
HPOS/COL0/BFC0/etc. And it will probably not include the final render=20
2) Note that the latest changes have at least temporarily disabled the=20
old Quake CVA optimziation - by splitting rendering off the pipeline as=20
above, we can restore the most important CVA case (multiple drawelements)=
3) I'd like to see the vertex program become the expected or normal mode=20
of operation - this will require quite a bit of optimization to=20
4) I'd like to see if it isn't possible to integrate t_vertex.c and=20
t_vb_arbprogram.c and have the vertex program spit out hardware format=20
vertices rather than raw arrays. If you squint at t_vertex.c it already=20
looks a lot like program execution, so it's just a matter of rolling the=20