Those with an AmigaOS 4.2 license (i.e., A1-X1000 owners) naturally have already paid for their updates.
If I'm reading that right (and I am not entirely sure as I may be taking it out of it's intended context), he is saying that these new Radeon HD drivers will be part of AmigaOS4.2 . This would make a lot of sense, but until now (due to the wording of A-Eons announcement) it had sounded like this might not be the case.
NOTE: I should add that this discussion is irrelevant to people buying NEW machines (since it seems that both A-Eon & ACube have licensed this driver for the machines they are selling now). The only question is whether OLD Sam460 users upgrading to AmigaOS4.2 will get the new driver as standard. (And it seems irrelevant to Sam440 users, since I am not aware of any way to get PCI Radeon HD cards, or if they were ever even produced.)
More or less I've come to the same conclusion, i presume that once AmigaOS 4.2 will be released we will have the latest HD driver all togheter, so at the end driver might be included into the standard AmigaOS 4.2 CD or almost i hope that
I have a Sam440 only so one day i would like to install a Radeon HD card on my machine, but at the same time i would prefer to contribute paying for a complete package (OS+Driver) rathen than buy a standalone driver set !
It has been said multiple times that full OpenGL support for RadeonHD cards is coming in AmigaOS 4.2. How exactly would that be possible if the 2D driver wasn't included?
My understanding of the situation, is that the license fee is for those who want to use 5000-6000 series cards right now. Pretty-much everyone buying a new motherboard should be in that group, due to the 4000 series being scarce. Since it's bundled in with new hardware, that shouldn't be a problem for them.
For existing Sam460ex owners, it's up to them if they feel the need to upgrade and are willing to pay. The 0.32 driver is very stable, and works well with Radeon HD 4000 cards. The prime benefit really is being able to use newer cards.
I might as well try to clear up a few other misconceptions... yet again.
Firstly, overlay and 3D support were never promised as a free update. I am very sorry if you bought hardware with that expectation, but this is not an impression cultivated by me. I think that ACube was very clear about what they were providing.
Next, about overlay. In short, it's obsolete technology. I don't even know if the latest Radeon HD cards support it. What I can tell you that the Radeon X1000 series (R500 chipsets) are the last Radeon series whose Linux drivers support overlay. It's a dead end; please forget about it.
Overlay has been superceded by textured video, which does everything that overlay does using the GPU. Unlike overlay, it plays nice with screen-grabbers and composited screens. If you've ever tried grabbing a screen-shot of DvPlayer or mplayer and got a blank area where the video should be, it's because the overlay bitmap isn't actually there. It's overlaid over the top of the screen by special hardware at the last minute.
Textured video is the avenue that I am exploring, but I make absolutely no promises as to when/if that will be ready. Development of something this complex needs to be done one step at a time. In the meantime, the current drivers are very usable even without this feature.
Quick question though - Will the overlay replacement work using the PiP functions transparently?
I don't want to get into details right now, but that is highly unlikely. It doesn't make sense to restrict textured video to PiP windows, and the PiP way of masking.
It has been said multiple times that full OpenGL support for RadeonHD cards is coming in AmigaOS 4.2. How exactly would that be possible if the 2D driver wasn't included?
That was indeed what I was *expecting*, but personal expectations & reality do not always coincide! (And due to A-Eon's "exclusivity" announcement about the driver, a few people on AW.net were predictably claiming that your new driver would not come with OS4.) Thanks for setting the record straight
Quote:
The 0.32 driver is very stable, and works well with Radeon HD 4000 cards. The prime benefit really is being able to use newer cards.
Going by the dates of your blog posts, it looks like v0.32 does not support vertical blank interrupts? So that WaitTOF has to use CPU polling? (Your blog clearly explains the benefit of using interrupts, so I won't repeat that here.)
Quote:
overlay and 3D support were never promised as a free update.
I can't imagine how anyone got that impression either. Especially about 3D, since Gallium 3D (and associated MESA) has always been reported as planned for AmigaOS4.2 (a paid update).
Quote:
Overlay has been superceded by textured video
Something that has been suggested is that OS4 should emulate overlay using textured video, so that old programs using overlays can benefit without needing to be rewritten. But it was also suggested that this would not be possible until 3D support was implemented.
Next, about overlay. In short, it's obsolete technology. I don't even know if the latest Radeon HD cards support it. What I can tell you that the Radeon X1000 series (R500 chipsets) are the last Radeon series whose Linux drivers support overlay. It's a dead end; please forget about it.
The problem is that we have already dvplayer and mplayers which use our current p96-overlays APIs. Yes, overlay is obsolete and should be changed on what you say, but that didn't mean that our current video players will support it automatically, right ? (or you will provide a layer for ?)
What mean, that after you will implement what you say in the drivers, new code in video players should be added. Knowing how everything develops , i have fat doubts that video players will be updated in that terms very short, and so users with radeonHD and Sams will have a slow video playback for a long time in end.
Quote:
Textured video is the avenue that I am exploring, but I make absolutely no promises as to when/if that will be ready. Development of something this complex needs to be done one step at a time. In the meantime, the current drivers are very usable even without this feature.
All the asking about "overlay" from users side its of course not because they want a overlay, but because they want smooth video playback, and for them not so important how it called, and how it done. Just for PIP we already have 2 video players, while we have no video players (and when we will have them no one can say) for textured video. As well, as you say you do not know when you even will add that.
From that perspective i see it like this:
-- SAM users with RadeonHD will have slow video playback for long time (and its very unclear when they will have it right) -- for SAM users currently better user Radeon92xx if they want smooth video playback.
@ChrisH Quote:
Something that has been suggested is that OS4 should emulated overlay using (3D) textures, so that old programs using overlays can benefit without needing to be rewritten. But it was also suggested that this would not be possible until 3D support was implemented.
And adding of layer will be also a slowing done the things in end.
EDIT: Damn, I accidentally edited my old post, rather than replying/quoting it. Bah. Sorry, looks like this post is lost (apart from what people have quoted)
Edited by ChrisH on 2012/6/28 9:06:59 Edited by ChrisH on 2012/6/28 9:07:44 Edited by ChrisH on 2012/6/28 9:09:05
but it does appear that overlays would make it faster or at least less CPU demanding (by removing the need for YUV to RGB conversion?).
I do not know details, but just from my past tests i can say that when i trying to play some video on my peg2 without overlay and it give let's say 80% of cpu loading, with overlay it give about 40-50% of cpu loading. Not radically faster in end, but i think that for sam440 it can make a sense..
Quote:
So you want to have your cake AND eat it? (i.e. overlap emulation without the emulation overhead!!!)
The best way will be write a new mplayer-driver for textured video once Hans will add that , and update DvPlayer in the same way. So no layers and no mess for future. With mplayer it can be easy (i think such kind of driver already done on unix).
Just its all of course time, and can take years, while i have a feel that all sam440/sam460 users have false hopes that they can very soon have overlay or that textured video replacement + new versions of video-players.
Imho better on any question about overlay for RadeonHD answering: better to use radeon92xx for now, because overlay will be replaced by new way of doing things + video player should be updated. So no false hopes will be.
Quote:
Anyway, that overhead is probably just a one-time "setup" overhead, which should not impact actual speed?
We need to see firstly how fast gallium/etc will be on os4. Maybe it will be so fast that layer will make sense, or maybe it will be not so fast, so layer will only make things worse.
I do not know details, but just from my past tests i can say that when i trying to play some video on my peg2 without overlay and it give let's say 80% of cpu loading, with overlay it give about 40-50% of cpu loading. Not radically faster in end, but i think that for sam440 it can make a sense..
See Hans post #5 Quote:
Overlay has been superceded by textured video, which does everything that overlay does using the GPU
Mplayer is a port which can only be updated once textured video is supported. DvPlayer is a contribution to OS4, and still actively under development, so I would expect Stephen to update DvPlayer when Texture video is also available.
Basicaly, chicken and egg, you can't have support until it is available, and you can't see how useful it is until it is supported.
The 0.32 driver is very stable, and works well with Radeon HD 4000 cards. The prime benefit really is being able to use newer cards.
Going by the dates of your blog posts, it looks like v0.32 does not support vertical blank interrupts? So that WaitTOF has to use CPU polling? (Your blog clearly explains the benefit of using interrupts, so I won't repeat that here.)
That is correct. However, that is only a minor benefit.
Next, about overlay. In short, it's obsolete technology. I don't even know if the latest Radeon HD cards support it. What I can tell you that the Radeon X1000 series (R500 chipsets) are the last Radeon series whose Linux drivers support overlay. It's a dead end; please forget about it.
The problem is that we have already dvplayer and mplayers which use our current p96-overlays APIs. Yes, overlay is obsolete and should be changed on what you say, but that didn't mean that our current video players will support it automatically, right ? (or you will provide a layer for ?)
What mean, that after you will implement what you say in the drivers, new code in video players should be added. Knowing how everything develops , i have fat doubts that video players will be updated in that terms very short, and so users with radeonHD and Sams will have a slow video playback for a long time in end.
The changes required would relatively trivial. MPlayer's source code is available, and DvPlayer's author is still here to update his own applications. Don't forget that I need a test app in order to implement it.
The slowness of video playback on the Sam460ex has been greatly overstated. I have one of these machines, and DVD playback is relatively smooth. Not perfect, but nowhere near as horrific as some claim.
I understand why users are interested in overlay or an alternative. I want it too. However, this is an incredibly complex driver, and so development can only ever proceed one step at a time.
I would not say that video playback is "slow" (e.g. a Sam440 is able to playback MPG videos just fine), but it does appear that overlays would make it faster or at least less CPU demanding (by removing the need for YUV to RGB conversion?).
Hmm, actually, doesn't the Sam440's Radeon 9250 (or similar) support overlay?
One more thing. Some people seem to think that overlay support could be slapped together quickly, whereas textured-video will take a long time. In reality, textured-video would probably take less time to implement than overlay.
There really is no technical or practical reason for wasting time on implementing overlay. It's obsolete, and won't get you better video playback any sooner.