Note that most Radeons actually support one or the other form of YUV textures, but support for that was never included in Warp3D. It's difficult to retrofit it into the compositing code since that would only work under certain contraints. The R200 for example can use separate YUV plane data but only when using the full three texture units. That means there is no room for a separate alpha map, so things would need to be done in multiple passes with temporary bitmaps.
Here's hoping we can support more of that stuff on the later chips, with Gallium there is certainly better chances to see this working.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Rogue wrote: Note that most Radeons actually support one or the other form of YUV textures, but support for that was never included in Warp3D. It's difficult to retrofit it into the compositing code since that would only work under certain contraints. The R200 for example can use separate YUV plane data but only when using the full three texture units. That means there is no room for a separate alpha map, so things would need to be done in multiple passes with temporary bitmaps.
Interestingly, the R200 entry on wikipedia claims that it can handle up to 6 textures per pass via some "loop-back" technique. I have no idea what the restrictions are, but it could still be doable. If not, then it should still be able to handle YUV422, as that requires just one texture. Plus, they have overlay.
Quote:
Here's hoping we can support more of that stuff on the later chips, with Gallium there is certainly better chances to see this working.
Radeon HD cards have 4 or more texture units (depending on the series), which is enough for separate Y, U, and V textures plus an alpha mask. That will cover planar YUV modes. I already have example shader code for this, although it will have to be adapted.
Radeon X1000 (R500) series cards also have 4 or more texture units, but I'll probably stick to the Radeon HD series only (almost no one uses the Radeon X1000 series, and there are so many other things to spend time on).
It's interesting, so what you rally wont is not to convert the YUV422 into RGB, but keep components divided and use shadier to mix it all.
I don't know have you thinking about doing it, B/W contrast or Y component, will need to shade the color more black or more white, will you need two textures whit alpha? Black texture and a white texture and just manipulate the alpha?
If I remember correct the Y component plain is larger than UV component plains, so it will need to scale to fit etch other, so it's not loss less format.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
It's interesting, so what you rally wont is not to convert the YUV422 into RGB, but keep components divided and use shadier to mix it all.
Not quite. I will be using shaders to convert YUV422, YUV420P, or YUV410P bitmaps to RGB on-the-fly. These YUV bitmaps will be in the same format as what overlay uses on older Radeons. YUV422 can be handled as one texture, but the planar formats - YUV420P and YUV410P - are processed as three textures. However, that is my driver's problem. As far as applications are concerned, they are providing single YUV bitmaps.
This is why I've asked for a test program that displays YUV bitmaps in these formats using overlay. The bitmaps must be in the same format that is currently being used.
Quote:
I don't know have you thinking about doing it, B/W contrast or Y component, will need to shade the color more black or more white, will you need two textures whit alpha? Black texture and a white texture and just manipulate the alpha?
I'm not sure exactly what you're asking here. An alpha channel has to be provided as a separate mask bitmap, since YUV bitmaps don't support an alpha channel.
Contrast and other similar items could be handled directly in the YUV -> RGB conversion (which is basically a matrix-vector multiply). The only item still up for debate is if gamma adjustment is worth the extra effort. Personally, I I'd prefer to keep things simple and stick to just plain YUV -> RGB. Picasso96's PIP API only supports brightness adjustment, which I don't think is particularly useful. Developers in need something more complex could always use GLSL when MESA + Gallium are done.
Quote:
If I remember correct the Y component plain is larger than UV component plains, so it will need to scale to fit etch other, so it's not loss less format.
Yes, YUV bitmaps are generally in a lossy format, as the colour information is at a lower resolution. This takes advantage of the fact that our eyes see colour at a lower resolution, and is the main reason for using YUV.
Interestingly, the R200 entry on wikipedia claims that it can handle up to 6 textures per pass via some "loop-back" technique. I have no idea what the restrictions are, but it could still be doable. If not, then it should still be able to handle YUV422, as that requires just one texture. Plus, they have overlay.
Hm, true... there are six texture address registers. I do seem to remember that I looked at the YUV support and there was something stopping me from doing it, but seriously, I can't remember what it was... :|
Quote:
Radeon HD cards have 4 or more texture units (depending on the series), which is enough for separate Y, U, and V textures plus an alpha mask. That will cover planar YUV modes. I already have example shader code for this, although it will have to be adapted.
Radeon X1000 (R500) series cards also have 4 or more texture units, but I'll probably stick to the Radeon HD series only (almost no one uses the Radeon X1000 series, and there are so many other things to spend time on).
Agreed. X1000 radeons where nice cards but it will be hard to even find them anymore.
Luckily, the shaders allow for a lot of things to be done within the chip, so converting YUV to RGB is "easy" to do on the RadeonHD (in quotes, because I still shudder at seeing the xv shader code in the ati video driver )
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Rogue wrote: Luckily, the shaders allow for a lot of things to be done within the chip, so converting YUV to RGB is "easy" to do on the RadeonHD (in quotes, because I still shudder at seeing the xv shader code in the ati video driver )
Yes, Radeon HD shader code** makes even simple operations look complicated. Fortunately, the actual operations are simple.
Hans
** Excluding the Radeon HD 7xxx+, as they have a new and nicer ISA.
I've done a little test executable which loads a 352x288 YUV422 image from a file and then display it using a PIP window (on a Radeon 9000)
Is it useful for your purpose ?
This is the link to download it, just in case... PIP_YUV422
Thanks. Yes, that is exactly the kind of thing that I'm looking for.
There is one minor issue though. Your code to upload the test bitmap doesn't take into account the bitmap's BytesPerRow alignment. Different cards have different alignment requirements, so it won't work on all cards. In particular, Radeon HD cards are more restrictive with alignment. This is easily fixed though.
It would be great if you or somebody else could add tests for the two planar modes too. For now, at least YUV422 is there.
at the following link an example on how to load and display a YUV420 planar image on a PIP window: PIP_YUV420P
Awesome. Thanks for that. I see from the code that the U and V planes are interleaved. I wasn't aware of this. That's not how the official format is specified. Fortunately, this isn't going to be a problem, as the plane alignment requirements remain the same.
Quote:
Currently I don't a way to create a 410P image, but it should be quite trivial to modify the 420P example.
Yes, it should be fairly trivial, as a 410P image follows the same idea as 420P except that the U and V resolution is 1/4 that of Y instead of 1/2.
Could software like EUAE take advantage from the video textured feature ? Or better if EUAE open a video textured window on workbench screen do you think that we'll have less cpu usage because some conversions are made by GPU ?? And so the remaining cpu power goes to emulate faster...
Edited by sofistisoftware on 2013/1/30 23:25:48
Sam 460EX, 2Gb Ram, Radeon R7 250, AmigaOS4.1 FE A4000 PPC604@233, Mediator A1200 PPC603@160, Mediator uA1 G3@800, 512 Mb [sold]
software like EUAE could be take advantage from the video textured feature ? Or better if EUAE open a video textured window on workbench screen do you think that we'll have less cpu usage because some conversions are made by GPU ?? And the remaining cpu power goes to emulate faster...
Like Thematic said, the classic Amiga's bitmaps weren't in YUV format, so textured video won't help. UAE could take advantage of compositing to rescale the screen, though. That would enable the user to resize the old lower resolution screens to whatever size they find most confortable on-screen without the emulation slowing down. This could be done today.
That was exactly what I wanted !! To have a confortable EUAE window on my full hd workbench screen it must be at least 800x600 and in that resolution on poor Sams cpu it limps. It would be nice to have an EUAE that could take advantage of compositing to rescale its window, i wonder who's the current EUAE's maintainer: Christopher Handley? Or who else? Richard Drummond is far from the amiga scene since 2007. I know that Álmos Rajnai is busy with jit and i don't think he would like to take into this trouble, is there anybody that could take care of this feature? Hans could you offer your help to any volunteer?
Sam 460EX, 2Gb Ram, Radeon R7 250, AmigaOS4.1 FE A4000 PPC604@233, Mediator A1200 PPC603@160, Mediator uA1 G3@800, 512 Mb [sold]
i wonder who's the current EUAE's maintainer: Christopher Handley? Or who else? Richard Drummond is far from the amiga scene since 2007. I know that Álmos Rajnai is busy with jit and i don't think he would like to take into this trouble, is there anybody that could take care of this feature?
I don't think there is a proper maintainer for it. I did the last few ports of it, tweaking it a little, but I am not a programmer, and so this type of thing isn't something I could do.
I don't know if Álmos plans on uploading his version to OS4Depot when it's done, but my plan is to update my ports with the JIT.
Quote:
mr2 wrote:
I think a new thread would be more visible :)
Yeah. I don't want to derail this one.
If someone else knows how to do it and writes the code, I can paste it into mine.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
)
