»

[klx300r]

@ Piru

I respect your work on MOS;however, I'll side with Hans and Karlos's opinions on modern video driver issues.

[Karlos]

Originally Posted by klx300r

@ Piru

I respect your work on MOS;however, I'll side with Hans and Karlos's opinions on modern video driver issues.

There's not really a side to take. There's no disagreement that being able to leverage hardware assisted video playback is a good thing (TM). This is all a question of implementation detail as to best to achieve it on more recent RadeonHD cards, as the existing drivers for these cards don't have a working implementation yet.

Ultimately, that decision will be down to Hans as he's the one doing the work, so other than being an interesting discussion on the relative merit of overlay vs chromakey vs video texture, it's all a bit academic.

[Piru]

Originally Posted by klx300r

@ Piru

I respect your work on MOS;however, I'll side with Hans and Karlos's opinions on modern video driver issues.

And by that comment you show your complete ignorance of the matters at hand. I hope it's that, since the alternative is even worse.

[stevieu]

Anyone for tea?!

[magnetic]

klx300r

Its not about "Sides" its about facts. Kind of funny you would take sides against guys like PIru and Itix ( man I wish Frank M posted here) I mean Piru has only been coding for amiga for 15 years, no big deal.

[klx300r]

Originally Posted by Piru

And by that comment you show your complete ignorance of the matters at hand. I hope it's that, since the alternative is even worse.

ah pleasewhy because you think it's 'essential' and other highly skilled developers think it's 'obsolete'

[magnetic]

kxl3oor

Whats humours is that you arent even considering the science behind it, as explained by many in all these threads. Instead you are taking fanboy sides..

[takemehomegrandma]

Originally Posted by klx300r

ah pleasewhy because you think it's 'essential' and other highly skilled developers think it's 'obsolete'

djrikki said about timberwolf: "You need to opt-in to YouTube's HTML5 programme. Videos are painfully slow though at present, but do work. Yes, cannot wait until the optimisations begin. "

Just guessing here, but he has no overlay, right?

[spirantho]

Overlay is obsolete.
Textured video is a much better way of doing the same thing at the same speed.
RadeonHD cards had moved away from supporting true overlay, using textured video instead.

And just in case I also get accused of fanboyism, here's a forum entry by AMD saying exactly that:
devgurus.amd.com/thread/154009

[Tcheko]

The only interesting point of overlay is offloading dumb scaling & color conversion from CPU.

Definitly not obsolete and a real usefull feature. Just have a look at any under CPU powered H264 media player. They all embbed dedicated hardware for scaling & color conversion.

Not willing to implement such defacto standart or agree its usefullness... Oh well...

[Karlos]

Originally Posted by stevieu

Anyone for tea?!

A nice cup of Assam, drop of milk, no sugar, would be great, thanks!

[Zac67]

Overlay is obsolete.

This very much depends on the platform in question. While traditional overlay and 3D texturing are pretty much interchangeable from the user's POV, overlay is much more efficient.

Overlay: raw video data is written once (decompression by CPU) and then read back once during display when the overlay is used in the framebuffer.

Texturing video: raw video data is written during decompression (CPU), then read back, scaled/converted and written to the framebuffer (GPU) and finally read during display (GPU).

Obviously the latter is more work, so if power or GPU bandwidth is an issue you're better off with overlay. On a desktop computer where neither is a problem it may not be worth the trouble.

(It may be possible to read the raw video just once, process it in the GPU and shove the data directly into the display pipeline, but I don't think they're using this approach.)

[Karlos]

Originally Posted by Zac67

This very much depends on the platform in question. While traditional overlay and 3D texturing are pretty much interchangeable from the user's POV, overlay is much more efficient.

It's only more efficient if both options exist and and takes less time than texturing. There was a time when that was a given, but these days, thanks to the 3D arms race (of which texture fill rate one of the things that got massively ramped up) it tends not to be the case. In fact, dedicated hardware has become less and less of a feature in favour of packing as many stream processors as possible onto the die.

As I said elsewhere, video texturing has a number of additional advantages too.

Obviously the latter is more work, so if power or GPU bandwidth is an issue you're better off with overlay. On a desktop computer where neither is a problem it may not be worth the trouble.

(It may be possible to read the raw video just once, process it in the GPU and shove the data directly into the display pipeline, but I don't think they're using this approach.)

GPU <-> memory bandwidth is literally in the hundreds of GB/s these days. Even my now rather old hat G200 based card can manage ~ 105GB/s for VRAM to VRAM (read-process-write) operations and that's while it's still displaying a fully composited desktop.

[Fab]

@karlos

Fine, and what about the practical write speed on SAM 460 PCIe bus?

Being able to write yuv 420 data instead of plain rgb24 data is twice as fast... On machines like Macs, Pegasos or AmigaOnes it's a huge speedup.

[Karlos]

Originally Posted by Fab

@karlos

Fine, and what about the practical write speed on SAM 460 PCIe bus?

I don't own a SAM so I can't say - there are various benchmarks out there.

Being able to write yuv 420 data instead of plain rgb24 data is twice as fast... On machines like Macs, Pegasos or AmigaOnes it's a huge speedup.

Not disagreeing at all. Don't forget, I still use an BPPC/BVision combo and the VRAM write speed there is ~15MB/s or so, thanks to the bus.

Perhaps I didn't make it clear (though I believe I did) when I first mentioned video texturing but just in case, video texturing does not imply the transfer of already-decoded RGB data from RAM -> VRAM. The transformation from YCbCr -> RGB, along with scaling, is handled by the texture mapping hardware. Without this hardware colourspace conversion, a chip can't really be said to properly support video texturing.

Whatever bus transfer arguments you can make for traditional overlay, you can equally make for video texturing.