If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
They just added TexturedVideo acceleration for many of the recent cards (R300, R400, R500, RS690) to the xf86-video-ati driver ("radeon"), so Xv should be working on many of the previously "broken" cards in some fashion in the next release. How well it works remains to be seen, of course.
It also supports R100 and R200 for those of you will old cards
I think you're underestimating the opensource community (look at the hand-optimized assembly code in Linux). The reason noone's doing any wild tweaking now is because there's practically no need to do so (scratch the itch, remember?). However, as soon as there are high-performance games/3D apps for linux, which are WIDELY used, people will get cracking at the radeonhd or whatever driver to see if they can come close/beat fglrx.
I think he's underestimating us as well...but it's as much a vicious cycle as anything else. We don't have anywhere near as much 3D stuff as we ought to because the 3D support was suboptimal in many ways. And if I had better resources and I didn't have the LGP stuff to do, I'd probably be working on driver coding like I did with the UtahGLX stuff.
How tightly is the DRM functionality bound to other UVD (h264 acceleration seems to be the "most wanted") functions - that is, even if disclosinng docs would compromise DRM, would the source code itself compromise it as well?
So far, yes. Even initializing the UVD is a problem.
If the source wouldn't compromise DRM, would it be possible to have the missing xv-* functionality added to the opensource driver through DAAMIT developers, OR outside parties under NDA agreements?
worst-case scenario - none of the above is possible. Let's say someone REs the closed driver (either windows or fglrx) and writes a patch for the opensource driver which would bring the xv-* functionality - would this patch be accepted into the driver? What I'm worried about is yet more fragmentation, should the "patched" driver become succesful (don't believe me? look at via vs. unichrome vs. openchrome - not entirely the same thing - the code was there, but it was ripped out - but close enough)
Windows would be fairly hard to RE, and the risk of RE'ing a Linux implementation of UVD support is one of the reasons that Linux video support tends to lag behind Windows support. In general, the distro developers would have to stay away from RE'ed code which the HW vendors were not willing to live with, so the driver probably would have to fork.
I have to stress that we're dealing with a big stack of hypotheticals here. We aren't going to be looking hard at the video options until 2Q08, and until then all I can tell you is what we know today.
I think he's underestimating us as well...but it's as much a vicious cycle as anything else. We don't have anywhere near as much 3D stuff as we ought to because the 3D support was suboptimal in many ways. And if I had better resources and I didn't have the LGP stuff to do, I'd probably be working on driver coding like I did with the UtahGLX stuff.
I'm not saying you guys don't have the skills and the interest, just that practically speaking nobody has the time to spend on it. I know a number of devs who *could* do great work on a gaming-oriented high performance open source 3D driver but so far all of them feel that there are other, higher priorities for them to work on with the time that they do have available.
I think he's underestimating us as well...but it's as much a vicious cycle as anything else. We don't have anywhere near as much 3D stuff as we ought to because the 3D support was suboptimal in many ways. And if I had better resources and I didn't have the LGP stuff to do, I'd probably be working on driver coding like I did with the UtahGLX stuff.
I'm not saying you guys don't have the skills and the interest, just that practically speaking nobody has the time to spend on it. I know a number of devs who *could* do great work on a gaming-oriented high performance open source 3D driver but so far all of them feel that there are other, higher priorities for them to work on with the time that they do have available.
Uhh, that wasn't me who said that, but does address what I was asking, so whatever...
...the risk of RE'ing a Linux implementation of UVD support is one of the reasons that Linux video support tends to lag behind Windows support.
Well that is truly pitiful, I thought REing was legal?! And hardware vendors need to remember that it's the software that sells your hardware repeatedly - unsuspecting customers may buy a piece of hardware once, but as they find the software sucks/doesn't deliver the hardware features, they won't fall for the trick again and WILL do proper research next time around, likely circumventing that vendor. But then again, since X11 driver features "only" affect the experience of *nix-using customers, we're back at the chicken-vs-egg problem of Linux desktop usage share.
So the content mafiaa is effectively pressing hardware vendors to cripple the consumer's experience and hardware vendors don't bite - what has this world come to?..
I realize it's WAY too late for DAAMIT (or anyone else aboard, for that matter) to back out of AACS. And, short of the GPL-ed OpenGraphics project miraculously becoming widely used on the desktop (yah, right...), I don't see a way this could be effectively opposed (well maybe if consumers turned back into customers, but that's wishful thinking).
So far, yes. Even initializing the UVD is a problem.
Source would be a problem, unfortunately.
Windows would be fairly hard to RE, and the risk of RE'ing a Linux implementation of UVD support is one of the reasons that Linux video support tends to lag behind Windows support.
I expect we'll get (some amount of) open-source GPU accelerated h.264 through framewave on CAL. If we had that, how much would we really care about the UVD?
Well that is truly pitiful, I thought REing was legal?!
RE-ing is legal in some countries but not others. DMCA (and similar legislation in other countries) put limits on reverse engineering in areas where RE-eing would put copy protection technology at risk.
And hardware vendors need to remember that it's the software that sells your hardware repeatedly - unsuspecting customers may buy a piece of hardware once, but as they find the software sucks/doesn't deliver the hardware features, they won't fall for the trick again and WILL do proper research next time around, likely circumventing that vendor.
I think you would have to circumvent all of the major vendors today - none of us are offering open source support for the most modern HD decode hardware, although the OpenChrome drivers for Via seem to be closest. We are presumably all looking for ways to change this.
The only thing different about AMD here is that we're actually willing to be open and talk to our customers about how copy-protection obligations affect our decisions -- I would hate to see Linux users punish us for that.
Comment