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