On 03/11/2016 05:25 PM, Martin Peres wrote:
On 10/03/16 20:07, Adam Jackson wrote:
On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote:
On 03/10/2016 10:47 AM, Martin Peres wrote:
That could be a hacky way of handling the case where multiple 3D
drivers could be used to drive the same GPU. This may be necessary in
the future if two mesa drivers support the same GPU but one is
considered better than the other. We can also imagine a case where a
proprietary driver would need to be co-installable with an open source
one and would still use the same DDX. Isn't that what AMD is going to
do soon? Did anyone think about this case?
That case is the reason for allowing multiple vendor names. For a case
like AMD's driver, it would hand back two names. The order would be up
to the driver implementation, but I would guess that it would list the
proprietary driver first and the open source driver second. If the
proprietary one is installed, then the client would use it, and if not,
the client would use the open source one.
Very good! That could be worth mentioning in the spec. To make it
clear that it is the intended goal and to help implementers understand
the logic behind this proposal.
That's what I meant to convey with the description of multiple
client-side drivers that work with the same server-side driver. But if
that wasn't clear I can add a more specific example. Would something
like this help?
For example, some vendors may have both a proprietary client-side
vendor library and an open source vendor library that work with the
same server-side driver. In that case, the server would return the
names for both of the vendor libraries. The client would then be able
to select one of those vendor libraries, depending on which of them is
installed.
Right. It's pretty straightforward (and I plan) to wire this logic
through to xorg.conf, so the admin can control the list at server
startup time. Historically it's been somewhat pointless to do so, since
all the proprietary drivers have also replaced the server's GLX module,
but this gives us a path towards not doing that anymore at least.
I'd also considered using this mechanism as a starting path towards
both implementing GLX+Xinerama at all for the open drivers, and
eventually to do that with heterogeneous open/closed GLX on the server
side. Those are both fairly long term prospects, but I imagine it'll be
easier to do if we can opt into different client-side logic.
Sounds indeed like a good thing to have! Accelerated xinerama using
prime and reverse prime on multiple drivers :)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
