Fabio Alemagna <[EMAIL PROTECTED]> wrote: > > How do you handle half-done accelerator commands? I have not yet heard a > > convincing way to handle them. > You wait for them to finish. They don't take forever, do they?
Right. If the app is written correctly. The point is: 1. We have to wait for quite some stuff anyway. 2. A well-behaved app will usually respond pretty quickly to a release request. 3. An ill-behaved app (think of malware) might want to make us wait forever. So I think it just isn't worth the bother to do a lot of "magic" from kernelspace that might be difficult to emulate on some platforms, when it can be done nicely in the application. All I propose is, that we signal the application in some way, that it will loose visibility. The app can then adapt to its liking. And while at it, it can just as well set up a backbuffer. If the application does not cooperate, then take _simple_ kernelside measures to preempt the application. > Very simple: protect that piece of code with a mutex! And provide for a DoS condition, if the mutex cannot be forcibly overridden from kernelspace. Moreover shared user/kernel mutexes may be very expensive on some architectures. > It can be all done in userspace with some shared memory and mutexes. So what are we discussing about, then? That's basically what I am saying. All we differ in, is that I advise to let the application actively participate in the switchaway process and thus provide a simple, portable solution. Yeah, I know how to "overmap" the VRAM mapping with a shm buffer, but what about platforms without shm? > Applications _do_ need to cooperate to access shared resources, and gfx > card's registers are shared resources: you need to protect the access to > them with some locking mechanisms if you want more than one process/thread > to use the gfx board at the same time. Yeah. So we're talking about the same thing now ... Only remaining difference seems that I opt for the easy way of doing the switchaway, while you'd like to have it a bit more transparent to the application, which will IMHO cause quite a lot of work for very little gain. BTW: IMHO that should rather be discussen on the KGI ML - LibGGI isn't in charge to dictate what they should use. When they got something to solve the problem, LibGGI will just adapt to it, I'd say. CU, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
