[Mesa-dev] [PATCH 1/3] gallium: add renderonly library

[Alexandre Courbot]

Hi Emil,

On 12/09/2016 11:20 PM, Emil Velikov wrote:
> On 9 December 2016 at 13:20, Alexandre Courbot <acourbot at nvidia.com> wrote:
>> On 12/08/2016 04:16 PM, Alexandre Courbot wrote:
>>> On 11/30/2016 10:44 PM, Christian Gmeiner wrote:
>>>> This a very lightweight library to add basic support for
>>>> renderonly GPUs. It does all the magic regarding in/exporting
>>>> buffers etc. This library will likely break android support and
>>>> hopefully will get replaced with a better solution based on gbm2.
>>>
>>> Since we have no idea when said better solution will be available, and
>>> the situation of render-only GPUs has been unsustainable for way too
>>> long, I really hope a solution like this one can be merged in the meantime.
>>>
>>> I have tried it after porting support for Tegra
>>> (https://github.com/austriancoder/mesa/commit/2c7354701ee21ca28f69f5d7588f1d497553b4bf)
>>> to this latest version. Here are a few issues I have met:
>>>
>>> First, setting the tiling works indeed just fine if we are using an
>>> ioctl for this. However my impression was that the preferred way of
>>> doing it was through FB modifiers, and we started moving Tegra to this
>>> scheme. Problem: the FB modifier is passed through a call to
>>> drmModeAddFB2WithModifiers(), which is called by the client program, not
>>> Mesa - which in this case leaves the program with the burden of figuring
>>> out what the modifier should be. So with FB modifiers the problem is
>>> still here.
>>>
>>> Another issue I have seen is that GLX does not seem to work with this.
>>> X/modesetting starts just fine, and GLamor also seems to initialize.
>>> However glxinfo freezes on a xshmfence_await() call, and all GLX
>>> programs fail as follow:
>>
>> Solved that issue by forcing is_different_gpu to true in
>> loader_dri3_drawable_init() (pretty hackish, looking for a better way).
>>
>> Also I had another issue with Wayland where EGL windows would be
>> displayed all black. I traced this to the fact that Wayland was trying
>> to share the buffer by calling the old FLINK ioctl on the rendernode
>> device, which is forbidden. Opening card1 instead of renderD128 did the
>> trick as a workaround, but I am surprised as I thought Wayland was using
>> DRI3 exclusively? I am not very familiar with neither Mesa nor Wayland
>> though, so my assumption may very well be incorrect.
>>
> Some of these issues is due to the hardcoded nature of the card/render
> node. I've had drmDevice API which could/should be extended and
> utilised here.
> Earlier versions were quite buggy, so make sure to use
> 677cd97dc4a930af508388713f5016baf664ed18 or later.

My libdrm was 2.4.74, so I think this patch is there.

> 
> Since from kernel there is no relation between the KMS and GPU device,
> one will need to apply some heuristics locally. At some point we might
> want to make things more systematic/configurable, but let's get it
> working first ;-)
> 
> Thus, please propose/add anything to drmDevice that will you think is
> enough to build some heuristics on.
> 
> With that sorted, the Wayland FLINK issues should go away.

Thanks for the hint. I will look into that.