Gallium3D VDPAU On Radeon Starts Working

[Deathsimple]

There is a patch for draw_instanced on Marek branch:

http://cgit.freedesktop.org/~mareko/mesa/log/?h=r300g-draw-instanced

Dunno about its state.

Thanks for the tip, but I tried this patch-set and it seems to only cause a system hangup, maybe the patches aren't complete (yet).

But even with an instanced drawing implementation in r300g this seems to be only some sort of emulation, because the hardware simply doesn't supports it. The end result is worse performance for the decoder.

For the motion vectors I could use an texture instead of a vertex buffer, but for the dct block list the texture size limit would also limit the picture size to something like 360x360, which isn't acceptable.

What I basically need is a attribute per primitive instead of per vertex (or it will increase the memory bandwith needed by 4).

Just give me a couple of days to thing about it and find a working solution.

[darkbasic]

z-scan, quantification and mismatch control is also implemented and working (at least with r600g).

Awesome, keep up the good work. I am particularly interested because I will have to use an old athlon64 single core with an RV610 card for the next months

[bridgman]

z-scan, quantification and mismatch control is also implemented and working (at least with r600g).

That is impressive. I had been thinking of just MC/IDCT/Deblock on the shaders, but you've gone way past that already.

[yotambien]

That is impressive. I had been thinking of just MC/IDCT/Deblock on the shaders, but you've gone way past that already.

The profecy has it that once every 7 Mars oppositions a new chosen hacker will arise from the mud of Phoronix posts and bring the state of open source drivers to new heights.

[Deathsimple]

That is impressive. I had been thinking of just MC/IDCT/Deblock on the shaders, but you've gone way past that already.

z-scan and quantification were easy to do, and z-scan gives quite a performance boost because of the better memory layout.

A major stage that?s still missing is Deblock, because that's only optional for mpeg2.

[pingufunkybeat]

Christian, what are the major milestones needed to add h264 support? I'm assuming that much of the stuff can be reused (MC, deblocking, etc.)

[Deathsimple]

Christian, what are the major milestones needed to add h264 support? I'm assuming that much of the stuff can be reused (MC, deblocking, etc.)

I wouldn't start with h264, mpeg4 (divx, xvid) would be the next logical step.

For this we need at least a new bitstream decoder, and at minimum quite some changes to the mc stage.

h264 also defines some new form of transformation which needs to be implemented, but to be honest I actually doesn't know much about how h264 works.

[curaga]

/me does not understand, if the vdpau one already does more than xvmc, why is it reported as slower than xv?

[Deathsimple]

/me does not understand, if the vdpau one already does more than xvmc, why is it reported as slower than xv?

Most people are currently only testing the yuv->rgb and scaling part of vdpau, since this works with all supported codecs.

This stages of the rendering pipeline are just a bit slower than Xv because of the debugging overhead. If you compile the state tracker without debugging support, it should be slightly faster because we don't need to call the x server to display every frame.

But the real improvement comes only when you enable more decoding stages, with mplayer provide the "-vc ffmpeg12vdpau" option for example.

[nevado]

MythTV / VDPAU / r600g

Looks like some people have MythTV working using VDPAU over r600g now, albeit playback is a bit jerky:

http://www.gossamer-threads.com/lists/mythtv/dev/482148