>> At one point I was about to implement a scheme for via with a number >> of similar locks, one for each independent function on the video >> chip, Like 2D, 3D, Mpeg decoder, Video scaler 1 and 2, so that they >> didn't have to wait for eachother. The global lock would then only >> be taken to make sure that no drawables were touched by the X server >> or other clients while the lock was held, which would be compatible >> with how the X server works today. Never got around to do that, >> however, but the mpeg decoders have a futex scheme to prevent clients >> stepping on eachother. With that it is possible to have multiple >> clients use the same hw decoder. > > Sounds interesting, but that would be card specific, right? I mean, on > some cards the 2d and 3d locks would have to be the same because of > shared state or whatever, for example. > > Jesse > Yes. you're right. The idea was to provide an implementation of a set of locks and context switch / idle hooks that the device-specific driver could use for whatever part of the chip it wanted, _if_ it wanted to. When a command stream is submitted, the driver would need to check that there are only commands for locked part of the chip in the stream. There would also need to be a mechanism to check whether there are pending DMA commands corresponding to a particular lock, to avoid having to make DMA quiescent in unnecessary cases. Lock values would reside in a separate shared memory area. However, a bit complicated and too little time.
/Thomas. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
