Re: [Xpert]write_mem_barrier()
Mark Vojkovich writes: On Thu, 15 Aug 2002, Egbert Eich wrote: Can any two register writes get written out of order? They can, however this may depend on their address order. If the address order is ascending you may be lucky. I never went into this really deeply. 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. Yes, that's the way it is done on a lot of chipsets. Do you see any problems on a specific architecture? I know that Jay Estabrook has done a lot of otpimization for the Alpha - he may tell you more about the rules where fence instructions need to be placed. But again this may be architecture dependend. 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. Have you tried adding some more fences? We may have to add architecture specific fence macros :-(( I could try both Alpha and PPC as I can get access to both platforms however I don't have time right now. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]write_mem_barrier()
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. 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. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]write_mem_barrier()
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
[Xpert]write_mem_barrier()
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? Mark. PS. I assume that on powerpc this is hooked up to eieio? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
