Hyperion Entertainment Message Boards

When using 16bit 565 bitmap formats as source for drawing operations CompositeTags behaves totally different on various systems.
For example I was able to get test results for the following cards using the follwing formats:

RGBFB_R5G6B5PC

Radeon 9250: okay
Radeon HD 4650/5450: fails completely
Radeon HD 7850: okay (not wrong colors as former wrong tests seemed to show)
Radeon R7 250X (HD 7770): okay

RGBFB_R5G6B5:

Radeon 9250: okay
Radeon HD 4650/5450: okay
Radeon HD 7850: fails completely
Radeon R7 250X (HD 7770): fails completely

Regarding driver versions: 9250 latest, 4650/5450 v1.0, 7xxx not mine no idea.
edited: test result above was wrong.

@Daytona675x

Daytona675x wrote:When using 16bit 565 bitmap formats as source for drawing operations CompositeTags behaves totally different on various systems.

The behaviour depends on what the hardware/driver supports. You can check whether hardware supports a particular pixel format by setting the HW only flag, and checking the return code when you call CompositeTags().

Daytona675x wrote:RGBFB_R5G6B5PC

Radeon 9250: okay
Radeon HD 4650/5450: fails completely
Radeon HD 7850: wrong colors
Radeon R7 250X (HD 7770): okay

I can almost guarantee that whoever tested the Radeon HD 7850 used an old version of the Radeon HD driver. Otherwise they would have had the same result as the Radeon R7 250X (they're both Southern Islands GPUs). There was an issue with RGBFB_R5G6B5PC in an older version of the driver. Tell whoever did that test to update the driver.

Daytona675x wrote:RGBFB_R5G6B5:

Radeon 9250: okay
Radeon HD 4650/5450: okay
Radeon HD 7850: fails completely
Radeon R7 250X (HD 7770): fails completely

Unfortunately AMD removed support for big-endian 16-bit textures with Southern Islands GPUs, which is why the Radeon HD 77xx and newer cards don't support RGBFB_R5G6B5 (or RGBFB_R5G5B5).

I can add RGBFB_R5G6B5PC support to Radeon HD 4650/5450, which only fails because I forgot to add it (up till Southern Islands GPUs came along, nobody really used the *PC modes). Unfortunately, RGBFB_R5G6B5 on Southern Islands GPUs isn't going to happen for the reason given above.

Hans

@Hans

I can almost guarantee that whoever tested the Radeon HD 7850 used an old version of the Radeon HD driver. Otherwise they would have had the same result as the Radeon R7 250X (they're both Southern Islands GPUs).

Yes, I was wondering myself. But that driver-bug reveals interesting information about what can be done and what not:

Unfortunately AMD removed support for big-endian 16-bit textures with Southern Islands GPUs, which is why the Radeon HD 77xx and newer cards don't support RGBFB_R5G6B5 (or RGBFB_R5G5B5).

But, you can do it - and you already did it once, although apparently not on purpose, the color-bug in that buggy driver clearly demonstrates it
Because I get the correct colors if I use the original big-endian colors with RGBFB_R5G6B5PC instead... And that's exactly the behaviour you need for proper RGBFB_R5G6B5 big-endian support!
So it shouldn't be a big deal to convert that bug into a feature!

I can add RGBFB_R5G6B5PC support to Radeon HD 4650/5450, which only fails because I forgot to add it

Yes, you should really fix that. I guess I remember the other *PC formats to also fail, at least the 16bit variants.

Thanks in advance for fixing / adding support for those formats!

EDIT Too bad Looks like it simply was a wrong test-app-setup on the system with the 7850. So sadly no bug to convert into a feature like it appeared first But support for those formats shouldn't be too hard anyway, after all it's just one byte-swap away.

Daytona675x wrote:

Unfortunately AMD removed support for big-endian 16-bit textures with Southern Islands GPUs, which is why the Radeon HD 77xx and newer cards don't support RGBFB_R5G6B5 (or RGBFB_R5G5B5).

But, you can do it - and you already did it once, although apparently not on purpose, the color-bug in that buggy driver clearly demonstrates it
Because I get the correct colors if I use the original big-endian colors with RGBFB_R5G6B5PC instead... And that's exactly the behaviour you need for proper RGBFB_R5G6B5 big-endian support!
So it shouldn't be a big deal to convert that bug into a feature!

Alas, it didn't work properly, which is why I switched to using RGBFB_R5G6B5PC for 16-bit screens in the first place. It's been a while since I worked on this problem so I can't remember all of the details. IIRC, it appears to work okay at first for 16-bit=>16-bit ops, but falls apart when you start doing things like varying the alpha value.

Hans