17 ms·
Maybe it’s time to talk about a new Linux Display Driver Model
- RX14 11y agoI 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.
- ccrush 11y agoYou misread OPs point. He is saying Windows can do both. And vsync across cards. That is quite a feat. If using separate outputs, this is probably achievable on Linux with a bit of work. Also vsync with a compositor shouldn't be impossible. However, if the processing is done on on two graphics cards and we output only on one of them then we need cooperation from the device manufacturers to provide us drivers or implementation details on how to drive their hardware muxers. Without that info, we're dead in the water.
- makomk 11y agoInitially at least, I don't think Windows did anything of the sort - laptop vendors were shipping carefully-vetted and tweaked versons of the Intel and $OTHERVENDOR drivers that knew how to talk to each other and couldn't be upgraded in the normal way. Naturally, they didn't bother doing this for Linux.
- datenwolf 11y ago> And vsync across cards. That is quite a feat. Well, what it does is, that the compositor (DWM) keeps a (small) backlog of presented window framebuffers (think GL SwapBuffers, that add to the queue) and whenever a screen's VSync comes along it blits the most recent picture presented to it. Which has the effect that if you have a window spanning multiple GPUs' outputs they may not all show the same frame, because the display refresh frequencies will beat (even if you set the same refresh frequency on all outputs, since between different GPUs they're not driven by the same clock, you'll get a little bit of clock skew; and video clocks are usually not of the low drift type, because for video it doesn't matter if you're off a few ppm). If you need synchronized video sync vendors are happy to sell you genlock-able cards for $$$.
- to3m 11y agoOh. 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 ;)
- RX14 11y agoI used xrandr --setprovideroutputsource to set one image provider as the source of the others image.
- thrownaway2424 11y agoThe thing about being able to read other process memory under Linux has always driven me nuts. Linux is fairly secure _except_ for this one giant gaping hole that nobody mentions.
- 0x0 11y agoThis is extra fun considering WebGL.
- hiker 11y agoWebGL implementations zero out newly allocated buffers for exactly that reason. https://www.khronos.org/registry/webgl/specs/latest/1.0/#4 https://www.khronos.org/registry/webgl/specs/latest/1.0/#4
- TheLoneWolfling 11y agoHow long until we get a heartbleed-like attack where some software overruns its GPU buffer into a webgl buffer?
- MaulingMonkey 11y agoFWIW I've been running with WebGL disabled because of similar concerns.
- thrownaway2424 11y agoWebGL works if you enable it? On Linux I've never seen anything other than error messages from WebGL.
- thristian 11y agoWebGL 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.
- TerryADavis 11y agoCIA sucks my dick.
- XorNot 11y agoHow much of the compositor problems will be fixed by Wayland? I know a big goal of Wayland is to address tearing and corruption.
- ac29 11y agoAnecdotal, 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.
- mikekchar 11y agoThe open source Radeon driver also does a good job of avoiding tearing. I think there are some pathological cases where it can still occur, but it is pretty rare. Catalyst was terrible at avoiding tearing the last time I used it (getting on to be 3 years ago now). I haven't looked into it, but it is possible that the tearing issue may not be solvable without a KMS driver (i.e. no binary blob drivers can do it). I used Wayland/Weston for a full work day about a year ago to try it out. It really was very nearly ready. I can't quite remember what problems I ran into, but I could do my work (as a web developer) with very few real problems. Probably it's time to look at it again.
- XorNot 11y agoInteresting to hear, I might give it a shot too now.
- TD-Linux 11y agoWayland 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)
- nikanj 11y agoNew year, new Linux graphics driver model. CADT is alive and well.
- gkop 11y agoI ran into issue 3) and a variation of 4) recently trying to accomplish what should be a pedestrian task: running Xvfb on Heroku. X11 is a pain in the ass to package, I spent a day on it and gave up.
- Animats 11y agoBe grateful that graphics cards work on Linux at all. For over a decade, they barely did.
- jbuzbee 11y agoDepends 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.
- mfisher87 11y agoHaven't been using linux as long as you, more like 10-15 years, but I've noticed during that time that the effort required to get a graphics device working has shrunk significantly (and I don't attribute that to an increase in my knowledge). I definitely use linux primarily for other stuff these days, though, so it's not often I'm setting up a new graphics card with linux anymore.
- pjmlp 11y agoSo 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.
- tfranco 11y agoStill remember the days where one had to compile the kernel to enable sound in doom. The fact that most hardware is supported today is a blessing. And agree with the author. X11 has aging issues.
- datenwolf 11y agoOr for that matter XFree86 / Xorg and Xlib have aging issues. IMHO the protocol is okay (it's not perfect). Maybe cut away some of the legacy cruft, implement antialiased rendering for core primitives (yes, even if they are just lines, arcs and ellipses, those are still needed even on modern screens; heck with all the flat style UIs currently being all the rage on a HighDPI screen you could probably disable XRender and nobody would notice). The whole framebuffer handle management of Wayland is a huge step in the right direction, but I despise Wayland's input and inter client communications model; not to say that X11 was anyway better, but whenever I code against Wayland, that part feels just wrong. Also the obsession of the Wayland devs of getting VSync right has its own share of issues (especially for low latency graphics, like you need it for VR).
- g10090409 11y agoIt's actually ironic that the Windows driver situation is worse than with Linux (with the exception of GPU drivers)
- doesnotmatter 11y agoYea, 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 (Microsoft) that can post WLK and unless you pass it you won't be certified and on GNU/Linux "a working driver" can be anything from "not catching on fire on boot" through "actually brings up display" to "oh, hey a textured triangle!". And I get it, everyone is frustrated because ultimately displaying a bunch of pixels, seems trivial, that is, until you mix in politics. You have NVIDIA, AMD, Intel and the community at large pulling all in different directions. With GNU/Linux graphics support having marginal effect on the bottom line there's little incentive to deal with it. And you'd still miss a controlling entity that could validate that "works on Linux" means anything but "compiles with some random kernel release". Everyone who thinks that writing great graphics drivers can be a spare time activity is delusional. The fact that we have Android with Gralloc (which in comparison to DRM is, well, a joke), Ubuntu with Mir, others trying out Wayland and folks still stuck on X11 makes this all so much more complicated than it needs to be (and SteamOS is rather terrible in this regard too, which is a shame because Valve is trying to do the right thing with Vulkan but SteamOS is just not a well put together distro, at least right now). It's just not a driver model problem, it's the politics of it all. Outside of Google adopting DRM instead of Gralloc (or Gralloc getting all of the features on DRM and effectively becoming DRM and replacing it on the desktop) there's probably little chance of unifying all the drivers under one coherent umbrella.
- tedunangst 11y agoCalling 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.
- doesnotmatter 11y agoYes, 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.
- stevebmark 11y agoThis is a good example of one of the dangers and failure points of open source. When hardware integration matters, you're going to have sub-par results if you don't have a strong relationship with the hardware manufacturers. The best firmware is from companies that control both the software and the hardware. Linux fundamentally cannot have this relationship. Some things need to be very specifically controlled and designed, with business interests driving progress. Open source doesn't help much with this. Trying to build a system that works fluidly with the larger audience, when the audience is independent corporations, is for better or worse a nightmare.
- slgeorge 11y agoI think you're trying to say that: a. Graphics requires software and hardware to be integrated b. Open Source communities don't work where you are driving designs in software and hardware - they are uncoordinated I can't comment on (a). In terms of (b) you might be right for the idea of "hackers at night" open source. But, a lot of open source is 'professional', so a graphics company could solve this by: 1. Graphics companies provide hardware and information under NDA to specific Open Source developers. That gets you enablement but not necessarily a "design" as you can't direct their work. 2. The hardware companies hire Open Source developers. That way you have either all, or a big chunk of a specific area of the developers. As employees they will work together on the companies priorities. 3. The hardware companies set-up a foundation. Then the foundation co-ordinates and works on the priorities of the members. There are sub-groups of the Linux Foundation that work like this - for ARM Linaro is an example. There's a meta-comment that talks about the economics of this area - that's a more significant challenge than the organisational ones.
- ryanmarsh 11y agoIt was time to talk about a new Linux display driver model 15 years ago. 10 years ago I gave up on Linux for this reason and switched to OSX
- yarrel 11y agoLet's incorporate it into systemd. That will solve everything.
- lololololololol 11y agoMaybe it's timw to pay for some more bandwidtth
- rootlocus 11y agoMaybe it's time to upgrade the hosting plan.
- pant 11y agoI am getting this error "Bandwidth Limit Exceeded The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later."
- theodorejb 11y agoIn case anyone else has been getting the "Bandwidth Limit Exceeded" error when attempting to access the page, here's a link to Google's cached copy: http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwww.yosoygames.com.ar%2Fwp%2F2015%2F09%2Fmaybe-its-time-to-talk-about-a-new-linux-display-driver-model%2F&oq=cache%3Ahttp%3A%2F%2Fwww.yosoygames.com.ar%2Fwp%2F2015%2F09%2Fmaybe-its-time-to-talk-about-a-new-linux-display-driver-model%2F http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...