Hi Emil, On 12/09/2016 11:20 PM, Emil Velikov wrote: > On 9 December 2016 at 13:20, Alexandre Courbot <acour...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev