A-EON Technology secures graphic card support for AmigaOS 4

[Karlos]

WTF?!

Have you been drinking heavily before posting? Or are you hearing voices in your head? You clearly see things that aren't there, yet you come bursting out like this? I mean WTF, get a hold of yourself, or at least please sober up before going near the keyboard again!

:rolleyes:

This response is no more proportionate.

[Karlos]

Right you 'orrible lot. Calm down and carry on.

Don't make me have to do moderation work.
I've got drivers to work on...

[Karlos]

My 2 cents on this whole issue.

1) Any OS vendor is not really responsible for driver development; their responsibility is to provide the API/documentation to allow others, usually the hardware vendor, to do so. With mainstream OSes, there's usually enough development resource to create baseline drivers for a wide selection of hardware, but last time AmigaOS was a mainstream OS was... ?

2) Given that the hardware in question is made by AMD, there's no chance they're going to create a driver. So, that leaves the task to whoever has the time and ability. I don't see that it's unreasonable for Hans to be remunerated for the effort he's put into it.

3) A-Eon are providing the (assembled) hardware and have decided to fund development of drivers for it. They didn't have to make it available to anybody else at all.

[Karlos]

I dont remember so much fuss about paying for api/drivers in the past.  Cybergrpahix, piccasso etc

I remember buying my BVisionPPC shortly after they first appeared. It cost me something like 200 UKP at the time (I can't recall the exact price somewhere around that price). It came with fairly basic drivers for CGX3 only, which didn't even support 24-bit pens in 8-bit mode and was a bit temperamental too.

To get proper, then up-to-date driver support for the hardware, I paid an extra 30 odd quid or so to buy CGX v4, and I certainly didn't regret that purchase.

[Karlos]

No overlay??? In 2012? Really?

IMHO overlay is a very basic feature much more important than 3d support.

It's 2012. Overlays are pretty much obsolete - the chances are the feature you are thinking of is emulated on your graphics card using 3D support anyway. Let's see why:

Overlay: separate display region with independent colour format and resolution from main framebuffer, intended for the display of video streams.

+ No software YUV <-> RGB conversion necessary
+ No software scaling/filtering necessary

These were definite boons back in the 90's, but there are drawbacks too

- Generally only one overlay available on supported hardware
- Overlay typically occludes framebuffer and can't be part of any graphics pipeline or windowing architecture. It's basically "on top" or not at all.
- Limited video processing available, usually only colour properties can be adjusted.

The alternative to this is video texturing, where a YUV video stream is applied as a texture map to a rectangle primitive.

+ No software YUV <-> RGB conversion necessary
+ No software scaling/filtering necessary

So far just as good as an overlay, but there's more:

+ As many concurrent video streams as bus bandwidth / texel fillrate allows
+ Render target is a bitmap, can be used as part of any graphics pipeline or windowing architecture. Does not float above framebuffer and is compatible with both traditional and compositing windowing methods.
+ 2D/3D transformations possible
+ Shader postprocessing possible (on hardware that has them, which in 2012 is everything), virtually limitless potential for colour correction, sharpening, deblocking, deinterlacing, wacky artistic effects etc.

On my linux box, my nvidia card can handle many video streams at once, rendering them via this method and I can still do all the silly compiz zoom, 3D rotating box and other nonsense with no loss in speed while the video continues to render smoothly in each window.

It's not even a new idea. The Permedia2 doesn't have a dedicated overlay, instead supporting YUV textures. Due to the lack of fill rate (and on the Amiga, slow buses), you are pretty much restricted to one or two streams.

I really don't think you are missing much if you don't have a genuine overlay on anything like the HD4xxx series or above but you can leverage the 3D hardware instead.

[Karlos]

Given that Hans was able to use the basic compositing system in 4.1 to implement a 3D textured demo complete with pixel shading effects for fun, are we really suggesting he won't be able to implement some form of video surface implementation?

If it's going to be video texture based (which is clearly the better solution unless you prefer the older way of doing it), then adequate 3D support has to come first.

Anyway, the problem with RadeonHD is it gets quite harder to have this "overlay" functionality since the whole 3d machinery has to be implemented first.

That's precisely my point. Please the post I was responding to.

[Karlos]

>Given that Hans .. use ... compositing system in 4.1 to implement a 3D textured demo ... he won't be able to implement some form of video surface implementation?

Using compositing for scaling/filtering/rotating a square texture (a bitmap) is easy...

You missed the part about using shaders in said demos

The only problem is that compositing dont support YUV directly... So it will remain the YUV to RGB conversion

Alain Thellier

I wasn't implying such a feature would be made available via compositing, I was implying that he isn't lacking the necessary expertise to implement a feature such as video surfaces.

[Karlos]

No, it is just silly. Emulating overlay using OpenGL is old story.

Who said anything about emulating overlay with OpenGL? It's not as if we're talking about decoding each frame as an RGB texture and passing that to OpenGL. What I am describing is video texturing, in which the GPU directly applies YUV formatted data as a texture to a primitive, doing the YUV -> RGB conversion directly. This is a hardware level feature that even the old Permedia2 supported. Many OpenGL implementations (not necessarily on Amiga) expose this functionality and, of course, are able to emulate it for those that don't.

[Karlos]

I was thinking that you can already achieve it on Amiga by using current OpenGL functionality.

Right, that would indeed be possible. I'm not sure it would be particularly fast on current MiniGL implementations though. First of all, you'd probably have to do the YUV -> RGB conversion yourself. Then, the texture you'd generate would be converted to some underlying Warp3D format, which amongst other things, will impose a 2^n width and height restraint on it, which implies further software conversion (width modulus expansion for example). The hardware 3D driver may then expect the resulting texture to be formatted in some special manner intended for faster texturing (subpatching, for example), where what you really want in this case is to render the texture with the least amount of fuss, then replace it with the next frame ad infinitum. With the sole exception of output scaling, I can actually see it being a slower than a software only implementation at this stage.

Of course it doesnt have to be exposed via OpenGL (only). BVision and CVision boards expose overlay support using standard overlay API on Amiga and users dont have to know how it works under the hood.

Precisely. As I recall, it was cgxvirgin.library that supported it, if you enabled a LAYER=DESTRUCTIVE tooltype in the monitor driver or something (I don't recall exactly). You could tell it was a textured triangle fan when you made the window large enough, occasionally you could see the leading diagonal when the video wasn't properly synced.

Not really true, at least on Amiga. Overlay works with windowing and compositing just fine.

Then you aren't using an overlay (at least not a traditional one). A hardware overlay, by definition, is not part of the current frame buffer any more than a hardware mouse cursor is. Modern overlays, however, tend to be implemented in a manner not unlike the Permedia2 did and as such can integrate nicely into a proper windowing environment.

Heh, I just remember that good old never released Dragon2 even implemented overlay emulation so you could expose two mplayers with overlay simultaneously... it was only software based and quite slow but it worked

Sounds fun

[Karlos]

Yup, VLAYER=DESTRUCTIVE.

Yep, that one, even.

Nope. Technically you are correct but it can also work with windowing and compositing. Remember that weird (pink?) colour you can see in screenshots from programs using an overlay? It is for colour keying that screenshot application found from a window bitmap where a hardware overlay was supposed to be. When colour keying is enabled the overlay data is only visible where this colour is found. If an overlay window is behind another window its colour key backfill is also destroyed and no overlay data is displayed there.

This is a slightly different use case again - not all hardware from the era where overlay was a common feature supported chromakeyed overlays (technically, it's an "underlay", the overlay pixels are rendered only where the chroma key colour is found in the framebuffer). A lot of them simply provided a rectangular overlay that was rendered directly and would appear op top and that was it. An application would position the overlay to fit within it's window border, but if you then dragged another window in front, the overlay would occlude the overlapping portion. I have several old PC graphics cards that did that