10bit display with SDL/GL

[alatteri]

Hi there,

I think we emailed about this a while back, but I'm wondering if there have been any changes to being able to get 10bit output from SDL/GL display surface in Linux? That would be great if so.
SDL does have the following pixel format:
SDL_PIXELFORMAT_ARGB2101010

Thanks for everything.

Alan

[MartinPulec]

Hi Alan,

SDL pixel format SDL_PIXELFORMAT_ARGB2101010 can be used for 10-bit RGB in UltraGrid by adding --param sdl2-r10k. It is not enabled by default because it usually generates black image (not sure if it works, anyways).

For the rest - have you managed to enable the 10-bit pipeline? For which setup - Intel, AMD or NVIDIA, X11 I guess? The thing is that I have done a small research and it still looks to me that it is still a bit tricky to make it run. Just AMD (and perhaps also Intel) seem to (at least) sometime work, yet I am not sure about details. It is also currently not clear to me the actual output format for OpenGL, but it may be possible at least to test but I currently don't have a working 10-bit setup.

[alatteri]

I've gotten 10bit working at least at the X11 level by creating this file /etc/X11/xorg.conf.d/30-screensetup.conf

Section "Screen"
  Identifier    "Default Screen"
  DefaultDepth    30
EndSection

grep -i 'depth\|bits' /var/log/Xorg.0.log
	"Default Screen" for depth/fbbpp 30/32
[    17.452] (**) modeset(0): Depth 30, (--) framebuffer bpp 32
[    17.902] (II) modeset(0): Initializing kms color map for depth 30, 10 bpc.

So it does seem to be set at the X11/OS level. I've added --param sdl2-r10k to my UV string and I see image, but I'm still trying to determine if it is actually giving additional color precision.

[alatteri]

I've tried a bunch of stuff, and adding --param sdl2-r10k does not seem to increase displayed color precision, although I do get picture. This is with an Intel NUC7i5 running Ubuntu 20.04 and 21.10

[MartinPulec]

Just for sure - what is transmitted pixelformat/codec? The thing is that the hint preserves R10k only if possible (there is a conversion if the codec doesn't match). You could try this:

uv -d sdl -t testcard:1920:1080:25:R10k --param sdl2-r10
[video dec.] Successfully reconfigured display to 1920x1080 @25.00p, codec R10k

There are 3 possibilities AFAIK:

1. R10k is used for the SDL display (and then it doesn't increase color precision as you noted)
2. it wasn't used in your scenario but if enforced with the testcard:
   a. image is displayed
   b. image is not displayed

In the case 2b we could try something more here.

[MartinPulec]

Thanks, I got it working with AMD in the end. Anyways, SDL2 R10k still doesn't display anything for me and unfortunately I don't have may resources for 10-bit rendering yet. BTW, do you have some content which would present the 8/10-bit difference in a visually observable way? I am now trying with UVG dataset...

[alatteri]

Hi Martin,

Thinking some more, I need to do better tests to validate.

Attached is a ZIP with 3 TIFF files that have gradients in them. In 8bit you would see definitive banding, in 10bit it will be smooth.
gradients.zip

[MartinPulec]

Perfect, thanks. I was a bit unsure if the display really displays 10 bits because of this line in Xorg.0.log:

AMDGPU(0): Using 10 bits per RGB (8 bit DAC) 

but banding is clearly observable with that image in 8-bit mode.

[alatteri]

In the past I've tested with BMD HDMI out, and it does properly display in 10bit. So that is my baseline reference proper color precision. My recent tests I don't have that baseline (different TV), so I need to do that.

[alatteri]

it is also important to set the display to Full range and set the max bpc

ACTIVEDISPLAY=`xrandr | grep " connected " | awk '{ print$1 }'`
xrandr --output $ACTIVEDISPLAY --set "Broadcast RGB" "Full" --set "max bpc" 10

https://www.soi.pw/posts/10-bit-color-on-ubuntu-20.04-with-amdgpu-driver/

[alatteri]

another relavent link

https://wiki.ubuntu.com/DeepColourDepthSupportPlan

[MartinPulec]

thanks, I am using DP and it doesn't seem to be necessary to set but it is certainly useful

[MartinPulec]

I've tried to implement 10-bit OpenGL rendering according to this document for AMD + X11 (settings) and I have to say that it looks that it works. You can try out with current UG code:

uv -t testcard:codec=R10k:pattern=gradient2 -d gl

(gradient2 pattern produces "full-range" R10k now)

Of course it currently works only if the selected codec (either implicitly or explicitly) is R10k. If you have some preferred workflow (mainly compression), you would like to share here, I could look if there is (or can be) created a conversion.

[MartinPulec]

Hi Martin,

is --param sdl2-r10k no longer necessary?

There is no change for SDL2 so far, so it is needed to use that parameter for SDL_PIXELFORMAT_ARGB2101010. I think it cannot be enabled by default now because it still displays black screen most of the time (at least I didn't manage to make it work).

Also, you are using -d gl, and I am wondering if that is preferred over -d sdl and what the difference between those two actually are.

Well, yes, as I said, I was never able to display 10-bits with SDL2 even if the X11 is started in 10-b mode. On contrary, the GL command works and it really displays 10-bit picture (as checked visually).

In regards to compression, my sources are 10/12bit SDI, captured via decklink:codec=R10k (I think I no longer need to specify this explicity as UG uses the proper codec based on input).

true

For HD/2K signal i'm using x265, and for UHD/4K I'm using libx264 with subsampling=444 (need to force this with x264, but I believe it happens native with x265) and --param use-hw-accel .

On the receiver I've been using -d sdl:fs --param use-hw-accel on Ubuntu 20.04 Server with NODM as the display manager.

Just for sure - --param use-hw-accel does (currently) nothing on the encoder. On the other hand, for the decoder it would currently prevent decoding 10-bit signal. We may add HW-accelerated 10-bit decode later (SW decoders support that now, anyways).

[alatteri]

Just for sure - --param use-hw-accel does (currently) nothing on the encoder. On the other hand, for the decoder it would currently prevent decoding 10-bit signal. We may add HW-accelerated 10-bit decode later (SW decoders support that now, anyways).

Good to know. I wouldn't have thought of that.

I've always used -d sdl, is there any downside to using gl or change of function, outside of the 10bit thing?

Thanks again.

[MartinPulec]

I've always used -d sdl, is there any downside to using gl or change of function, outside of the 10bit thing?

Not really, it is just a different display.

But there are somedifferences (otherwise it wouldn't make sense to have both) - I guess that GL could have better performance, SDL on the other hand offers better compatibility including different backends, especially when OpenGL wouldn't run at all (Raspi?). Also I suppose that YUV interpretation may not be entirely consistent - IIRC I've seen some differences, not sure now - it would be needed to find out how SDL interprets YUV, OpenGL uses Rec.709 (the conversions are in UG module as shaders).

[alatteri]

OpenGL uses Rec.709 (the conversions are in UG module as shaders).

I'll have to look at this as we almost always working P3 color space. So does GL/UG "clip/constrain" the image to 709, or is it just displaying absolute values?

[MartinPulec]

I don't know what you mean by displaying absolute values. But the behavior is slightly different - it won't clip the values, it will use 709 primaries for the conversion, thereafter I'd expect a slight shift. Anyways, if you use both from/to YCbCr, the conversion it will be idempotent.

[alatteri]

I confirm uv -t testcard:codec=R10k:pattern=gradient2 -d gl is producing quite smooth results. But when displaying an actual encoded signal, it still looks 8 bit. I have not yet had the chance to check the signal on a waveform, but in the past, at least with an x265 signal output via BMD SDI, it was accurate to the input.

[MartinPulec]

How encoded? I'd assume that there may be some missing conversions, but I'd need used commands. Anyways, I've now tested the testcard witn -c libavcodec:encoder=libx265 and the result still looks as preserving 10-bit.

[alatteri]

So I confirm this is working thru encode.

Sender: ./UltraGrid.AppImage --tool uv -t testcard:codec=R10k:pattern=gradient2 -c libavcodec:encoder=libx265:bitrate=40M 10.55.118.75
Receiver: UltraGrid.AppImage --tool uv -d gl:fs

The gradient is smooth on the receiver display.

I have more testing to do to see why a similar gradient captured via SDI is banded.

[MartinPulec]

Are the properties exactly the same? Or the input is e.g. in 10-bit YUV instead of RGB/R10k?

[alatteri]

Hi Martin,

Sorry for the late followup. I've tested the latest builds. Using -d gl:fs results in less than 24fps playback (around 20). If I use -d sdl:fs then I get realtime playback. So the choice is higher color fidelity but non-realtime, and lower color fidelity but realtime playback.

[MartinPulec]

Btw, which graphics do you use? I've retested with AMD and NVIDIA – NVIDIA seems to work fine with 10 bits but AMD is a very slow, even slower than you describe - some 1 FPS for me, but RGBA is a bit slow there as well, so I am not sure - I was thinking if switching to 10-bit workflow doesn't slow the whole stack down there. I'll consider disabling native 10-bit display for AMD, if you confirm that the observed behavior is on AMD.

[alatteri]

Intel NUC8 and NUC10... I believe they both have UHD 630 integrated graphics.

[MartinPulec]

Interesting - and is it working there? I mean is the output really 10-bit if it can be visually checked? Anyways, I'll at least add an opt-out option for OpenGL since it looks like the performance is worse for AMD and Intel at least

[MartinPulec]

Just for the record:

I'll at least add an opt-out option

it is --param gl-disable-10b. But default is still enabled - I think that more testing is needed to asses if disabling per vendor. I don't think that it has the negative performance impact when 10-bit rendering isn't enabled in the system. So assuming that user really wants 10 bits - not sure how much it is automatic nowadays, at least in Linux I don't think it is even if both GPU&display support that.