On Tue, 21 Jan 2003, Andreas Beck wrote: > Fabio Alemagna <[EMAIL PROTECTED]> wrote: > > Not necessarily, it just requires a way to centralize memory allocations. > > You are only talking about memory. I have already shown that and how it can > be done. > > 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? > > Why would that be complicated? You have one or more surfaces on which you > > display things, after VT switching you still have one or more surfaces on > > which you display things. > > And you have an application that is stuck in a piece of code (within the > library) like this: > > accelreg[DATA_REG]=some_setup_stuff; > /* VT switch happens here */ > accelreg[CMD_REG]=some_command; > > > Now what do we do with that? Very simple: protect that piece of code with a mutex! > > I can do it easily if I just have framebuffers. I can do it easily, if > I route all accel stuff through a central authority and either let it > provide fallback rendering (yeah, I can hear the kernel people scream, > if we put a complete graphics engine in there) or have the code > calling into it check for errors in every instance. I can do it easily > on graphics hardware that uses main RAM, can be saved/restored nicely > and can be told to just keep blitting to that piece of RAM, even though > it is not visible. It can be all done in userspace with some shared memory and mutexes. > > Even in AROS it works, so I don't see why it shouldn't work in KGI. > > Show me code, that works in the direct-accel-access scenario I depicted > above, that does not need the application to cooperate or using something > of outrageous complexity like emulating the graphics hardware with > pagefaults (VMWare-Style). 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. Fabio Alemagna
