<div dir="ltr"><div dir="ltr">On Wed, 14 Aug 2019 at 18:42, Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm not sure I agree with this.<br>
<br>
We are meant to work on embedded systems and 256MB should be enough to<br>
let us bring up X under qemu.<br>
<br>
I'm fine with some sdk/ptest images having more memory, that makes<br>
sense but 256MB not allowing X under qemu seems rather poor.<br></blockquote><div><br></div><div>I poked a bit more at this. The main difference between vmware emulated hardware and std emulated hardware is that X uses the standard 2D framebuffer interface for the former, and the full 3D stack for the latter (via use of glamor: <a href="https://www.freedesktop.org/wiki/Software/Glamor/">https://www.freedesktop.org/wiki/Software/Glamor/</a>). The 3D stack (mesa and friends) is what causes the memory usage to swell.<br></div><div><br></div><div>It is possible to disable this behaviour and enforce framebuffer usage (see 'man modesetting'), and I have verified that the RAM usage drops to similar levels as vmware, but that is not the upstream default; they have more or less obsoleted 2D drivers and are defaulting to 3D rendering nowadays. I'd rather follow that.<br></div><div><br></div><div>Alex<br></div><div><br></div><div><br></div></div></div>