On Thu, 15 Aug 2002, Egbert Eich wrote:

> Mark Vojkovich writes:
>  > 
>  >   To me the application of write_mem_barrier() to drivers like the
>  > "nv" driver seems almost haphazard.  Can someone explain what the
>  > criteria is for placing these?
>  > 
> 
> These marcos are required only for weak ordering architectures 
> like Alpha and expand to nothing on architectures that don't 
> have this property. Ia32 is one of them.
> 
> Generally you want to issue them to make sure all data has been
> written to the bus before executing the next instruction.
> 
> You want to do that before you read data from a register which
> may depend on data written to another register previously.

   Can any two register writes get written out of order?
If so, then the fences in the "nv" driver are misplaced and
insufficient.  For each primitive, the last register in the
sequence is what initiates the drawing.  If the setup writes
were not commited before the kickoff write, things will be
wrong.


> Also you want to issue it before you write to a register that
> starts an operation that depends on data written to other registers
> and you want to issue this instruction afterwards to make sure the
> operation actually gets initiated.
> 
> That's the theory - generally it takes some experiments. 
> 
> We even don't know yet if all weak ordering architectures behave
> exactly the same ie. if they require the fences at the same place.
> 
> If you use the MMIO_OUT macros you don't need to worry about
> setting fences as these are fenced already. Fencing any write is
> suboptimal however therefore drivers should be tuned to use
> the MMIO_ON macros and fence explicitely.
> As far as I remember I started to add support for non fenced writes
> to the nv.
> Jay Estabrook fixed some problems and did a lot more tuning for 
> the Alpha.
> 

   Well, here's the deal.  Color expansion doesn't work reliably
on PowerPC with the "nv" driver and there doesn't seem to be any reason 
for it other than architectural issues. 


                        Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to