Frank C. Earl wrote: > > The command pathway doesn't seem to allow for that. Only the blit pathway. > I've coded only inbound to the aperture writes with that pathway, but not > outbound (there's very little that anything other than the X server needs to > do that sort of thing).
How do you prevent a client-side "driver" from sending down blit commands, without inspecting the DMA buffer? > Ok, that's going to make the machine do the work twice- once for filling the > buffer with verticies and then again to unpack them and submit commands to > the engine. I was trying to avoid a bottleneck- but, okay, if that's not > acceptable, I'll do it the other way. You can't allow the user-space portion of the driver to fill in the register programming words in the DMA buffer. Vertex data, sure, that's okay. The registers are mapped into two separate pages for PIO access, but all that goes away when you're doing DMA transfers... > The engine doesn't seem to allow for that if you disallow the user to set up > blit operations. I'd have to run a test to be sure, but I think the engine > would lock up if you messed with the setup registers and tried to transform > the gui-master into a blit and that'd be only way what you suggest could > happen with the RagePRO from what I can tell. Exactly how do you do this? > The other cards seem to mainly have nice pathways for submitting verticies, > etc. This one doesn't. I'll recode it to accomodate no commands but pure > data- it's not just a pain, it's horribly inefficient with this card the way > it's designed. It's a damned slow chip. With anything over about a 4-500MHz processer, you'll still be able to saturate the chip -- we got it to hit the hardware limit doing PIO with a 600MHz PIII, I seem to recall... -- Gareth _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
