Yo (ho ho and a bottle of rum)

newer
[Bug 26702] New: radeonhd window...

Michael Cree

25 Jan 2010 25 Jan '10

07:46

Hello list I've been incommunicado for a while. Overloaded with work commitments and had a non-working X server on my home computer architecture (Alpha) for quite a while. But now the X server (v1.7.1) works on Alpha, and hopefully I may have a little bit of spare time, so might be able to participate in the radeonhd community again. Looking at the commits for the last few months there seem to be noticeably fewer commits to the radeonhd driver than the ati driver. Would it be a valid perception that efforts to continue developing the radeonhd driver have dried up a little recently? (Or is that an artefact of radeonhd supporting only recent radeon cards?) Is there any intention to get KMS into radeonhd? That is something I am planning to test over the next couple of weeks but I note that I am limited to the ati driver. I had indicated an interest in implementing the DCT and motion estimation on the shader units to provide hardware acceleration of MPEG video some time back. I have been far too busy and haven't even done any background work whatsoever to learn about the shader units. I presume this is still up in the air and that there is no serious effort yet to implement such features, right? Cheers Michael. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Show replies by date

Alex Deucher

25 Jan 25 Jan

21:12

On Mon, Jan 25, 2010 at 2:46 AM, Michael Cree wrote:

...

Hello list

I've been incommunicado for a while. Overloaded with work commitments and had a non-working X server on my home computer architecture (Alpha) for quite a while. But now the X server (v1.7.1) works on Alpha, and hopefully I may have a little bit of spare time, so might be able to participate in the radeonhd community again.

Looking at the commits for the last few months there seem to be noticeably fewer commits to the radeonhd driver than the ati driver. Would it be a valid perception that efforts to continue developing the radeonhd driver have dried up a little recently? (Or is that an artefact of radeonhd supporting only recent radeon cards?)

Is there any intention to get KMS into radeonhd? That is something I am planning to test over the next couple of weeks but I note that I am limited to the ati driver.

I don't know of any concrete plans to add kms support to radeonhd (although it's been mentioned a few times), but I'm not sure the work is worth the effort. The main differentiating factor between radeon and radeonhd is the modesetting code. When KMS is active, radeon is basically just kms ioctls for modesetting and memory management and the accel code. As the accel code is very similar between radeon and radeonhd, the drivers would end up looking just about identical. In my opinion, time would be better spent improving kms or working on gallium.

...

I had indicated an interest in implementing the DCT and motion estimation on the shader units to provide hardware acceleration of MPEG video some time back. I have been far too busy and haven't even done any background work whatsoever to learn about the shader units. I presume this is still up in the air and that there is no serious effort yet to implement such features, right?

There's been some work to implement video decode acceleration in mesa via gallium. In that case, video decode acceleration would just work on any gallium driver. Currently the r300 gallium driver (for r3xx-r5xx radeons) is fairly far along, but the r600 one has barely started; mostly just some experiments. The advantage of gallium is that new front ends can be added to support acceleration of new APIs without requiring a new driver for each one. There is already work to support OpenGL, OpenCL, OpenVG, EXA, and video decode on top of gallium. Alex

...

Cheers Michael. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Christian König

22:50

...

...
I had indicated an interest in implementing the DCT and motion estimation on the shader units to provide hardware acceleration of MPEG video some time back. I have been far too busy and haven't even done any background work whatsoever to learn about the shader units. I presume this is still up in the air and that there is no serious effort yet to implement such features, right?

There's been some work to implement video decode acceleration in mesa via gallium. In that case, video decode acceleration would just work on any gallium driver. Currently the r300 gallium driver (for r3xx-r5xx radeons) is fairly far along, but the r600 one has barely started; mostly just some experiments. The advantage of gallium is that new front ends can be added to support acceleration of new APIs without requiring a new driver for each one. There is already work to support OpenGL, OpenCL, OpenVG, EXA, and video decode on top of gallium. I played around a bit with the XvMC gallium state tracker, but only with

Am Montag, den 25.01.2010, 16:12 -0500 schrieb Alex Deucher: the software rendering stack and just to learn a little bit about the design. IDCT and MC should be pretty easy, IDCT are just a bunch of cos and mul operations, and MC scripted blitter operations. The real tricky part is VLD, i have no clue how this works. Just leave me a note if you got something interesting to test or could explain how VLD works. Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Michael Cree

2 Feb 2 Feb

07:37

On 26/01/10 11:50, Christian König wrote:

...

Am Montag, den 25.01.2010, 16:12 -0500 schrieb Alex Deucher:

...
There's been some work to implement video decode acceleration in mesa via gallium.

IDCT and MC should be pretty easy, IDCT are just a bunch of cos and mul operations, and MC scripted blitter operations.

Yeah, on the surface it's straightforward, but often CPU implementations of the DCT for JPEG/MPEG trade off precision for efficiency by using fixed point or even integer arithmetic. With hardware implementation it might be nice to aim for precision to maintain best quality assuming sufficient speedup? I'm not familiar with shaders; do they provide floating point?

...

The real tricky part is VLD, i have no clue how this works.

VLD? What's that? I'm guessing - variable length decoding? Cheers Michael. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf

12:43

On Feb 02, 10 20:37:22 +1300, Michael Cree wrote:

...

...
IDCT and MC should be pretty easy, IDCT are just a bunch of cos and mul operations, and MC scripted blitter operations. Yeah, on the surface it's straightforward, but often CPU implementations of

On 26/01/10 11:50, Christian König wrote: the DCT for JPEG/MPEG trade off precision for efficiency by using fixed point or even integer arithmetic. With hardware implementation it might be nice to aim for precision to maintain best quality assuming sufficient speedup? I'm not familiar with shaders; do they provide floating point?

Actually, integer arithmetics has only been added *after* floating point was already defined and working :-)

...

...
The real tricky part is VLD, i have no clue how this works. VLD? What's that? I'm guessing - variable length decoding?

Guess so. Anything that requires an inherent serial workflow (Huffman etc.) is truly bad to parallelize, especially in a SIMD array like GPUs. Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Michael Cree

22 Feb 22 Feb

08:48

On 03/02/10 01:43, Matthias Hopf wrote:

...

On Feb 02, 10 20:37:22 +1300, Michael Cree wrote:

...
I'm not familiar with shaders; do they provide floating point?

Actually, integer arithmetics has only been added *after* floating point was already defined and working :-)

Nice. I have students working on FPGA including one who has implemented a hardware accelerated FFT. It is all fixed point as floating point is an expensive luxury in that field! By the length of time I have taken to reply to this you may gather that I am not making much progress on learning about the GPU shaders, etc. I have a couple of other projects that I somehow seem to have been landed with... But I did bump into the libva project due to an announcement on the mplayer project webpage that radeon is now supported. On closer examination (and after I compiled it and tried it without success) it appears only AMD's close-source driver is supported. I was wondering what is the relationship of libva to gallium. Would I be correct in thinking that libva is a separate project with a much more specific aim to implement the hardware assisted video compression/decompression and display that will work within the traditional dri/drm/Xserver structure and that it may not support KMS? Cheers Michael. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

15:21

On Mon, Feb 22, 2010 at 3:48 AM, Michael Cree wrote:

...

On 03/02/10 01:43, Matthias Hopf wrote:

...
On Feb 02, 10 20:37:22 +1300, Michael Cree wrote:

...
I'm not familiar with shaders; do they provide floating point?

Actually, integer arithmetics has only been added *after* floating point was already defined and working :-)

Nice. I have students working on FPGA including one who has implemented a hardware accelerated FFT. It is all fixed point as floating point is an expensive luxury in that field!

By the length of time I have taken to reply to this you may gather that I am not making much progress on learning about the GPU shaders, etc. I have a couple of other projects that I somehow seem to have been landed with...

But I did bump into the libva project due to an announcement on the mplayer project webpage that radeon is now supported. On closer examination (and after I compiled it and tried it without success) it appears only AMD's close-source driver is supported.

I was wondering what is the relationship of libva to gallium. Would I be correct in thinking that libva is a separate project with a much more specific aim to implement the hardware assisted video compression/decompression and display that will work within the traditional dri/drm/Xserver structure and that it may not support KMS?

VA-API is just one of several decode level video APIs (like XvMC or VDPAU). They still need a driver specific implementation to to actually accelerate anything. You could either write a specific backend for your hardware (similar to how the mesa r600 driver is an OpenGL hw backend) or you can write a gallium front end for the video API. The advantage to the gallium approach is that it will work on any gallium hw backend. gallium basically provides a generic API that other APIs can be built on. So you write one backend hw driver for your chip family, and then all gallium front ends (X, OpenGL, OpenCL, OpenVG, XvMC, etc.) should be accelerated. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Michael Cree

2 Feb 2 Feb

07:17

On 26/01/10 10:12, Alex Deucher wrote:

...

On Mon, Jan 25, 2010 at 2:46 AM, Michael Cree wrote:

...
Is there any intention to get KMS into radeonhd? That is something I am planning to test over the next couple of weeks but I note that I am limited to the ati driver.

I don't know of any concrete plans to add kms support to radeonhd (although it's been mentioned a few times), but I'm not sure the work is worth the effort.

Thanks for the comments on KMS and radeonhd. I have tested KMS with a radeon 7000 card and it is not working - Xserver crash in the drm code with a warning message from the kernel at the same time. Obviously this is not the right list to report it -- should I forward a report and logs to the xorg-driver-ati email list?

...

...
I had indicated an interest in implementing the DCT and motion estimation on the shader units to provide hardware acceleration of MPEG video some time back. I have been far too busy and haven't even done any background work whatsoever to learn about the shader units. I presume this is still up in the air and that there is no serious effort yet to implement such features, right?

There's been some work to implement video decode acceleration in mesa via gallium. In that case, video decode acceleration would just work on any gallium driver. Currently the r300 gallium driver (for r3xx-r5xx radeons) is fairly far along, but the r600 one has barely started; mostly just some experiments.

OK, so I should take a look at gallium. I see that on the web there are some documents taking a very general look at gallium, but there seems to be very little describing the internal workings. I presume I am going to have to look at the code to learn about it? Ahh - I see there is a docs directory in mesa/src/gallium. I'll take a look at that. Cheers Michael -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

14:40

On Tue, Feb 2, 2010 at 2:17 AM, Michael Cree wrote:

...

On 26/01/10 10:12, Alex Deucher wrote:

...
On Mon, Jan 25, 2010 at 2:46 AM, Michael Cree wrote:

...
Is there any intention to get KMS into radeonhd? That is something I am planning to test over the next couple of weeks but I note that I am limited to the ati driver.

I don't know of any concrete plans to add kms support to radeonhd (although it's been mentioned a few times), but I'm not sure the work is worth the effort.

Thanks for the comments on KMS and radeonhd.

I have tested KMS with a radeon 7000 card and it is not working - Xserver crash in the drm code with a warning message from the kernel at the same time.

Obviously this is not the right list to report it -- should I forward a report and logs to the xorg-driver-ati email list?

Please file a bug against xf86-video-ati or the radeon drm: https://bugs.freedesktop.org Also, it's probably best to try the latest drm to see if it's already fixed.

...

...
...
I had indicated an interest in implementing the DCT and motion estimation on the shader units to provide hardware acceleration of MPEG video some time back. I have been far too busy and haven't even done any background work whatsoever to learn about the shader units. I presume this is still up in the air and that there is no serious effort yet to implement such features, right?

There's been some work to implement video decode acceleration in mesa via gallium. In that case, video decode acceleration would just work on any gallium driver. Currently the r300 gallium driver (for r3xx-r5xx radeons) is fairly far along, but the r600 one has barely started; mostly just some experiments.

OK, so I should take a look at gallium. I see that on the web there are some documents taking a very general look at gallium, but there seems to be very little describing the internal workings. I presume I am going to have to look at the code to learn about it? Ahh - I see there is a docs directory in mesa/src/gallium. I'll take a look at that.

Corbin has been filling in a lot of gallium documentation recently, so make sure your mesa tree is up to date. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

5183

Age (days ago)

5211

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Alex Deucher
Christian König
Matthias Hopf
Michael Cree