On Tue, Mar 29, 2016 at 1:51 PM, Daniel Stone <[email protected]> wrote: > Hi, > > On 29 March 2016 at 15:44, Rob Clark <[email protected]> wrote: >> On Tue, Mar 29, 2016 at 10:30 AM, Rob Herring <[email protected]> wrote: >>> On Tue, Mar 29, 2016 at 8:43 AM, Rob Clark <[email protected]> wrote: >>>> On Mon, Mar 28, 2016 at 12:29 PM, Rob Herring <[email protected]> wrote: >>>>> However, I found a bigger mismatch is there are no explicit map/unmap >>>>> calls in GBM. A writeable buffer will be a dumb buffer and is >>>>> implicitly mapped. Maybe that is enough in reality? >>>> >>>> I think originally this was probably just used for uploading mouse >>>> cursor, or something along those lines, rather than any serious use of >>>> sw rendering. But if android needs to mix hw and sw access to the >>>> buffer, I think we do need something that maps to transfer_map/unmap, >>>> so gl driver can (if needed) flush pending rendering and sync. >>>> >>>> Not sure how others feel, but I wouldn't be opposed to extending gbm.. >>>> anything that can sit on top of transfer_map/unmap should coexist well >>>> with a gpu driver. >>> >>> Looks like it was tried already[1]. Interestingly, the gralloc lock >>> interface already does some of what is discussed being needed >>> (specifying the region). >> >> yeah, as does pipe->transfer_map/unmap (which is ofc supported by >> vmwgfx gallium driver). >> >> So I think the issue is to just make the API look more like >> transfer_map/unmap (ie. specify a region.. and probably usage flags.. >> I don't think it would be applicable for cube/array/3d textures so >> 'level' probably not required.), rather than blind 'give me a void * >> for the whole buffer' sort of thing.. > > 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 ;-)) BR, -R > Cheers, > Daniel _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
