[Mesa-dev] [PATCH 3/3] imx: gallium driver for imx-drm scanout driver

[Thierry Reding]

On Mon, Dec 19, 2016 at 04:04:34PM +0000, Emil Velikov wrote:
> On Monday, 19 December 2016, Thierry Reding <thierry.reding at 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 ;-)

I'm fine if you want etnaviv as-is. I personally would want to hold off
on Tegra for a wee bit longer. Let's see if Alex has a strong opinion.

What are your requirements for release? Will you be freezing the libdrm
dependency during RCs? I've got most of the patches ready to make this
work reliably on Tegra, though I'd still have to port my patches to
Christian's renderonly library.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161219/5bd96a1a/attachment.sig>