On Wed, Nov 30, 2016 at 02:44:36PM +0100, Christian Gmeiner wrote:
[...]
> +static struct pipe_screen *imx_open_render_node(struct renderonly *ro)
> +{
> +   return etna_drm_screen_create_rendernode(ro);
> +}

Patch 2/3 never made it into my inbox for some reason, and had to find
it in some archives. I'll have to resort to commenting on the code here.
From what I saw, etna_drm_screen_create_rendernode() hard-codes the GPU
render node (to /dev/dri/renderD128, I think). It's a little brittle for
obvious reasons, but I think you might be able to get away with it,
depending on the SoC.

On Tegra we have a bunch of people that stick discrete GPUs into the
PCIe slot and run a second instance of Nouveau on that. It's an
interesting use-case, but it also has the drawback of creating a second
renderD device. What's more, it uses the same kernel driver, so hard-
coding the device node is going to give us a 50-50 chance on average
that we get the right one. Back when I had written the original proposal
I had also coded a heuristic that would walk sysfs and select the render
node that was on the same bus as the card node. This was before Emil had
removed the dependency on udev, but I've rewritten that code to work
with Emil's drmDevice*() API, which needs some fleshing out[0].

Out of curiosity, is this something that could happen on i.MX devices as
well? Or even if not i.MX, I'm fairly sure that there are other SoCs
that have a Vivante GPU and a PCI slot that people could use to stick
big GPUs into, so you may run into the same issue eventually.

Thierry

[0]: Interestingly, things would probably work for Tegra regardless of
whether the GPU is the Tegra one or a discrete one, as long as the
discrete is driven by Nouveau. So perhaps an even more interesting
heuristic would be to look for a render node that's driven by the
Nouveau driver...

Attachment: signature.asc
Description: PGP signature

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to