As it becomes more clear that in the mach64 the best solution is to fill 
DMA buffers with the context state and the vertex buffers I've been trying 
to understand how can this be done and how the Gamma driver (which has 
this same model) does.

The context state is available right in the beginning of running a 
pipeline and usually DDUpdateHWState is called in the beginning of 
RunPipeline. The problem is that although all state information is 
available, we don't know which part should be uploaded since other clients 
could dirty the hardware registers in the meanwhile.

I'm don't fully understand how the Gamma driver overcomes this. Its 
behavior regarding this is controled by a macro definition, named 
DO_VALIDATE, that enables a series of VALIDATE_* macros which in turn I 
couldn't understand what they do. Another thing that caught my atention 
was the "HACK" comment on gammaDDUpdateHWState before gammaEmitHwState - 
it reminds a similar comment on mach64, which makes one think that the 
author had in mind a better way to do that. Alan, could you shed some 
light on these two issues please?

Before I started this little research I already had given some thought on 
I would do it. One idea that crossed my mind was to reserve some space on 
the DMA buffer to put the context state before submiting the buffer. Of 
course that there would be some DMA buffer waste but it wouldn't that much 
since there are a fairly low number of context registers. One think that 
holds me back is that I still don't understand how multiple clients avoid 
each other: what is done in parallel, and what is done in serie...

I would also appreciate any ideas regarding this. This is surely an issue 
I would like to discuss further on the next meeting.

Regards,

Jos� Fonseca

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to