[Bug 754826] memory: add remap operation

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=754826

--- Comment #7 from Matthew Waters <ystreet00 at gmail.com> ---
(In reply to Olivier Crête from comment #6)
> (In reply to Matthew Waters from comment #5)
> > (In reply to Olivier Crête from comment #3)
> > > The whole undo operation feels fishy to me, I'm not sure how a undo is
> > > different from modifying the flags again? Although locking downgrades seem
> > > find, locking upgrades seem like a risky idea. Downgrading and then
> > > re-upgrading seems downright wrong for example as someone else could have
> > > mapped it for reading while that happens and then you won't be able to
> > > re-upgrade!
> > 
> > Actually, you will be able to reupgrade in that case.  The more dangerous
> > case is first adding a write map and then undoing with a potential map with
> > the write bit in between.
> 
> I think if you only downgrade, remapping can never fail, in the worse case,
> the buffer will still be mapped as RW internally even though the elements
> think it'S RO, no ? I would never allow adding write, only removing it.

Sure but what if you have a case where you have 1 memory per YUV plane and one
of those planes fails the remap operation.  You now have mappings that are in
an inconsistent state.

There are also other flags that would possible be removed (or added?) from/to a
mapping.  e.g. in GL there's a coherent bit that allows mapping on both the GPU
and the CPU concurrently.  Without that, we have to memcpy for coherency like
we currently do.

This of course this is all an optimization to avoid transfers on every map
related to tracking map flag state inside the memory subclass for memories that
have more than one memory domain that they are dealing with.

> > > I'd have a simple
> > > gst_mini_object_downgrade_lock(GstMiniObject, gint flags_to_drop);
> > 
> > That's what I started with :) however videometa has its own map()/unmap()
> > and now remap() vfuncs which may also need/want to undo a remap operation
> > unless we attempt something else.
> 
> I'm not sure why those would want to undo if we saw that we only allow
> downgrading?

Inconsistent map state as above.

> > The question is what does an API user do if the memory remap operation
> > fails.  As far as I see it, we have a two of options.
> > 1. do nothing (easy)
> > 2. attempt to rollback (hard)
> 
> How can a downgrad remap fail?

Pretty much in exactly the same ways the the lock downgrade can fail. 
Subclasses may have their own requirements for performing a remap that they
need to check.

e.g. attempting to lose the GL bit in a GL memory mapping which would result in
no mapping at all.

map(GL | RW)
downgrade(GL) -> error, memory domain change invalidates mapped pointer to a
texture handle

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.