Hey, On 29 March 2016 at 19:06, Rob Clark <[email protected]> wrote: > On Tue, Mar 29, 2016 at 1:51 PM, Daniel Stone <[email protected]> wrote: >> Yep, you got it right: in the original intention, the only mappable >> GBM BOs were cursor BOs. This is mostly because we lacked modifiers, >> so it was assumed that they would be in a magic undiscoverable tiling >> format. >> >> Now we have modifiers, whilst adding those to the API (both allocation >> and gbm_bo_get_*() for legacy allocations), you could then do a >> gbm_bo_{,un}map_range(). I'm assuming these mostly wouldn't actually >> map and unmap in a VMA sense, but rather primarily perform cache >> maintenance. > > right, or let's say whether the entire vma is mapped or not should be > implementation specific. > > It would probably be useful if the ptr returned had the offset already > added, since this is how transfer_map works.. and (hopefully?) the > gralloc API lets us return a separate pitch for the mapped ptr (which > might be different from the src buffer)? That would accommodate > upload/download sanely. (Fwiw, even some UMA drivers need to do > staging copies for some formats.. although I guess gralloc probably > doesn't care about z32_float_s8x24_uint and that sort of thing ;-))
Yep, absolutely agreed. Who volunteers? :) Cheers, Daniel _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
