Messages in this thread | | | Date | Thu, 24 Nov 2005 17:04:39 +0100 (CET) | Subject | Re: 2.6.14-rt4: via DRM errors | From | Thomas Hellström <> |
| |
>> 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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |