On Thu, 22 Aug 2002, Rodolphe Ortalo wrote: > The "accelerator engine communication channel" is also a generic thing > common to all drivers in some sense. But its standardization may be (?) > less critical as it can only be useful for (hw-specific) software that > knows how to use it effectively (and fill it with binary ops that the > specific hw engine understands).
Right, my point exactly. > The key issue in the standardization on a > generic channel from userspace down to the accelerator is more related to > the fact that it will be a (important) design decision. I think we need to just identify what facilities (mmap page-fault schemes, various types of kernel<->user locks) are needed as building blocks, and standardize them in a way that driver authors find them easy to use, not standardize the pipeline as a whole. > > The > > only exception to this IMO should be facilities which are easy to provide > > because they had to be implemented in order to provide the OS with > > a console/fb system, mainly mode-setting. Other than that, there > > should be a strict "validate only" policy. > > Oh. It seems we agree in fact. Right, I was considering the minimum requirements for VC's to be everything the OS needs to implement a 16 color and/or attribute, ASCII text terminal system, and the "optional" stuff to be basically the necessary enhancements to implement things like linux fbdev, and the mouse cursor and programmable console text fonts. > > 2) Absolute inter-process security > > Hmmm. You mean that we need to double check that the permissions on the > /dev/graphics devices and co. are really enforced by the code? Corner cases like leaving data in the video RAM after a console switch, possibly giving access to sensitive information. > > 3) Graphics driver system pause/resume due to VC-switch and/or system > > powersave or suspend-to-disk, > > Isn't this limited to text mode? In "VC-switch", there is the C for > console which means text (even if on a graphical fb)... Okay, that's just > a pun, but isn't my point valid anyway? It seems to me that, on one > graphical head, a switch should be handled the simple way (SIGSTOP? Can > be trapped no?). Much more complicated than that: what guarantees does KGI offer about preserving the state of the hardware? Will the GPU be flushed? Can an app arrange to have the fb and texture contents preserved by saving them aside? And, can all this be done in-kernel such that we do not have to play any complex double-clutch tricks (send a signal to the app, give it a small time-slice to prepare for the switch and ensure the app is scheduled for at least long enough to perform the needed operations, then block the app when the time limit is up.) And then we have save-to-disk where the state of the hardware has to be restored from power-on conditions. -- Brian
