On Mon, Dec 19, 2016 at 10:19 PM, Thierry Reding
<thierry.red...@gmail.com> wrote:
> On Mon, Dec 19, 2016 at 04:04:34PM +0000, Emil Velikov wrote:
>> 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 ;-)
>
> 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.
No strong opinion, although I suppose basic functionality with some
assumptions (i.e. that we don't have a discrete GPU on the board) is
better than no functionality at all, and we can always improve Tegra
support incrementally. We are close enough to not requiring any
out-of-tree patches that I am ok with a temporary compromise.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
