Questions about the HD4870/HD4850

[bridgman]

[*] Does the video tearing only happen while using compiz or any other compositor? Even though that would still be unfortunate but not such a huge problem by itself because I don't use any of those yet (because of my crappy card and instabilities). Or put the other way: does the video tearing always happen or is there a pattern one can easily avoid? (like not using a 3d desktop)

I think (low confidence info but worth a try) the issue is that we have a vsync option for OpenGL but not for TexturedVideo. If so, then one option would be to play back through the OpenGL path with vsync enabled. Haven't tried it myself but I think I remember seeing a post that it worked.

[*] @bridgman: in some thread, you clearly stated that there are some problems with wine and fglrx. Could you please elaborate on this further? Is there an ETA for an fix or is this low priority?

Wine is kind of a non-standard OpenGL app and so it needs to work around driver implementation specifics to a greater extent than other apps. I don't think this has been done for our new driver stack yet. There are also some reported regressions with Wine in the 8.6 and 8.7 drivers -- we are trying to find out if those are actual driver bugs or just where we changed something unrelated to the OpenGL API which Wine doesn't like. I'm not the Wine expert though.

[*] @bridgman: you stated the plan is doing 6xx and 7xx acceleration in parallel. I haven't been following the radeonhd development very closely. Is there already some work done on this or is something expected for this year in this regard...?

Until I have time to get the specs turned into something we can release publicly work is proceeding in an NDA depot accessible to specific devs from AMD, Novell and Red Hat. We are doing 6xx and 7xx work in parallel and most days are actually a bit further ahead on 7xx because we have better sample code to work with.

[*] @bridgman: even though you cannot state an ETA or anything like it but could you at least give us some clue what priority xorg 1.5 support has?

Roughly, priority is lower than evil bugs, new GPU support and new kernel support but higher than most other things.

[*] What OpenGL revisions are supported through fglrx and will be supported through radeonhd? Maybe any word on the upcoming 3.0 standard? (doing OpenGL programming myself, this is actually quite important)

I think it's 2.1-ish today although there I think there were issues reported against pointsprites, not sure if those are a 2.1 requirement. No comment on 3.0 before Siggraph, not sure what will happen after.

[RealNC]

I think (low confidence info but worth a try) the issue is that we have a vsync option for OpenGL but not for TexturedVideo. If so, then one option would be to play back through the OpenGL path with vsync enabled. Haven't tried it myself but I think I remember seeing a post that it worked.

It works. Problem is, you're stalling mplayer decoder that way; for HD 720p video that means you'll need a strong CPU and for 1080p a Cray super computer.

[RobotMarvin]

... the issue is that we have a vsync option for OpenGL but not for TexturedVideo.

I see. Video playback through OpenGL is still not very sophisticated and the only player I know of which pretty much works in this regard is mplayer- xine-lib (and thus all programs using it) or vlc are still rather buggy with OpenGL playback.

Is there any work currently on getting vsync support for textured video? Maybe some hint...? :-)

... There are also some reported regressions with Wine in the 8.6 and 8.7 drivers -- we are trying to find out if those are actual driver bugs or just where we changed something unrelated to the OpenGL API which Wine doesn't like.

Okay, so I shouldn't expect wine working any time soon if I get a HD4870, right? But knowing that it's been worked on is comforting.

We are doing 6xx and 7xx work in parallel and most days are actually a bit further ahead on 7xx because we have better sample code to work with.

That sounds great. So 2d/3d accelerated support in radeonhd shouldn't be too far away actually. Hopefully sometime this year.

Roughly, priority is lower than evil bugs, new GPU support and new kernel support but higher than most other things.

But it's coming sometime this year or if put the other way: once 1.5 is officially released, there will be support for it rather soon, right?

I think it's 2.1-ish today although there I think there were issues reported against pointsprites, not sure if those are a 2.1 requirement. No comment on 3.0 before Siggraph, not sure what will happen after.

So fglrx is currently OpenGL 2.1 and radeonhd should be 2.1 too as that's what Mesa3d 7.x is advertising. Are there plans to move to Gallium3d once it's progressed a bit more...?

Thanks bridgman and everyone else for your very kind support btw!

[bridgman]

So fglrx is currently OpenGL 2.1 and radeonhd should be 2.1 too as that's what Mesa3d 7.x is advertising.

Mesa is at 2.1 with software rendering but support with hardware rendering depends on the hardware-specific code -- believe it's "just under 1.4" for the ATI/AMD GPUs so that is what you would get with both radeon and radeonhd.

Are there plans to move to Gallium3d once it's progressed a bit more...?

Definitely. We just want to get basic support up with the existing Mesa code that everyone knows so we aren't fighting the GPU and the new driver framework at the same time.

Fighting the GPU is hard enough

[RobotMarvin]

... believe it's "just under 1.4" for the ATI/AMD GPUs so that is what you would get with both radeon and radeonhd.

Ok that's rather bad being stuck to OpenGL < 1.4 while using the open drivers because I do GL programming myself. :-( I guess there is no work in this area getting the support up to date? Or is this scheduled for the big move over to Gallium3d which would be almost equally bad because I guess Gallium3d has still a long way to go before it sees day light.

Fighting the GPU is hard enough

:-)

I guess you jumped over two questions intentionally to not violate your "no comments on upcoming features until they're ready"-policy what I totally respect btw. But nevertheless it would really be great to know if there anyone is working on proper vsync support for textured video and if one can expect support for xorg server 1.5 at least shortly after its released?

[bridgman]

There is work going on now to add OpenGL features -- most of the discussion is on the "#radeon" channel right now. MostAwesomeDude and nha are the primary guys pushing the current support ahead, and they (nha mostly, I think) have also been rewriting some of the code to make it more extensible and to make transition to Gallium easier.

Going much further with OpenGL also needs a good in-drm memory manager and that work is just happening now. I think memory management, DRI2 and Gallium stabilizing will all happen about the same time (fairly soon) and at that point everyone will hop over to using Gallium for the HW-specific bits of Mesa. It's not that GL2.0 "comes for free" with Gallium, just that implementing the support over Gallium seems like a good idea.

re: vsync support for textured video, the general feeling seems to be that having the compositor sync to vblank is the best approach. I *think* that needs a compositor change (Compiz, Metacity, Kwin etc..) first but I'm not sure. The problem is that the playback chain is quite different depending on whether or not you are running through a compositor -- in one case the TexVid driver should do the syncing while in the other the compositor does the syncing and TexVid has to handle flow control and frame dropping/doubling to deal with refresh rate mismatches.

Vblank support in drm is still at a pre-production stage as well -- you might want to follow the #dri-devel logs for more details there.

[RobotMarvin]

There is work going on now to add OpenGL features -- most of the discussion is on the "#radeon" channel right now.

Great news. I haven't realized so much was happening behind the scenes. It's a pitty that there is no special AMD/ATI Open Source page that tries to compile everything that's been happening for a given week and posts a summary. Or at least gives a good overview over the current state of things. That might also draw new developers to the project and help devs/users in finding the appropriate informations they are looking for. And besides- it would be a nice showcase for AMD/ATI.

re: vsync support for textured video, the general feeling seems to be that having the compositor sync to vblank is the best approach.

I understand that there are still vsync issues while using a compositor. I don't know if nvidia is any better there. Nevertheless I could live with that until those are fixed because there is a good workaround: don't use a compositor. But I was more interested if there is work going on for adding proper vsync support to the textured video engine while not running through a compositor because I've heard people complaining they are having video tearing even without using a compositor. I guess it's now some shader code that replaced the legacy 2d and video engine, right?

[bridgman]

We are going to set up some kind of page (probably a wiki on x.org) for this but I don't want to spend time on it until we have 6xx 3d engine work a bit further along. It would definitely help. Then again, tirdc and Phoronix do a pretty good job too

We probably need vsync on both composite and non-composite paths -- pity the implementations are completely different ;(

Yeah, textured video basically replaces the video processing block built in the older overlay with shader code (actually it's really the texture engine doing all the work, the shader just says "fill this triangle with this texture". The nice thing is that the output can go through a compositor rather than being mixed in by the display block, which is what happesn with overlay.

[Fixxer_Linux]

Bridgman, a simple question : in windows, some players do use the hardware acceleration for decoding H264.
Is this functionnality implemented for linux in some way ? If yes, how to use it ? If no, is this implementation "under construction" or no ?
I'm just talking of decoding H264. I got a AVCHD camcoder and I'd like to know if someday I'll be able to read my rushes on my PC. I'm not talking about cracking the blu-ray protection, which I know has already being done.

[bridgman]

Fixxer_Linux, we are not accelerating video decode under Linux today. As for the future, sorry but that has to fall into the class of "we do not comment on unreleased features or functionality".

Is the problem today that even with Xv accelerating the rendering your CPU is not able to keep up with the decoding effort (I smell laptop ) ?