On 07.12.2015 17:41, Michel Dänzer wrote: > On 05.12.2015 19:12, Daniel Vetter wrote: >> On Fri, Dec 04, 2015 at 05:43:33PM -0500, Ilia Mirkin wrote: >>> On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux >>> <linux@xxxxxxxxxxxxxxxx> wrote: >>>> On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote: >>>>> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux >>>>> <linux@xxxxxxxxxxxxxxxx> wrote: >>>>>> Moreover, DRI3 is not yet available for Gallium, so if we're talking >>>>>> about Xorg, then functional DRI2 is a requirement, and that _needs_ >>>>>> to have a single device for the rendering instances. Xorg has no way >>>>>> to pass multiple render nodes to client over DRI2. >>>>> >>>>> Just to correct... DRI3 has been available on gallium [at least in the >>>>> context of st/mesa] basically since DRI3 was introduced. Not sure what >>>>> issue you're fighting with, but it's definitely not a gallium >>>>> limitation... could be something related to platform devices. >>>> >>>> Well, my statement is based on the fact that there's nothing in >>>> src/gallium/state-tracker/dri which hints at being DRI3. Maybe it's >>>> implemented differently, I don't know. > > The DRI state tracker code in src/gallium/state_trackers/dri/ supports > DRI1-3. There's almost no explicit mention of DRI3 in it because DRI3 > and DRI2 work mostly the same as far as this code is concerned. Also note that there's no requirement for the renderer device node to be opened via the DRI3 protocol. E.g. the DRI_PRIME implementation for DRI3 in Mesa opens the renderer device itself, creates a shared scanout image from it, gets a dma-buf file descriptor for that, creates a pixmap from that via DRI3 and presents that pixmap via Present. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
