>> This completely breaks the ABI. Nak. If you remember, before doing any stolen memory related changes, we had consulted you. We went ahead with these changes, after getting a nod from your side. This idea of allocating the User created frame buffers came from your side only. We didn't had the option of using a new ioctl. And the GEM objects of User frame buffers were the only such objects which can be identified uniquely at driver level. Otherwise there was no way to determine the type of a GEM object at driver level and take some custom decisions based on that. It was discussed that the stolen area has a limitation of not being directly accessible from CPU side, but it was also told that the direct access of User frame buffers (especially X tiled) from the CPU side would be very unlikely. Also we have seen that typically the life-time of Frame buffers is more, as they are not local objects. They are always being used as a shared object between the Surface flinger & the Rendering App. So the logic of BO cacheing on libdrm side is also not applicable to them and thus we didn't have to care about the BO purging part also. Considering all this, we came to a conclusion that the User fb's fitted well into our requirement and we took the decision of using the stolen area as a backing store for the frame buffers whenever possible. We admit that this is still a basic rudimentary implementation. But it can be enhanced/refined further over a period of time in subsequent patches. Actually the problem of underutilization of Stolen memory is more pronounced on VLV-BYT platform only, as there is a Hw bug that either the allocation of Stolen area can be completely disabled or the next allocation has to be of 64 MB only. But this limitation is not present on newer platforms, like from CHV onwards. For low RAM based products on BYT, it became imperative for us to fully utilize the Stolen space. Best Regards Akash -----Original Message----- From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] Sent: Thursday, January 09, 2014 3:18 PM To: Goel, Akash Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [PATCH 5/7] drm/i915/vlv: Increase the utilization of stolen memory on VLV. On Thu, Jan 09, 2014 at 11:01:02AM +0530, akash.goel@xxxxxxxxx wrote: > From: Akash Goel <akash.goel@xxxxxxxxx> > > On VLV, 64MB of system memory was being reserved for stolen area, but > ~8MB of it was being utilized. > Increased the utilization of Stolen area by allocating User created > Frame buffers(only X Tiled) from it. > User Frame buffers are suitable for allocation from stolen area, as > its very unlikely that they are not accessed from CPU side. > And its even more unlikely that the Tiled(X) buffers will be accessed > directly from the CPU side. And any allocation from stolen area is not > directly CPU accessible, but accessible only through the aperture > space. > With 1080p sized frame buffers (32 bpp), the allocation of 6-7 frame > buffers itself gives almost the full utilization of stolen area. This completely breaks the ABI. Nak. See the create2 ioctl. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
