2016-03-08 12:36 GMT+01:00 Daniel Stone <dan...@fooishbar.org>: > Hi, > > On 7 March 2016 at 20:45, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 7 March 2016 at 10:35, Daniel Stone <dan...@fooishbar.org> wrote: >>> On 7 March 2016 at 10:19, Thierry Reding <thierry.red...@gmail.com> wrote: >>>> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote: >>>>> The wrapped driver takes away the ability of the application to decide >>>>> which GPUs to bind together - at least if you want to keep things >>>>> tightly coupled at that level. >>>> >>>> That was actually the prime objective of the patches I posted back at >>>> the time. =) >>> >>> Which, for the single-GPU/single-scanout case, is perfect. But it's >>> completely backwards for the multi-GPU case, and they _are_ the exact >>> same problem, so I'd rather not encourage separate solutions for both. >>> I really, really, really want to get rid of $DRI_PRIME. >>> >> Nuking DRI_PRIME and straightening things out is a very worthy goal >> imho. Although... how are these two new approaches likely to work with >> X11. Afaics there is no GBM/EGL in xserver, outside of glamor that is. >> Even if we add the bits, how are thing going to work in GLX ? > > Axel pointed out privately that I worded this very badly: I don't want > _get rid of_ $DRI_PRIME and drirc overrides for the default device, > but I do want to allow apps to enumerate and select devices through > EGLDevice as an additional API. That it solves our existing (and very > real) GBM problem makes it a nice two-birds-with-one-stone approach. > > GLX is pretty much a dead end here, and there's not a lot we can do > about it. But EGL/X11 is a very real thing that works today (given > that you need it for newer GL versions, I believe ... ?), and doesn't > require Glamor/GBM on the other end. So from that end, we fall into > the same solution as Wayland: the server declares the GL device it's > using for composition (through wl_drm or dri2/dri3), and it's > essentially on the client to ensure it renders in a manner compatible > with both the render device and the target. Same as GBM really. :) > >>>> While I agree it's good to have an API to allow explicit control over >>>> association of render to scanout nodes, I think that we really want >>>> both. In addition to giving users the flexibility if they request it, >>>> I think we want to give them a sensible default if they don't care. >>>> >>>> Especially on systems where there usually isn't a reason to care. Most >>>> modern SoCs would never want explicit control over the association >>>> because there usually is only a single render node and a single scanout >>>> node in the system. >>> >>> I don't think anyone's arguing otherwise! If there's only one scanout >>> node, then the application cannot possibly discover any other DRM >>> device to give to GBM. If there's only one render node, then the EGL >>> implementation cannot possibly discover anything with EGLDevice. And >>> there'll always have to be a default render node selection for apps >>> who don't use EGLDevice (currently all of them), so, no problem. >> >> I believe that the series is inspired by device(s) where both parts of >> the GPU/SoC are closely coupled. Even if I recall correctly, the >> display engine cannot scanout from the tiled format, and the GPU >> should be used prior to that. This information can be communicated >> easier via the wrapped approach, otherwise we will need an API to pass >> it through the layers. Which in itself is a great although I'd imagine >> we won't get it right the first (X?) time(s). Meanwhile the original >> approach will just work ;-) > > Indeed; as I said, the combination/wrapped approach is essentially > perfect for these systems (especially Freescale, with its mandatory 2D > blit engine), but I don't think it scales, since you require one > wrapper driver per GPU+KMS combo. Taking the approach I suggested
The 'good' is that the specific kms driver is quite short and easy to maintain. The whole magic lies in the corresponding winsys - e.g. src/gallium/winsys/tegra/drm/tegra_drm_winsys.c: static int tegra_tiling(int fd, uint32_t handle) { struct drm_tegra_gem_set_tiling args; memset(&args, 0, sizeof(args)); args.handle = handle; args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK; args.value = 4; return drmIoctl(fd, DRM_IOCTL_TEGRA_GEM_SET_TILING, &args); } static const struct renderonly_ops ro_ops = { .open = nouveau_drm_screen_create, .tiling = tegra_tiling, }; struct pipe_screen *tegra_drm_screen_create(int fd) { return renderonly_screen_create(fd, &ro_ops); } So it boils down to write a driver for every supported kms device. This would make it easy to support different kms IP core block version with different features. kms IP core v1: does need intermediate flush and v2: does not. > would allow us to solve multi-GPU with the same approach, whereas with > the wrapper driver ... who volunteers to write the Radeon+Intel > combination driver? Not me :) > >>> I think the only disagreement is how to implement the API internally. >>> Lucas is heading in a more generic direction, whereas the >>> wrapper-driver approach requires you to write one driver for literally >>> every possible combination of render/scanout. Again, fine for >>> platforms like Tegra and i.MX where there will only ever be one >>> combination ever, but it doesn't scale. >> >> Indeed there would be some duplication/boilerplate. The render-only >> idea by Christian Gmeiner mitigates it. I believe Thierry was unhappy >> with it, due to the possible permutation as new users come along. >> >> Personally, I would use it for now, and worry/re-design thing as we >> get (m)any other users. No offence but it seems like we're trying to >> tackle a problem which does not exist, yet ? > > In that case, we should just scrap Lucas's series entirely and go back > to individual drivers which are specific to one render+scanout > combination; my suggestion was an incremental improvement on Lucas's > series, which already adds the notion of individual device > enumeration. But I don't think the one-fixed-driver approach scales at > all, especially if you think of multi-GPU in a desktop system. As the > guy who seems to deal most with the build, I thought you'd be the > least amenable towards adding however many new drivers we'd require > ... ;) > Correct.. renderonly was written to full fill the one-scanout-one-renderonly GPU thing. > >>>>> We don't need any of this for GLX. Etnaviv is working fine with GLX on >>>>> both imx-drm and armada-drm, as the DDX does all the work when binding >>>>> devices together in that case. >>>> >>>> In this case DDX will take the role of the wrapped driver. So you'd end >>>> up with duplication of the "glue" in both Mesa and the DDX, don't you? >>> >>> The DDX doesn't exist outside X11, thankfully. >> >> Indeed. Shame that not everyone is on the wayland/mir boat yet. We're >> getting close though :-) >> >> At the end of the day: the idea is that wrapped driver works now >> (modulo bugs) with any user space. As we get the explicit control >> interface in place (mesa and users) we'll still be able to reuse those >> drivers and we can migrate smoothly. > > It does work, but given that renderonly didn't really seem to get > anywhere, we'd need a tegra driver, a freescale driver, one driver for > every combination of {r300,r600,radeonsi}+i915 and nouveau+i915, etc. It is/was a good thing to get something working. Without it it would be quite hard to do some real development on those drivers. > Not to mention one for every combination of every in-tree driver plus > DisplayLink or similar. I just don't think it's viable as a long-term > solution, and given that Lucas's patches give us the infrastructure to > deal with this (current and very real) set of problems well - what's > the harm? > In the end I like the idea from Daniel I only wish that it is not needed to modify existing SW to be able to use the device enumeration approach as this would be a real blocker (at least for me). I really hope to see the one-and-only solution lading this year in mesa. Greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev