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

[Michel Dänzer]

On 2019-02-08 10:30 a.m., Tapani Pälli wrote:
> On 2/6/19 7:40 PM, Michel Dänzer wrote:
>> 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.
> 
> Hmm I'm not sure I follow you here but I got gnome-shell compositor
> running when setting DefaultDepth to 30 and it still had the bug where
> picking the objects (like selecting a window) did not work, rendering
> was looking OK though

Yeah, as I wrote that's a different issue from what this thread is about.


> and there were 1010102 visuals available in glxinfo.

So does i965 expose 1010102 configs when the X server runs at depth 30?
Or did you test with another driver?

I was thinking only exposing 1010102 configs (by default) when the X
server runs at depth 30 might be a solution, but I wonder if that might
affect some CTS/piglit tests or apps making use of those configs.


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