linux-kernel - Re: Proposal for a low-level Linux display framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Sep 2011 12:25:24 -0700
From:	Corbin Simpson <mostawesomedude@...il.com>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	Dave Airlie <airlied@...il.com>, linux-fbdev@...r.kernel.org,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, Archit Taneja <archit@...com>,
	Rob Clark <rob@...com>
Subject: Re: Proposal for a low-level Linux display framework

On Sat, Sep 17, 2011 at 12:06 PM, Florian Tobias Schandinat
<FlorianSchandinat@....de> 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@...il.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/