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

[Daniel Stone]

Hi Alexandre,

On 9 December 2016 at 13:20, Alexandre Courbot <acourbot at nvidia.com> wrote:
> On 12/08/2016 04:16 PM, Alexandre Courbot wrote:
>> 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.

Wayland doesn't use DRI-anything; Mesa has its own interface for
Wayland. I'm really surprised that you're seeing this behaviour
though: if you search for WL_DRM_CAPABILITY_PRIME (i.e. send dmabufs
rather than flink names) in src/egl/drivers/dri2/platform_wayland.c,
you'll see that a) we always use it when available, and b) we refuse
to initialise when the device is a rendernode and we don't have PRIME.
So I'm not sure how this could ever happen ...

> 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!

Cool! I assume this will work on Tegra124 more generally then - do you
have a branch somewhere?

> 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.

Check out Ben Widawsky's 'Renderbuffer Decompression (and GBM
modifiers)' patchset. With this, as well as krh's pending GETPLANE2
ioctl that will allow us to get a list of acceptable modifiers for
display from KMS, we can trivially implement this in clients without
the need for a backchannel ioctl:
https://git.collabora.com/cgit/user/daniels/weston.git/commit/?h=wip/2016-11/gbm-planes-modifiers

Cheers,
Daniel