XvMC Comes To xf86-video-unichrome Driver

[libv]

Soooo uuuuhhhhhh,,,,

Hows that.... ummmmm...... documentation coming?

It's still being delayed by me having implemented real modesetting more than two years ago

[libv]

Honestly I'm not a programmer. I really dont know how those things work. Being a radeon user though, and your experience with ATi hardware, and clearly your experience with XvMC would seem like a logical choice.

I guess I could more appropriately phrase my question as "Why implement XvMC in unichrome when it would serve a whole lot more people to implement it in radeon?"

So other hardware should not be cared for?

I started out with unichrome in 2003. I own a very comprehensive set of hardware today. I developed the fundamental concepts of modesetting today on unichrome. And without my work on unichrome, you would not even have a free r500 and up driver today (because then ATI would have gotten away with trying to kill radeonhd before the release), you would be stuck with fglrx and some spare-time attempt at a free driver that was struggling due to a lack of resources and a lack of information.

But really, what does any of this have to do with this topic?

[duby229]

I can probably answer that one... info is available to program the video decode hardware on the Via chip but not on our chip.

Soooo uuuuhhhhhh,,,,

Hows that.... ummmmm...... documentation coming?

[duby229]

???

I implemented unichrome MPEG2 hardware slice decoding acceleration. I wrote a tiny X protocol to feed the mpeg data into the part of the driver that feeds that data into the hardware. The tiny X protocol was not the goal, it was a tool to function as a back-end for the unichrome XvMC client library, and it will not grow beyond this driver.

Why you think this involves other drivers is beyond me.

Honestly I'm not a programmer. I really dont know how those things work. Being a radeon user though, and your experience with ATi hardware, and clearly your experience with XvMC would seem like a logical choice.

I guess I could more appropriately phrase my question as "Why implement XvMC in unichrome when it would serve a whole lot more people to implement it in radeon?"

[libv]

I can probably answer that one... info is available to program the video decode hardware on the Via chip but not on our chip.

Eh? I did not care about implementing just any XvMC support.

But more on that next week on my blog, right now i am waiting for the masses to stop roaring about this important new development.

[libv]

I have to agree with him though. Why implement it in Unichrome? Radeon would have given you a much larger user base for testing, and would have been immediately useful to a whole lot more people.

???

I implemented unichrome MPEG2 hardware slice decoding acceleration. I wrote a tiny X protocol to feed the mpeg data into the part of the driver that feeds that data into the hardware. The tiny X protocol was not the goal, it was a tool to function as a back-end for the unichrome XvMC client library, and it will not grow beyond this driver.

Why you think this involves other drivers is beyond me.

[bridgman]

I can probably answer that one... info is available to program the video decode hardware on the Via chip but not on our chip.

[duby229]

It is compatible with existing XvMC clients. I just question assumptions everywhere and usually find where they are wrong, it's how i am. Also; of course it is limited to this driver, that's how all XvMC drivers are.

I have to agree with him though. Why implement it in Unichrome? Radeon would have given you a much larger user base for testing, and would have been immediately useful to a whole lot more people.

[libv]

So...
He implemented XvMC in a manner that is 1) incompatible with existing assumptions about the implementation of XvMC, and 2) is limited to a driver for hardware that hardly anyone uses.

What exactly does this accomplish?

It is compatible with existing XvMC clients. I just question assumptions everywhere and usually find where they are wrong, it's how i am. Also; of course it is limited to this driver, that's how all XvMC drivers are.

[droidhacker]

So...
He implemented XvMC in a manner that is 1) incompatible with existing assumptions about the implementation of XvMC, and 2) is limited to a driver for hardware that hardly anyone uses.

What exactly does this accomplish?