| |||||||||||||
LinuxCon Brazil: Q&A with Linus and AndrewLinuxCon Brazil: Q&A with Linus and AndrewPosted Sep 2, 2010 12:01 UTC (Thu) by nix (subscriber, #2304)In reply to: LinuxCon Brazil: Q&A with Linus and Andrew by michaeljt Parent article: LinuxCon Brazil: Q&A with Linus and Andrew
Um, it was. It didn't work. The DRM stuff that's in kernel space is hardware-bashing mode-setting and memory-management stuff. So we have hardware-bashing, arbitration among many processes and security (because the video card has access to all of memory and can be told to do stuff to it). Seems like stuff that belongs in the kernel to me.
(Log in to post comments)
LinuxCon Brazil: Q&A with Linus and Andrew Posted Sep 2, 2010 14:04 UTC (Thu) by michaeljt (subscriber, #39183) [Link] > The DRM stuff that's in kernel space is hardware-bashing mode-setting and memory-management stuff. So we have hardware-bashing, arbitration among many processes and security (because the video card has access to all of memory and can be told to do stuff to it). Seems like stuff that belongs in the kernel to me.It is particularly the arbitration between processes that I am thinking of. As far as I know, the main reason that indirect rendering is significantly slower than direct rendering is due to the need to pass large structures through, mainly textures and arrays of vertices. So to me it would make sense for direct rendering to work mostly like indirect rendering, except for additional mechanisms - say mechanisms based on shared memory in some way, like giving the process with actual access to the video card device a means to selectively share portions of video RAM - for passing those data structures more efficiently. This would also remove the need for memory management of video RAM in the kernel, as it could be done by the process managing the rendering - i.e. the X server - which mapped the VRAM. As usual, feel free to point out why this would never work, I am always happy to learn something new.
LinuxCon Brazil: Q&A with Linus and Andrew Posted Sep 2, 2010 17:12 UTC (Thu) by glisse (subscriber, #44837) [Link]
indirect rendering or direct rendering as little to do with the DRM infrastructure. Indirect rendering is when rendering goes through the X server, it's was glx extension offer. Direct rendering allow you to directly speak with the GL driver and thus stuff doesn't go through the X server.
In this picture the DRM infrastructure in kernel as no role to play, what DRM provide is use by lower level ie the GL driver or the X driver. Last you don't want X to handle memory what about GPGPU or others use of GPU ? GPU offer resource, you need a central place to allow proper sharing of resources among consumer and given the capabilities of GPU (capable of overwritting otherwise protected system memory like kernel structure) you likely don't want to have too much in userspace.
LinuxCon Brazil: Q&A with Linus and Andrew Posted Sep 3, 2010 13:44 UTC (Fri) by Spudd86 (guest, #51683) [Link]
Not to mention that the DRI2 stuff means you can do direct rendering without an X server at all, you can even do it with just one process running on a framebuffer (this is essentially how Wayland does it's rendering).
LinuxCon Brazil: Q&A with Linus and Andrew Posted Sep 3, 2010 14:04 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
> Not to mention that the DRI2 stuff means you can do direct rendering without an X server at all, you can even do it with just one process running on a framebuffer (this is essentially how Wayland does it's rendering).
In my defense, I did say "i.e." the X Server. I could quite imagine the same thing being done at a lower level, say in Wayland. Of course, if you just have one application doing graphics you don't need to worry about multiplexing the graphics resources at all and can just talk to the kernel bits directly. I also suggested that direct rendering might "work mostly like" indirect rendering, not exactly like it. I don't really think that OpenGL is necessarily the best API to base the communication on - something closer to Gallium 3D might be better. As for GPGPU stuff, I must confess that I'm not very knowledgable about it - I thought that it mainly involved running shader programmes on data structures that were set up to look like vertices and things and interpreting the output.
What does seem trickier to me is that there are no good APIs that come to my mind that could be used to let one user space process manage memory for others to let them selectively map sections of the video RAM into their address space. And of course there is the small matter that after people have invested so much into DRI2 they are probably not raring to try alternative designs!
LinuxCon Brazil: Q&A with Linus and Andrew Posted Sep 3, 2010 13:42 UTC (Fri) by Spudd86 (guest, #51683) [Link]
Also Indirect rendering doesn't do everything Direct does because the wire protocol for newer OpenGL stuff was never specified. (For example you don't get GLSL with indirect rendering)
|
|||||||||||||