| |||||||||||||
Graesslin: Driver dilemma in KDE workspaces 4.5Graesslin: Driver dilemma in KDE workspaces 4.5Posted Sep 7, 2010 1:40 UTC (Tue) by RCL (guest, #63264)In reply to: Graesslin: Driver dilemma in KDE workspaces 4.5 by drag Parent article: Graesslin: Driver dilemma in KDE workspaces 4.5
It's actually impossible even on well-tested platforms with good support (read: Windows). Even with such a standardized and clean API as DirectX (3D, Compute) is.
Linux sucked for anything graphics related since forever and NVidia has been a lone saviour for a number of years. That problem isn't new. KDE can't "fix them in the drivers" because nobody - not even major commercial Linux players like Red Hat - was able to do that either. Hell, even Intel can't, despite having its own drivers for its own hardware.
That's all is pretty sad, actually. With the appearance of GPGPU more than 4 years ago, the world is slowly moving to some hybrid computing model where main CPU cores are used only for task-parallel programming, which is a minor challenge, while data-parallel stuff - the most compute-intensive one - is being done on simpler, but more numerous GPU-like cores.
Good news is that the future indeed belongs to multicore systems. Bad news is that it won't be symmetric, but rather asymmetric multiprocessors with most of performance-critical code being written in "virtual" instruction set like NVIDIA's PTX which heavily relies on drivers to translate it to hardware-specific representation.
GPU drivers nowadays aren't just for graphics. We're abstracting away the processors (which is a good thing), but unlike Java etc we avoid losing the speed that much. Unfortunately we are introducing a layer of drivers which will soon be needed to run even the most basic software. And there's no open source solution for that, not even on a horizon - seeing how open source drivers are struggling to support the functionality of pre-GPGPU era...
(Log in to post comments)
Actually the problem becomes easier, not harder Posted Sep 7, 2010 6:12 UTC (Tue) by khim (subscriber, #9252) [Link] GPGPU does not introduce new hardware, it's just a way to use the same hardware for different tasks. This means when free drivers will be usable for 3D work they'll be easily adopted to GPGPU work. Advent of GPGPU era also means differences in architecture will be less and less important: strange limitation of different 3D chips which affect 3D drivers today will be just removed since GPGPU requires significantly more uniform architecture to be usable. Hardware may be totally different (like Athlon and Pentium4) but software should see something quite similar - or else the whole thing will not work.
Actually the problem becomes easier, not harder Posted Sep 7, 2010 6:45 UTC (Tue) by drag (subscriber, #31333) [Link]
My understanding is that nowadays there is very little '3d' done in hardware. No 'opengl state machine' or anything like that. It's all software rendering with just some of the software designed to run on the GPU while other parts on the CPU.
This is why it's so important to get working open source drivers. The GPU is now part of the normal computer architecture, just like the math co-processor from the 386/486 days. Just exponentially more complicated.. Imagine having to install 'drivers' to use your central CPU! Depending on proprietary drivers to create a abstraction between you and your hardware in this manner is insane if you want to maintain that you run a open source system.
It will not be long until the GPU will be integrated as cores on your central processor. It's not a matter of 'if', it's only a matter of when. Moore's law is going to continue to go into effect and it's just 'duh' that those transistors are going to have to be used for more then just another general purpose core if we want to continue to see performance increases and increases in efficiency.
Shuffling information over PCI-Express bus is going to start to get extremely expensive no matter how much bandwidth you have... it's latency that is the killer.
Actually the problem becomes easier, not harder Posted Sep 7, 2010 9:18 UTC (Tue) by nix (subscriber, #2304) [Link]
The fact that you need to install drivers on your GPU, but not your CPU, has nothing to do with the complexity of the GPU per se. It's got to do with the fact that the kernel (and drivers) are running on the CPU, so something on the CPU has to program the GPU, maintain a shared memory management layer, and tell the GPU what to do. And that something is the driver.
Actually the problem becomes easier, not harder Posted Sep 7, 2010 9:50 UTC (Tue) by RCL (guest, #63264) [Link]
I like your comparison of GPUs to FPUs... It's indeed the case :)
By the way, just to illustrate the importance of GPGPU in traditional areas: http://gpgpu.org/2010/09/06/packetshader-software-router
Actually the problem becomes easier, not harder Posted Sep 7, 2010 11:16 UTC (Tue) by Trelane (subscriber, #56877) [Link] GPGPU does not introduce new hardware, it's just a way to use the same hardware for different tasks.Jein. See also, NVidia Tesla. Perhaps more correct would be that it doesn't introduce new chips; TMK Tesla cards are just specialized hosts for standard higher-end NVidia chips. strange limitation of different 3D chips which affect 3D drivers today will be just removed since GPGPU requires significantly more uniform architecture to be usableDepends on what you're referring to. E.g. GPUs have a pretty strange memory hierarchy, and I don't see it going away. GPGPU programmers just work around it for the most part as far as I can tell.
Graesslin: Driver dilemma in KDE workspaces 4.5 Posted Sep 7, 2010 7:16 UTC (Tue) by drag (subscriber, #31333) [Link]
> Linux sucked for anything graphics related since forever and NVidia has been a lone saviour for a number of years. That problem isn't new. KDE can't "fix them in the drivers" because nobody - not even major commercial Linux players like Red Hat - was able to do that either. Hell, even Intel can't, despite having its own drivers for its own hardware.
Linux has made huge strides and will continue to do so. There is no choice. You cannot depend on Nvidia for making a working system that will be competitive with Windows or other operating systems. Nvidia does not give a shit one way or another about Linux. _They_just_don't_
Unless your a major OEM or are willing to spend huge amounts of money on high-end professional graphics for Linux Nvidia does not care about you. They don't care about your desktop, your kernel, your needs. They don't care about making it easier, more secure, more stable, more efficient or anything remotely like that. The only reason we have the drivers we have is because Nvidia's consumer hardware is so similar to their professional hardware and they have the ability to make a shim into the kernel to shove parts of their XP drivers into it.
Anyways: GPU's have been very 'General Purpose' for a very long time now. Ever since they started calling them 'GPU's, basically. Having to build compilers to build and execute GLSL code on them is proof of this. It was a huge failure for XFree86 and other folks to not recognize this and they delayed modernizing the driver architecture for nearly a decade. ATI and Nvidia proprietary drivers made the transition to the newer architectures years ago and since then the move to 'GPGPU' has been a evolutionary one.
If Linux cannot provide the ability to perform well on modern hardware without shoveling well over 50MB of Windows driver code into the system then what exactly is the point of having Linux, then? Just so you can have a good command line or something? I can easy show you how to have a POSIX environment on Windows 7 if that is all you really care about. (One of the nice things about NT Kernel is that it has the ability to support multiple user space APIs.. the win32 stuff is just one of many it supports.)
How can Linux move forward and be able to claim that it supports hardware with 90% of peoples computers will not have the ability to support modern APIs? Only a small minority of people actually do run modern Nvidia hardware that is supported by Nvidia drivers... 70-80% run Intel hardware and ATI is still popular.
That is what is so sad about the developer complaining he did not have the hardware to test open source drivers. Only a small fraction of his potential audience has the ability to run proprietary Nvidia drivers. Even if all he had was nvidia hardware it is still more then likely supported by open source drivers.
How can you have modern applications and modern graphics when the software support for it in Linux is that spotty? Why do you think that game developers swore off Linux as a nightmare to program for?
We now have working Gallium3D drivers. We have working open source drivers on 3 of the top most common hardware families out there which will cover well over 95% of the x86 hardware out there.
Things have improved hugely and when Intel finally gets off their asses realizes that they need to use the same driver architecture that ATI and Nvidia open source developers are using then Linux will be able to provide the same level of consistency that things like DirectX and Windows provide. It will be years before it reaches the same level of modernization and performance, but that is much less important then having something that is reliable and works consistently across the board.
Graesslin: Driver dilemma in KDE workspaces 4.5 Posted Sep 7, 2010 14:16 UTC (Tue) by fandingo (subscriber, #67019) [Link]
Simply not true. How can you explain VDPAU? There isn't much commercial application for it. VDPAU is completely a consumer technology.
|
|||||||||||||