On Sunday 10 March 2002 04:36 pm, Jos� Fonseca wrote: > I didn't fully understand the implications of above, but shouldn't the > direct access to the chip registers still be denied to clients?
Depends. Looking at the gamma source code (I could be wrong, mind...) it appears that the DRM is taking in direct commands from userspace in DMA buffers and sending them on to the chip as time goes along. If you can make it so that it doesn't lock up the card or the machine and doesn't compromise system security in any way (i.e. issuing a DMA pass from a part of memory to the framebuffer and then from the framebuffer to another part of memory so as to clobber things or to pilfer info from other areas), it's pretty safe to do "direct" commands. From observations, it appears that you can't get the engine to do anything except GUI operations during a properly set up GUI-mastering pass. The only risks that I can see right at the moment with sending direct commands over "indirect" commands is one of not resetting certain select registers to what they were before the pass and one of the engine not handling certian GUI operations well. The first is easily taken care of by having the driver have a 4k block submitted in the descriptor chain as the last entry that updates those registers accordingly- the list of commands should only need to be built once and reused often since these registers won't be changed by the DRM engine, Mesa driver, or the XAA driver after the XAA driver does it's setup for the chip operation. The second case is a tough one and one that copying/mapping won't protect you from it- you have to process commands to prevent them from occuring (compute intensive and there might be other cases, each time you'd have to come up with yet another workaround) or find something to detect a hang on the engine and reset it proper. I seriously doubt that we'd encounter one of those, but we might all the same. I've still got one or two more tests to run (I've yet to deliberately hang the engine, detect the same, and then do a reset- but then I've yet to be able to hang the engine with it _properly_ set up...) but most of the innards for copying commands or whatever would be largely the same (some of the interfaces might change, but that's less of an issue than the heart of the DMA engine itself which is the same no matter what...) so I'm going to get _SOMETHING_ in place to see what our performance actually would be with some DMA operation going on. > > Mapping and unmapping a memory space is somewhat compute intensive. > > This one has to be compared to the time that takes to copy a buffer, > unless there is a way to do it in a secure manner without copying or > unmapping. If you don't have issues with sending commands directly, you don't need to copy or map/unmap. You don't need special clear commands or swap commands, you only need to issue DMAable buffers of commands to the DRM engine for eventual submission to the chip. Right now, I'm not 100% sure that the mach64 is one of those sorts of chips, but it's shaping up to be a good prospect for that. -- Frank Earl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
