On Sat, Sep 17, 2011 at 12:06 PM, Florian Tobias Schandinat <FlorianSchandinat@xxxxxx> wrote: > Again, you seem to not understand my reasoning. The "if" is the problem, it's > the kernels job to ensure stability. Allowing the userspace to decide whether it > crashes my machine is not acceptable to me. > I do not claim that it is impossible to write a KMS driver in a way that it does > not crash, but it seems more difficult than writing an fbdev driver. It is a non-trivial problem, which I would argue is impossible, to permit acceleration without also permitting the possibility of a GPU lockup. It is completely legal, in every graphics API, to submit requests which take multiple seconds to render but are totally valid. Differentiating between long-running rendering and GPU lockup is difficult. In addition, determining whether or not a permutation of register writes will lock up a GPU is a pretty hard problem, computationally, not to mention the walls of code that would be required to make this happen. At that point, you might as well run unaccelerated. >> The core drm/kms ioctls don't expose acceleration to userspace either, >> again misinformation seems to drive most of your logic. You can't do >> generic useful acceleration from the kernel. A lot of modern GPU >> hardware doesn't even have bitblt engines. > > I did not say that it is used directly for acceleration, but wasn't the point of > DRM to allow acceleration in the first place? In the Voodoo era, sure. DRM really means that userspace can talk directly to a card, in a card-specific way; beyond the basic DRM ioctls for gathering card info, nearly every ioctl is device-specific. You can't command an nV card with Radeon ioctls. It just so happens, fortunately, that the only things which differ from card to card and cannot be abstracted from kernel to userspace are accelerated rendering commands. You're conflating DRM and KMS. It's possible to provide KMS without DRM: Modesetting without acceleration. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@xxxxxxxxx> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel