[vlc-devel] [PATCH 2/2] picture_pool: fix Reserve() not locking/unlocking pictures

[Thomas Guillem]

On Sat, Dec 31, 2016, at 11:14, Rémi Denis-Courmont wrote:
> Le vendredi 30 décembre 2016, 23:13:21 Thomas Guillem a écrit :
> > > More importantly, I cannot think of any use case for using the lock and
> > > unlock
> > > callbacks, that would be both practically useful for the display plugin,
> > > and
> > > safe/valid/well-defined, so I don't really see the point in these extra
> > > intricacies.
> > 
> > My work in progress OpenGL PBO branch
> > https://github.com/tguillem/vlc/commit/bf7fa65ede8fb10839f70d61f707965ee43b6
> > 049 will need this commit.
> 
> From my PoV, any vout that relies on lock/unlock is broken because the 
> callbacks haven't really done anything useful ever since the vout rework. 
> AFAICT, the original (unsound) semantics of those callbacks were lost by
> then.
> 
> And I still fail to see an explanation of what they are supposed to do,
> how 
> that's actually going to work, and why it's actually necessary.
> 
> > PBO for Pixel Buffer Object.  With that, we can do direct rendering with
> > OpenGL x / OpenGLES 3 display modules. For now, perfs are worse with
> > OpenGLES 3 but 30% better (for 4K) with OpenGL (still WIP).
> 
> I fail to see why.
> 
> * If you need to know when the buffer is read-only and ready for upload,
> cache 
> invalidation, etc., you have to use the ->prepare callback.
> * If you need to hold onto the buffer after display, you can use
> picture_Hold() 
> and picture_Release() functions to defer the buffer returning to the
> pool.

Ohh I didn't though about that solution. I'll try that, see if it works
in my case.


> * If you need to unmap the buffer before rendering, you simply cannot
> perform 
> direct rendering (since software decoders and filters might need the
> buffer as 
> reference frame during and after display).
> * Likewise if you do not have enough buffers (lest a deadlock potentially 
> occur). though the core should work around it automagically by turning
> direct 
> rendering off.
> 
> And with that noted, I don't really see what (else) ->lock and ->unlock
> could 
> do that would be useful to OpenGL, or really any video output interface.
> 
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel