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

[Emil Velikov]

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.

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.

> Anyway, with this patch and the corresponding Tegra support, I have a
> working solution that can run unmodified Mesa applications using KMS,
> EGL/Wayland and GLX backends on TK1 and TX1 platforms. Neat!
>
> Considering that we have been ressorting to hacking all the KMS
> applications of interest to connect the render and display nodes
> together with the right tiling settings for the last two years, I regard
> this patch as a huge improvement for mobile graphics and would like to
> strongly support it.
>
> My only remaining concern is that this scheme cannot support the case
> where the tiling format is specified using FB modifiers, since this
> requires drmModeAddFB2WithModifiers() to be called from the application.
> So for Tegra we have to resort to a staging, not enabled by default
> SET_TILING ioctl. Not ideal, but recompiling your kernel with an
> additional config option is much less a hassle than patching every KMS
> app under the sun.
>
> So while thoughts about how this last issue can be addressed are
> welcome, I think this little lib can improve the life of many SoC users.
Agreed - let's have things as-is. One can "polish" the backend side of
things, once we have something in place.

Thanks
Emil