Hello David, Thanks for your answer.
On Fri, Apr 01, 2016 at 06:57:07AM +0000, David Garbett wrote: > The main difference between modesetting and armsoc is that armsoc > supports DRI2, and modesetting doesn't. This is what allows the GLES > driver to render to X buffers. Yes, that's what I figured. > DRI2 enables any application to pass any X pixmap into the GLES/EGL > driver, so all buffers need to be allocated from shareable memory. > That's not the case with modesetting - other than the main framebuffer, > other allocations (for pixmaps and windows) can just be local to the X > server, so don't allocate from the DRM driver. > > I've not looked at your DRM driver proposal so I can't really say why it > can't cope with the additional allocations. Though I do notice in your > armsoc patch that you don't handle scanout buffers any differently. In > many systems scanout buffers are a more scarce resource (perhaps they > need to be contiguous, or meet certain alignment restrictions). We do agree on that. However, it looks like the arm soc driver does way much more allocations, and usually smaller ones, than modesetting that basically just allocates a buffer for its framebuffers and that's it. If I was to guess, I'd say that it allocates buffers for applications (and possibly part of the applications window), that eventually depletes the CMA pool, even though the GPU is not used. I'd expect the DRI buffers to be allocated from this pool, because of the reasons you pointed out, but I would also expect that the applications do not hit that pool, precisely because it's a scarce resource. I'm possibly missing something though, or have broken expectations :) In our case, we don't really have any restrictions on the memory resource locations, and I'm not aware of any particular weird alignment constraints either. > > > Then, we noticed (using xfce4, on debian jessie) that the systray > > > icons were not displayed for some reason. There's also some game > > > (alex4 [4]), that starts, runs, but the window content remains black > > > (but it remains interactive, audio plays and if we take a screenshot, > > > the content is on the image, but the screen remains black). That's what concerns me the most though. We can always work around the memory allocations by playing cat and mouse and allocating a bigger pool (even though I'd really like to avoid that). However, those glitches are kind of weird, and not really convenient :/ Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel