Good *GOD* what a rush.
Open source driver implementing MPEG2 and h264 acceleration?
This is why I now buy AMD and ATI products instead of Intel and nVidia.
OK, I know, Intel are doing it to. But they're expensive! ^.^
Even if it doesn't happen with UVD2.
SO EXCITED!!! 8D 8D 8D
> Good *GOD* what a rush.
> Open source driver implementing MPEG2 and h264 acceleration?
Huh? I can't find an announcement anywhere.
Great news if it is true.
The gallium frontend to XvMC, I guess
> The gallium frontend to XvMC, I guess
Assuming the SoC project goes well.
But... then we need gallium for ATI. Is anyone working on that?
Two parts to the answer :
1. There are some pre-requisites which need to be at least partially in place for Gallium. A modern memory manager in drm is the first priority (Dave Airlie is working on that) and I believe DRI2 will be needed as well -- and DRI2 also needs the new memory manager.
2. In terms of development priorities, we are aiming to get at least basic 3d functionality running on "classic mesa" before beginning implementation on Gallium, so that developers are only faced with the challenge of learning the chips and not learning a new environment & API at the same time. This definitely made sense for 5xx but 6xx/7xx will probably be the last generation where we get things running on "classic Mesa" before Gallium.
Documentation and community knowledge for 5xx and earlier is good enough to support Gallium work today; glisse did some preliminary work a few months back, and MostAwesomeDude is eyeing Gallium now. I expect that work on both DRI2 and Gallium will ramp up over the next month or so as (a) we make more progress on 6xx/7xx 3d and (b) Dave's work on a new memory manager gets a bit further along.
Memory manager => DRI2 => Gallium
Memory Manager => Kernel Modesetting
Work on the above initiatives can start in parallel to a certain extent, but they really need to "come up" in the order above and certainly need to finish in the order above.
So... real soon now
Do you think that the move to Kernel Modesetting is going to lighten the load on the Linux kernel? We are actively pushing more into the kernel while Windows is trying to pull things out. There are religious wars over drivers in userland/kernel so let's avoid it here....
Originally Posted by TechMage89
When kernel modesetting kicks in, the X developers, FB developers and other random display developers are all going to have to find a way to support the same OSS driver. If we end up with 3 kernel based graphics drivers, then I don't believe we have improved the situation.
Video encoding is probably best suited to OpenCL (I will use that term instead of CAL/OpenCL/CUDA/Shader/whatever), since in general that is done away from the consumers desktop.
Originally Posted by chaos386
The OpenCL based solutions scale their performance with the number of shader cores that are available. This means the effectiveness will scale with hardware.
The Proprietary driver has used shader based video (only colorspace conversion/attributes) since R5xx, and shader based 2D since R6xx, and has some people have been playing with RENDER acceleration (TexturedVideo, Textured2D and TexturedXRender). It does work, but it does present a number of technical issues that need to be resolved, and realistically we focus a lot more on 2D acceleration than video.
I am absolutely in support of the GP-GPU approaches to computing problems (including xvmc/h264 decode), but just be aware that the performance of those solutions will scale with hardware.
Last edited by mtippett; 07-16-2008 at 03:38 PM.
But what good does that do when the HW makers' contract terms with the "content protection" cartels and with Microsoft apparently explicitly forbid them from enabling their video-dedicated hardware to be used with free software?
Originally Posted by glisse
(And has anyone discussed the antitrust implications of Microsoft and the HW makers signing secret agreements that say certain HW functionality shall be off-limits to Microsoft's chief competitors?)