On Monday, 19 December 2016, Thierry Reding <thierry.red...@gmail.com>
wrote:
> 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.
>
> Thanks Thierry for the nice write-up. Must admit that I was feeling a bit
lazy.
Considering the ~ok odds and the fact that we don't have platform support
for the drm*Device helpers I'm inclined to have this fixed after the merge.
Let's have etna and(?) tegra and sort bugs during the RCs ;-)
Emil
P.S. Pardon the html formatting
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
