1671071 - sw-wr: webrender software doesn't handle bit depth other than 8 bits

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Jean-Yves Avenard [:jya]]

Attachment: image.png

Created some reftest in bug 1660727.

When webrender-software is enabled, the rendered image is green.

Looking at the code of RenderBufferTextureHostSWGL , it only seems to carry across the colorspace; bit depth and video range (limited or full) is dropped.

The code treats all planes as being 8 bits which isn't always the case.

Comment 2

[Darkspirit]

Gnome X11, Debian Testing
This seems to have a different range than bug 1670815.

Before bug 1622966: This video is green.

After bug 1622966: Video is so transparent that I can look through the window.
mozregression --launch 2020-08-27 --pref gfx.webrender.all:true gfx.webrender.software:true -a https://hg.mozilla.org/integration/autoland/raw-file/2f20b441ceb2ed0704a70bcfd0e9affaece4f4a5/dom/media/test/reftest/av1hdr2020.mp4

Today: Corrupted like bug 1670815.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1622966

Comment 4

[Jeff Muizelaar [:jrmuizel]]

How does the non sw-wr code path handle non 8 bit?

Comment 5

[Jean-Yves Avenard [:jya]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)

How does the non sw-wr code path handle non 8 bit?

The bit depth, color space and color range is carried all the way from the TextureHost and the YUV->RGB shader handles conversion to 8 bits RGB.
https://searchfox.org/mozilla-central/source/gfx/webrender_bindings/WebRenderAPI.cpp#1303-1342

Color range information is provided, but not acted upon.

This isn't full 10/12 bits support, just that the conversion to 8 bits RGB is correct.

Comment 6

[Jean-Yves Avenard [:jya]]

The information is available to RenderBufferTextureHostSWGL ; it contains the YCbCrDescriptor which has all the data necessary

Comment 7

[Lee Salzman [:lsalzman]]

Attachment: Bug 1671071 - reduce color depth of HD source data in SWGL. r?mattwoodrow

The non-WR basic codepath reduces HD YUV data to 8bpp low def. We need to
mimic this behavior in SWGL. GL does not have 10/12 bit planar formats, so
SWGL also needs to add a couple innocent format extensions to handle this
format of data coming in. SWGL then transparently does the lossy conversion
into an internal buffer, which allows texture fetching and compositing to
work as normal for an 8bpp texture.

Comment 8

[Lee Salzman [:lsalzman]]

Attachment: Bug 1671071 - support HDR formats in SWGL. r?mattwoodrow

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f7b8bcc63183
support HDR formats in SWGL. r=mattwoodrow

Comment 10

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/f7b8bcc63183