Closed Nevcairiel closed 2 years ago
I haven't been able to find a value yet which actually results in a black image. Using 0 leaves the image the typical green, but using 128 already gives cyan, and even 0.5 already tints the image noticeably cyan (as I was testing if they maybe ignore that part of the specification and expect 0.5)
Might just add a vendor check there.
AMD seems to be fine, so just Intel that seemingly screwed up the implementation here.
For the record, tested on
NUC7CJYH2 Celeron J4005 - UHD 600 Driver 27.20.100.8681
I got reports first from a user, so I just picked up this NUC and started it up to try to reproduce.
I tested with wrong file as dumbass before.
AMD seems to be fine, so just Intel that seemingly screwed up the implementation here.
Yep, I have AMD 5700XT rig which I tested before, and it was fine too.
Might just add a vendor check there.
Yes, probably the best. They clearly doing it wrong and not how the documentation says they should.
They seem to be missing Video View special case. And looks like it is interpreted as [0, 1] RGB (but not quite) input, with conversion on the way, from RGB to YCbCr?
It works if you do:
const FLOAT ClearYUV[4] = {0.5f, 0.0f, 0.5f, 0.0f};
I only figured it out, because I looked at this equations (and because G+B is cyan, which we were getting)
Cb = (B - Y) /
I always lose my head when it comes to color conversions... they are doing something funky and for sure not up to specification.
On Intel GPUs, the fast clearing path for P010 results in a cyan image, instead of the expected black. Disabling fast clearing, and using the RTVs works as expected. NV12 also seems to work fine.
Already attempted to use 512 as the clear color (as would be appropriate for 10-bit), without any noticeable change.
CC @kasper93
PS: If anyone has a AMD GPU to test this with, that would also be helpful. Otherwise I might setup a test bench soon to confirm.