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

[Alexandre Courbot]

Hi Daniel,

On 12/09/2016 11:13 PM, Daniel Stone wrote:
> 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 ...

Interesting. I will try to get to the bottom of this as a way to improve
my (weak) understanding of Mesa.

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

Yes, anything using Tegra124 or Tegra210 with working display drivers (a
few Chromebooks so far, and probably the Pixel C sometime soon) should
directly benefit from it.

I have pushed a branch (just Christian's initial branch + a port of his
first Tegra patch and my hacks to make Wayland and GLX work) here:
https://github.com/Gnurou/mesa/tree/renderonly

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

That should make a good reading for the weekend. :) Thanks!

Alex.