Re: [Intel-gfx] [RFC 0/3] Add new ioctl to resize gem object for deferred allocation
On 27/03/2014 22:23, Chris Wilson wrote: On Thu, Mar 27, 2014 at 03:28:26PM +, arun.siluv...@linux.intel.com wrote: From: Siluvery, Arun arun.siluv...@intel.com This patch series adds a new ioctl to resize a gem object. I'm tired, but off the top of my head, I think you can do away with the magic extension to create_ioctl. If we allow any one to fallocate() ranges of any object, the user can create a large object, populate it all with a scratch page, then later populate regions as required. This looks quite a reasonable and useful feature. -Chris Could you clarify my understanding on how to use fallocate() to resize the object, considering the case where we start with an object of size x and want to increase its size to (x+y) at a later point. My understanding is, first object is created with gem_create ioctl with size x. At a later point if it is to be resized, we allocate y at the end of x using fallocate(). It is allocating the pages for us and from its implementation it is clear that the file size is updated with new value if offset+len is greater than initial size. Do we need to make any changes for GEM to get the new size or it is completely transparent to it? could you give an overview on how you think it should work? regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/3] Add new ioctl to resize gem object for deferred allocation
On 04/07/2014 02:18 PM, Siluvery, Arun wrote: On 27/03/2014 22:23, Chris Wilson wrote: On Thu, Mar 27, 2014 at 03:28:26PM +, arun.siluv...@linux.intel.com wrote: From: Siluvery, Arun arun.siluv...@intel.com This patch series adds a new ioctl to resize a gem object. I'm tired, but off the top of my head, I think you can do away with the magic extension to create_ioctl. If we allow any one to fallocate() ranges of any object, the user can create a large object, populate it all with a scratch page, then later populate regions as required. This looks quite a reasonable and useful feature. -Chris Could you clarify my understanding on how to use fallocate() to resize the object, considering the case where we start with an object of size x and want to increase its size to (x+y) at a later point. My understanding is, first object is created with gem_create ioctl with size x. At a later point if it is to be resized, we allocate y at the end of x using fallocate(). It is allocating the pages for us and from its implementation it is clear that the file size is updated with new value if offset+len is greater than initial size. Do we need to make any changes for GEM to get the new size or it is completely transparent to it? could you give an overview on how you think it should work? My understanding of what Chris said is that fallocate(2) could be used to toggle ranges of an object - from normal backing store, to scratch page backing store. There is a mode argument passed in to fallocate, so if that is zero you could populate the passed in range with scratch pages. Or if mode is FALLOC_FL_KEEP_SIZE you could allocate proper backing. Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/3] Add new ioctl to resize gem object for deferred allocation
On 27/03/2014 22:23, Chris Wilson wrote: On Thu, Mar 27, 2014 at 03:28:26PM +, arun.siluv...@linux.intel.com wrote: From: Siluvery, Arun arun.siluv...@intel.com This patch series adds a new ioctl to resize a gem object. I'm tired, but off the top of my head, I think you can do away with the magic extension to create_ioctl. If we allow any one to fallocate() ranges of any object, the user can create a large object, populate it all with a scratch page, then later populate regions as required. This looks quite a reasonable and useful feature. -Chris Sorry for the delayed response, I was on holiday. I will modify the implementation to use fallocate(), shmem is supporting this and it seems to be a better approach. In this case once the object is created we extend gem_create ioctl using fallocate() and allocate the additional space but does the userspace still see it as a contiguous block when it writes to the additional space? Once the object is modified using fallocate(), are these changes completely transparent when this object is used in other functions? please clarify. regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/3] Add new ioctl to resize gem object for deferred allocation
From: Siluvery, Arun arun.siluv...@intel.com This patch series adds a new ioctl to resize a gem object. This is required in cases where the actual size of the object is not known at the time of creation and there is chance that we may need more space later. A typical use case is memory allocation for mipmaps where you cannot know whether higher level mipmaps are required or not. If the object is resizeable we can initially allocate only for level0 and when we know that higher levels are required we can resize and allocate the rest. This is desirable in case of low memory devices. The usage scenario is, 1. Driver allocates original single-level texture. 2. GPU blit for level 0 data added to command buffer by driver. 3. OpenGL Driver requests resize of texture with all mip levels. 4. GPU blit for level 1 data added to command buffer by driver. 5. Command buffer submitted. The size of gem object is constant and this fact is tightly coupled in i915, so Daniel suggested an alternative approach. In this approach a scratch page is used for lazy allocation. When the object is created, a new parameter is added to specify the size for which the backing store is required initially along with the total size. A scratch page is also created for lazy allocation. The scatter/gather table is created for the total size but the entries whose backing store is not created point to the scratch page. A stop marker is introduced to denote the end of real pages. When the resize request is received, new pages are created and dummy entries are updated with real entries. In the mipmap usecase there ever will be only one resize request so single stop marker is sufficient to handle this. There is a basic i-g-t to test this, I will send it as a separate patch. This is a not a complete implementation, I am sending this mainly to get feedback. Please review and let me know how this is going in the right direction, how it can be improved, missing things and any other suggestions. regards Arun Siluvery, Arun (3): drm/i915: Prepare gem object to handle resize drm/i915: Handle gem object resize using scratch page for lazy allocation drm/i915: Create new ioctl to request gem object resize drivers/gpu/drm/i915/i915_dma.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 9 ++ drivers/gpu/drm/i915/i915_gem.c | 191 +++- include/uapi/drm/i915_drm.h | 33 +++ 4 files changed, 234 insertions(+), 1 deletion(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/3] Add new ioctl to resize gem object for deferred allocation
On Thu, Mar 27, 2014 at 03:28:26PM +, arun.siluv...@linux.intel.com wrote: From: Siluvery, Arun arun.siluv...@intel.com This patch series adds a new ioctl to resize a gem object. I'm tired, but off the top of my head, I think you can do away with the magic extension to create_ioctl. If we allow any one to fallocate() ranges of any object, the user can create a large object, populate it all with a scratch page, then later populate regions as required. This looks quite a reasonable and useful feature. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
