James Simmons wrote:
> > Can be any. This behaviour is usually a bug.
> > I'll explain it a little further below:
>
> Well that kills that idea. I was hoping that often the poblem was that the
> accel engine was updating area that another process was access via the
> framebuffer. If this was the case then I was going to steal a piece of the
> framebuffer from the process owning it and add it the process address
> space that opened /dev/gfx. This way the process owns the accel engine and
> the possible offending framebuffer region. [...]
With buggy hardware, you can simply prevent anything from accessing
the framebuffer (especially via mmaps areas) while the hardware
accelerator is running. If possible, without busy wait.
With normal hardware, concurrent and incorrect accesses to the same
area of the framebuffer by the application (even with two threads
or two processes) are due to bugs IN THE APPLICATION, it means either:
- that it did not call ggiFlush{Region}() while it should (single
process);
- that it did not correctly synchronize several drawing threads (single
process w/ multiple threads);
- that it did not arbitrate correctly the access to the screen
(one app. w/ multiple processes, or more probably one drawing server
with several clients).
Hence, in fact, the real issue is to protect the system against
buggy hardware. In that case, you need to lock access to the
card while the hw accelerator is running. That's pretty enough
in fact - the only other solution is not to allow any access to
the accelerator at all, or to get rid of protection entirely.
Rodolphe
