[Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

Michel Dänzer michel at daenzer.net
Wed Feb 6 17:40:10 UTC 2019


On 2019-02-06 12:55 p.m., Tapani Pälli wrote:
> On 2/6/19 1:16 PM, Michel Dänzer wrote:
>> On 2019-02-05 11:30 p.m., Marek Olšák wrote:
>>> Hi,
>>>
>>> Video players request fbconfigs with these attributes:
>>> GLX_RED_SIZE = 8
>>> GLX_GREEN_SIZE = 8
>>> GLX_BLUE_SIZE = 8
>>> GLX_ALPHA_SIZE = 0
>>>
>>> Note that the values specify MINIMUM required component sizes, not exact
>>> sizes. 10-10-10-2 satisfies the requirement and therefore
>>> glXChooseFBConfig
>>> returns it first. Then video players choose the first config.
>>>
>>> There are many video players that have this issue. I guess they
>>> copied the
>>> same code from each other.
>>>
>>> If we expose 10-bit or 16-bit formats, a lot of software will be broken.
>>> Any ideas how to get out of this rabbit hole?
>>>
>>> My suggestion is to change the behavior of glXChooseFBConfig to return
>>> 8-8-8 or 8-8-8-8 first if they satisfy the attributes and ignore the
>>> spec.
>>
>> Deliberately violating the spec and diverging from other GL(X)
>> implementations sounds like a bad idea to me.
>>
>> We should help getting broken code fixed by identifying it and making
>> suggestions.
>>
>>
>> For code using glXChooseFBConfig, unless I'm missing something, a
>> water-tight way to get a config which exactly matches a specific format
>> is to specify all of GLX_RED/GREEN/BLUE/ALPHA_SIZE corresponding to each
>> component's size, and GLX_BUFFER_SIZE corresponding to the sum of all
>> sizes. The former and the latter have opposing sort orders, so only a
>> single combination of R/G/B/A sizes should match all five of them.
>>
> 
> This is the main reason why 1010102 is still disabled in i965, there are
> still issues, even with ubuntu 18.10. It looks like gnome-shell version
> in 18.10 is too old (does not have the 'fix' which was essentially to
> disable 1010102),

gnome-shell is a different case though, and AFAIK it's only ever been
broken if Xorg runs at depth 30.


> Xorg 1.20 seems to work ok with DefaultDepth 30 though.

With no 10/10/10/x FBConfigs? I don't get any depth 30 GLX visual in
that case either, so no compositing manager using OpenGL can work.
glxgears works, but only via automatic compositing I suspect.


> I guess one way forward would be to expose 1010102 but start
> listing all problematic apps with 'allow_rgb10_configs=false' to drirc.

Then they would probably never get fixed anyway.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the mesa-dev mailing list