RFC - ioctl to defer higher level mipmap allocation

RFC - ioctl to defer higher level mipmap allocation

[Siluvery, Arun]

> > On Tue, 2014-02-25 at 11:52 +0000, Arun Siluvery wrote:
> >> >Hi Everyone,
> >> >
> >> >There is a requirement to defer physical mapping of higher level
> >> >mipmaps. Texture download and usage are separate and you cannot know
> >> >beforehand whether higher level mipmaps are required at the time of
> >> >allocation.
> >> >
> >> >If we have an ioctl to resize existing mapping it can
> >> >be used when higher levels are required. It is desirable in low memory
> >> >devices to be able to defer until needed. 
> >> >
> >> >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.
> >> >
> >> >One issue is when the resize request is received, GPU has to wait if the
> >> >original object is in use.
> >> >
> >> >In a typical use case the above sequence is followed so waiting is not
> >> >required as the object is not yet submitted to GPU but it
> >> >isn't necessarily the case always - it could be that the command buffer
> >> >is filled and has to be submitted between downloads of levels 0 & 1 of a
> >> >texture and probably won't happen too often.
> >> >
> >> >Any wait in the driver affects user experience. Since textures are
> >> >downloaded at startup time this will only affect application startup
> >> >time and should not affect the performance but I am not sure whether
> >> >this is acceptable.
> >> >
> >> >I would like to get your comments on the following,
> >> >
> >> >1. Would it be an useful addition to i915?
> >> >2. what other issues need to be consider if we support this?
> >> >3. Has there been any work done on this?
> >> >
> >> >Any other comments/suggestions?
> >> >
> I don't think resizing the gem object is a good approach, obj->size 
> being invariant over the lifetime of a bo is pretty deeply ingrained 
> into our kernel code. What we could do instead is to have a per-process 
> scratch page and optionally use that for lazily allocated objects 
> instead of the shmem backing storage pages. A new ioctl could then be 
> used to instate the real backing storage on a range basis - a (start, 
> stop) pair to denote the range of pages which are backed by shmem should 
> be useful for this purpose. As long as we only allow this range to grow 
> we shouldn't have any tricky implications for the current code. Always 
> reserving the full size of the texture in the gtt and just filling the 
> unused parts with a scratch page also means that broken opengl clients 
> will sample a nice black and not random gunk from adjacently placed 
> textures.
> 
> As usual I need an open-source user of this new interface before I can 
> merge it, so someone also needs to enable this for mesa.
> -Daniel

Bringing this discussion to public list.
To merge this some work needs to be done on the mesa side also, so
please let me know your comments on this before we start with the kernel
changes.

regards
Arun