Maybe it’s time to talk about a new Linux Display Driver Model • Hacker News Board

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#31

Post by doesnotmatter » Sat, Sep 05, 2015, 9:45 PM UTC

tedunangst wrote: post #26

doesnotmatter wrote: post #24

Yea, that's cute, except that DRM can handle pretty much all of it. You can split hairs and complain about GPU scheduling which is inherently rather difficult because scheduling at the command queue level is problem very much alike the halting problem. The real issue isn't that we don't have the pieces we need but rather that we can't get all the players to agree on using the same ones. On Windows you have one entity…

Calling it a political problem and not a technical problem doesn't make it less of a problem. Nor does dismissing it as "cute" offer much in the way of a solution.

Yes, except that I didn't do either one of those things. I was responding to the original article which is calling for a new driver model, which, as pointed out, is neither the problem or the solution.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#32

Post by ac29 » Sat, Sep 05, 2015, 9:55 PM UTC

XorNot wrote: post #13

How much of the compositor problems will be fixed by Wayland? I know a big goal of Wayland is to address tearing and corruption.

Anecdotal, but these "compositor problems" are not inherent to Linux or X11. I am extremely sensitive to things like tearing, and I can tell you it simply doesn't occur on my linux machines (though it does require enabling a TearFree X11 option on my intel GPU).

Wayland, unfortunately, seems to be the type of project that has been a year or two away from usability since its first release in 2012. I suspect we'll be stuck with X11 for a while yet.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#33

Post by thrownaway2424 » Sat, Sep 05, 2015, 10:01 PM UTC

MaulingMonkey wrote: post #12

TheLoneWolfling wrote: post #11

Earlier quoted context omitted.

How long until we get a heartbleed-like attack where some software overruns its GPU buffer into a webgl buffer?

FWIW I've been running with WebGL disabled because of similar concerns.

WebGL works if you enable it? On Linux I've never seen anything other than error messages from WebGL.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#34

Post by TD-Linux » Sat, Sep 05, 2015, 10:08 PM UTC

XorNot wrote: post #13

How much of the compositor problems will be fixed by Wayland? I know a big goal of Wayland is to address tearing and corruption.

Wayland does address basically all of the tearing problems assuming a correct GPU driver (all of the opensource ones). There are several different problems, all of which are solved:

- Clients only provide complete buffer updates rather than drawing on to the front buffer, fixing tearing for all non-OpenGL apps

- Each monitor can have its own set of buffers and sync signal (technically the wayland protocol doesn't specify this, but makes it possible, and Weston does it correctly)

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#35

Post by geofft » Sat, Sep 05, 2015, 10:12 PM UTC

timthelion wrote: post #29

geofft wrote: post #19

Earlier quoted context omitted.

The Yama patchset has been in mainline for the last few years, and disallows non-root processes from reading each others' memory (except for direct children). The trouble is that it's a sort of retrofitted check. It works surprisingly well, but being added to a 20+-year-old OS and a 40+-year-old design, it can't guarantee being correct. The traditional, historic process boundary on UNIX has been user accounts / UIDs.…

Perhaps you would be interested in my project, subuser.org Unfortunately, it does absolutely NOTHING with regard to OpenGL isolation :( (That is if you give programs permission to talk to the graphics card, which is denied by default...)

Neato! Many years back I was playing with Xpra for this, but it was in the days before either Docker or useful seccomp. Glad to see something making progress here.

Have you looked at OpenGL virtualization e.g. Virgil (https://virgil3d.github.io/ , https://www.kraxel.org/blog/tag/virgl/) for that problem? The idea is to use Gallium to give them just enough access to get host 3D acceleration, but not direct access to the graphics card.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#36

Post by thristian » Sat, Sep 05, 2015, 10:32 PM UTC

thrownaway2424 wrote: post #33

MaulingMonkey wrote: post #12

Earlier quoted context omitted.

FWIW I've been running with WebGL disabled because of similar concerns.

WebGL works if you enable it? On Linux I've never seen anything other than error messages from WebGL.

WebGL exercises some new corners of the OpenGL interface that many drivers weren't prepared for when WebGL arrived, so browsers tend to have an extensive blacklist: if you have a driver on the list, you won't get WebGL.

On a rolling release like Debian Testing, with well-supported hardware like the Intel Ivy Bridge integrated GPU, WebGL has always worked beautifully.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#37

Post by pjmlp » Sat, Sep 05, 2015, 10:41 PM UTC

jbuzbee wrote: post #22

Animats wrote: post #16

Be grateful that graphics cards work on Linux at all. For over a decade, they barely did.

Depends on what you mean. I've been running Linux for 20+ years and have never had a graphics card that I couldn't get to work. If you're talking about acceleration, there have obviously been issues getting manufacturer support, but as a non-gamer, that mattered little to me.

So no endless hours trying to get a config file that wouldn't set the monitor in flames?

Because I did spent such hours back with Slackware 2.0.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#38

Post by comex » Sat, Sep 05, 2015, 10:50 PM UTC

geofft wrote: post #19

rbanffy wrote: post #6

Earlier quoted context omitted.

Should be pretty straightforward to fix. I wonder why it isn't. Is someone discussing the issue?

The Yama patchset has been in mainline for the last few years, and disallows non-root processes from reading each others' memory (except for direct children). The trouble is that it's a sort of retrofitted check. It works surprisingly well, but being added to a 20+-year-old OS and a 40+-year-old design, it can't guarantee being correct. The traditional, historic process boundary on UNIX has been user accounts / UIDs.…

GNOME is trying to do this: https://wiki.gnome.org/Projects/SandboxedApps

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#39

Post by FractalNerve » Sat, Sep 05, 2015, 10:53 PM UTC

doesnotmatter wrote: post #24

Yea, that's cute, except that DRM can handle pretty much all of it. You can split hairs and complain about GPU scheduling which is inherently rather difficult because scheduling at the command queue level is problem very much alike the halting problem. The real issue isn't that we don't have the pieces we need but rather that we can't get all the players to agree on using the same ones. On Windows you have one entity…

I am sorry, sir. What is DRM? I only have Digital Rights Management flashing in into my memory, but I have no idea what you could mean with DRM. Apparently I've been able to ignore and live behind the moon, not knowing what DRM is, while using Linux mainly since 2003-2004.

I'm sad that there is no alternative to X that works with `legacy` graphic cards like mine (Radeon HD 4500). But to be honest I'm personally just concerned due to already mentioned security problems with Xorg.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#40

Post by to3m » Sat, Sep 05, 2015, 10:56 PM UTC

RX14 wrote: post #2

I am currently using 2 displays connected to my graphics card and one connected to my igpu on my Linux desktop at home, and it's really not that hard to set up. Unfortunately the GPU does all the rendering and passes images to the iGPU, but I believe this is the case too with Windows. Also there are a few bugs when using this setup to do with monitor positioning.

Oh. How did you do this? Are you using an NVidia GPU? Does XRandR work? I couldn't get this to work at all, though I was using the closed drivers (since I couldn't find any evidence CUDA works with the open ones). Do you need the open drivers for this?

In the end I spent £30 on a second GPU. Problem solved... ish. XRandR still didn't work, and GNOME3 switched to fallback mode, which is basically GNOME2, i.e., a totally different window manager and a totally different shell.

I have no opinion on the performance on Windows vs that on Linux (not a concern, hence the £30 GPU...) but this whole situation was certainly a lot less hassle on Windows ;)