Since you're a Mesa/X.org dev, maybe you can answer this. Why has there apparently been no interest in implementing XvMC?
XvMC requires very specific hardware support (which AMD hasn't been able to get legal clearance for) or complex shaders. The latter is already in the Gallium tree, but we don't have a working driver that can run it yet.
Also, each of the big three has gone ahead and crafted their own goddamn standard. Intel's VAAPI, AMD's XvBA, and nVidia's VDPAU. Eventually, at least one of those will probably be added to Gallium. (Probably Intel's pick, since they put so much money into this.)
Based on what's been on IRC in the past few hours.
Q: Wait, what?
A: Code for radeonhd and the kernel providing acceleration for Radeon HD 2400 and newer. Kernel parts are already pretty much integrated; radeonhd is integrated as well, although stuff still needs to be copied to radeon.
Q: So what does this mean for the user?
A: EXA means faster GUI responsiveness. Xv means fast video. Kernel DRM is the basis for all acceleration unification (OpenGL, etc.)
Q: Speaking of OpenGL...
A: Lawl, no. Not for another few months. Most of the code we're gonna write will target Gallium, so--
A: Nope, no docs. AMD couldn't agree on docs before their vacation time, so I guess we'll see those in a month or so. On the other hand, we've got enough here to do a lot of stuff. It'd be nice if we had more devs, though.:3
Q: So why is there only code for radeonhd? Will radeon support this too? Why two separate drivers?
A: The reason for two separate drivers is a very long and largely silly story. I don't feel like repeating it, and I probably couldn't tell it fairly anyway.
I'll get radeonhd code ported over to radeon once my vacation's over, assuming nobody does it sooner. I can't do the HDMI audio setup without testing hardware, though; does anybody want to donate an HDMI audio-enabled monitor?:3
Graphics stuff must be in the kernel at some level. The reason for GEM is that the entire system needs to have unified memory management for GPUs, just like for CPUs.
Also each GEM-capable driver has to support legacy mode. Linus was *very* clear on that point. So, starting with 2.6.29, each KMS or GEM driver supports non-KMS and non-GEM mode. (Some drivers, like the Radeon drivers, are all-or-nothing, so running KMS without GEM won't work.)
You're probably a BSD guy. Which is fine. Nothing wrong with that. Unfortunately, your upstreams have shown a rather lackluster interest in actually participating in these DRM changes. While there are a few guys working on porting this stuff, most of us are not BSD guys and are certainly not required to make it work across kernels. We're trying to make it as open and clean as possible, though. (DRM is actually built from a shared core that has Linux and BSD wrappers.)
And really, you don't want drivers in X. That's what we've done for a long time, and frankly, it sucks. Poor memory management, poor direct rendering. Lock contention, kernel sareas, GETPARAM/SETPARAM insanity. Each new feature requires kernel modifications and new ioctls which then have to remain working for a decade despite Mesa being the only real consumer of those ioctls. (nVidia doesn't use our DRM. They got this stuff working a long time ago on their own code. That's right, the closed-source drivers do this.)
Hynix has a plant in my hometown of Eugene, Oregon.
Okay, fine. They *had* a plant. It's shut down. Y'know why? They just decided it wasn't profitable. They got the city officials to okay tax breaks, they got everybody to bend over backwards to let them get away with putting an incredibly cheap (comparatively) factory set up and running. And now they're leaving, before any of the long-term benefits of their work really come back to the community (read: tax break expiration. Even with the five- and ten-year breaks, they still paid more taxes than anybody else in the area.)
The galling thing is, if they were serious about overbuilding factories, then they should have considered that eight years ago, when WinXP was just coming onto the market and there were no ridiculous signs of overdemand. Vista boxes have shipped with 2-4 GB of RAM, cell phones and PDAs have more internal space; the demand for this stuff should be right on target with Moore's Law.
Fuck Hynix, and fuck their pals too. They're getting more business than ever, and yet they think they can just whine and moan? Bah.
Unfortunately, I can't remember the exact chipsets, but some Ethernet cards are capable of WoL from any valid IP they had before being shut down, and some are capable of WoL from MAC address only, ignoring IP. This means that, if you set up your firewall right, you can WoL from the WAN/Internet with no problems.
I personally leave my firewall on all the time, and my fileserver suspends itself after a few hours of boringness. I have a handful of knocks on the firewall that can shutdown, restart, wake up, or sleep the fileserver.
In addition to your other replies, don't forget about Lincoln. Suspension of habeas corpus during wartime; isn't that one of the things we've criticized Bush for?
Hi, I joined X.org after ATI released docs, and helped add support for an entire line of video cards, including the one I'm using right now to type this.
Your defeatism is kinda silly, if you stop and consider how much work we've done in the open source world.
Personally, Reiser4 can go far, far, away, and never come back. Every time I've badmouthed it, and somebody's replied, "Oh, I guarantee you it gets better," I think back to the four different times that I tried it, and the four different times I lost all my data.
Of course, if I had just gone up into the hills, I probably would have found my data sitting in a shallow grave, but that didn't occur to me at the time...
Buffer clears always take time. CUDA doesn't need to write to any color buffers, so yes, it will be faster. I was talking about OpenGL calls, not CUDA calls.
Even so, the point is "Drivers can't actually feed the GPU at maximum speed in real applications," and I think it's still a valid point.
If you'd like CUDA to be available for all platforms, write a compiler for Gallium for it. Either compile CUDA to LLVM IR, or compile it to TGSI, and all Gallium-aware cards will be able to run it.
Depends on the kind of precision you want. Also the big limiting factor in these kinds of apps is actually feeding the GPUs. Y'know that little glxgears test app that everybody uses to test their FPS? The glxgears framerate is actually just the number of times per second that the driver can properly set up the card, prepare a display list, flush it to the card, and then swap the buffers. The card usually can go much faster than that.
(And, of course, the point is, glxgears is probably the fastest thing that you'll be able to ever run on that GPU!)
I've had this handle for a very long time, and I keep it now for mostly historical reasons. On the other hand, I don't mind people knowing that my real name is Corbin Simpson, that I'm a student in Oregon, or that I attend Oregon State University.
I certainly wouldn't ever disclose a fake name, or ever admit that it was false.
To be fair, a large part of why Intel graphics suck on Windows has to do with architectural issues on the Microsoft end of things. If Intel chips were lacking the raw power for Glass, I suppose they wouldn't be able to run Compiz either, but here I am, typing this from an Eee with Compiz Fusion enabled on my Intel i915-based chipset.
At the risk of stating the obvious...
Not to say that Intel's a victim here, but perhaps the raw numbers for "Vista Capable" are just too high.
Unless, of course, you feel like writing the support into the open drivers. I've got other things to do, as do most of my compatriots.
Not to be insulting, but OpenGL 2.0 support, DRI2, KMS, are all of much higher importance than yet another GPGPU language, especially since Radeons are still not on the Gallium system yet.
Slashdot Mirror
Since you're a Mesa/X.org dev, maybe you can answer this.
Why has there apparently been no interest in implementing XvMC?
XvMC requires very specific hardware support (which AMD hasn't been able to get legal clearance for) or complex shaders. The latter is already in the Gallium tree, but we don't have a working driver that can run it yet.
Also, each of the big three has gone ahead and crafted their own goddamn standard. Intel's VAAPI, AMD's XvBA, and nVidia's VDPAU. Eventually, at least one of those will probably be added to Gallium. (Probably Intel's pick, since they put so much money into this.)
~ C.
Based on what's been on IRC in the past few hours.
Q: Wait, what?
A: Code for radeonhd and the kernel providing acceleration for Radeon HD 2400 and newer. Kernel parts are already pretty much integrated; radeonhd is integrated as well, although stuff still needs to be copied to radeon.
Q: So what does this mean for the user?
A: EXA means faster GUI responsiveness. Xv means fast video. Kernel DRM is the basis for all acceleration unification (OpenGL, etc.)
Q: Speaking of OpenGL...
A: Lawl, no. Not for another few months. Most of the code we're gonna write will target Gallium, so--
Q: Gallium?
A: Gallium is the next generation of GPU acceleration. Once we get drivers ready, it'll be awesome. Linky to TG: http://www.tungstengraphics.com/wiki/index.php/Gallium3D
Q: So this is just docs and some basic code?
A: Nope, no docs. AMD couldn't agree on docs before their vacation time, so I guess we'll see those in a month or so. On the other hand, we've got enough here to do a lot of stuff. It'd be nice if we had more devs, though. :3
Q: So why is there only code for radeonhd? Will radeon support this too? Why two separate drivers?
A: The reason for two separate drivers is a very long and largely silly story. I don't feel like repeating it, and I probably couldn't tell it fairly anyway.
I'll get radeonhd code ported over to radeon once my vacation's over, assuming nobody does it sooner. I can't do the HDMI audio setup without testing hardware, though; does anybody want to donate an HDMI audio-enabled monitor? :3
~ C.
Graphics stuff must be in the kernel at some level. The reason for GEM is that the entire system needs to have unified memory management for GPUs, just like for CPUs.
Also each GEM-capable driver has to support legacy mode. Linus was *very* clear on that point. So, starting with 2.6.29, each KMS or GEM driver supports non-KMS and non-GEM mode. (Some drivers, like the Radeon drivers, are all-or-nothing, so running KMS without GEM won't work.)
You're probably a BSD guy. Which is fine. Nothing wrong with that. Unfortunately, your upstreams have shown a rather lackluster interest in actually participating in these DRM changes. While there are a few guys working on porting this stuff, most of us are not BSD guys and are certainly not required to make it work across kernels. We're trying to make it as open and clean as possible, though. (DRM is actually built from a shared core that has Linux and BSD wrappers.)
And really, you don't want drivers in X. That's what we've done for a long time, and frankly, it sucks. Poor memory management, poor direct rendering. Lock contention, kernel sareas, GETPARAM/SETPARAM insanity. Each new feature requires kernel modifications and new ioctls which then have to remain working for a decade despite Mesa being the only real consumer of those ioctls. (nVidia doesn't use our DRM. They got this stuff working a long time ago on their own code. That's right, the closed-source drivers do this.)
Sorry for ranting, but that's the way it is.
Nope. Go check Moore's Law. We won't be switching until 2050 or so.
Hynix has a plant in my hometown of Eugene, Oregon.
Okay, fine. They *had* a plant. It's shut down. Y'know why? They just decided it wasn't profitable. They got the city officials to okay tax breaks, they got everybody to bend over backwards to let them get away with putting an incredibly cheap (comparatively) factory set up and running. And now they're leaving, before any of the long-term benefits of their work really come back to the community (read: tax break expiration. Even with the five- and ten-year breaks, they still paid more taxes than anybody else in the area.)
The galling thing is, if they were serious about overbuilding factories, then they should have considered that eight years ago, when WinXP was just coming onto the market and there were no ridiculous signs of overdemand. Vista boxes have shipped with 2-4 GB of RAM, cell phones and PDAs have more internal space; the demand for this stuff should be right on target with Moore's Law.
Fuck Hynix, and fuck their pals too. They're getting more business than ever, and yet they think they can just whine and moan? Bah.
Like everything else in the open-source world, we move in increments. Don't expect breakthroughs, expect progress. :3
http://nouveau.freedesktop.org/wiki/FeatureMatrix
http://wiki.x.org/wiki/RadeonFeature
~ C.
I just got done with finals. Gimme a few days to get my head back into a known working state. :3
Then again, I guess nvidia & fglrx alone will be enough to make a majority of users.
We're working on that, by the way.
Unfortunately, I can't remember the exact chipsets, but some Ethernet cards are capable of WoL from any valid IP they had before being shut down, and some are capable of WoL from MAC address only, ignoring IP. This means that, if you set up your firewall right, you can WoL from the WAN/Internet with no problems.
I personally leave my firewall on all the time, and my fileserver suspends itself after a few hours of boringness. I have a handful of knocks on the firewall that can shutdown, restart, wake up, or sleep the fileserver.
And http://dri.freedesktop.org/wiki/DRM as well.
Note to self: Don't shave for the week before getting driver's license renewed. Also wear old, ugly glasses instead of current glasses.
In addition to your other replies, don't forget about Lincoln. Suspension of habeas corpus during wartime; isn't that one of the things we've criticized Bush for?
http://www.freedesktop.org/ is the link. Was that really so hard?
Hi, I joined X.org after ATI released docs, and helped add support for an entire line of video cards, including the one I'm using right now to type this.
Your defeatism is kinda silly, if you stop and consider how much work we've done in the open source world.
Personally, Reiser4 can go far, far, away, and never come back. Every time I've badmouthed it, and somebody's replied, "Oh, I guarantee you it gets better," I think back to the four different times that I tried it, and the four different times I lost all my data.
Of course, if I had just gone up into the hills, I probably would have found my data sitting in a shallow grave, but that didn't occur to me at the time...
In certain parts of Africa, the AIDS rate is quite high, which means that even 99% accuracy is still useful enough to use for preliminary screening.
Buffer clears always take time. CUDA doesn't need to write to any color buffers, so yes, it will be faster. I was talking about OpenGL calls, not CUDA calls.
Even so, the point is "Drivers can't actually feed the GPU at maximum speed in real applications," and I think it's still a valid point.
If you'd like CUDA to be available for all platforms, write a compiler for Gallium for it. Either compile CUDA to LLVM IR, or compile it to TGSI, and all Gallium-aware cards will be able to run it.
Depends on the kind of precision you want. Also the big limiting factor in these kinds of apps is actually feeding the GPUs. Y'know that little glxgears test app that everybody uses to test their FPS? The glxgears framerate is actually just the number of times per second that the driver can properly set up the card, prepare a display list, flush it to the card, and then swap the buffers. The card usually can go much faster than that.
(And, of course, the point is, glxgears is probably the fastest thing that you'll be able to ever run on that GPU!)
I've had this handle for a very long time, and I keep it now for mostly historical reasons. On the other hand, I don't mind people knowing that my real name is Corbin Simpson, that I'm a student in Oregon, or that I attend Oregon State University.
I certainly wouldn't ever disclose a fake name, or ever admit that it was false.
Ignore the notice. It's clearly not properly formed, and should provide great evidence, should Toyota decide to start suing this guy.
To be fair, a large part of why Intel graphics suck on Windows has to do with architectural issues on the Microsoft end of things. If Intel chips were lacking the raw power for Glass, I suppose they wouldn't be able to run Compiz either, but here I am, typing this from an Eee with Compiz Fusion enabled on my Intel i915-based chipset.
At the risk of stating the obvious...
Not to say that Intel's a victim here, but perhaps the raw numbers for "Vista Capable" are just too high.
Yeah, no, you're the only one.
Unless, of course, you feel like writing the support into the open drivers. I've got other things to do, as do most of my compatriots.
Not to be insulting, but OpenGL 2.0 support, DRI2, KMS, are all of much higher importance than yet another GPGPU language, especially since Radeons are still not on the Gallium system yet.
~ C.
Nice nick. :3
Can't be harder than programming a graphics card.