[PATCH v2 0/5] MR197: winegstreamer: Add support for zero-copy in wg_transform.

Rémi Bernon (@rbernon) wine at gitlab.winehq.org
Wed Jun 8 18:11:57 CDT 2022


> Sure, conceptually it's simpler, but the callbacks make it really ugly. 
> (Also the fact that it's so different from the API for the transform...)
> 
> We can't exactly predict how many buffers a GStreamer pipeline needs 
> (well, unless it tells us through the buffer pool config), but we don't 
> necessarily need to, either; we can allocate new buffers and blit if our 
> pool wasn't large enough, and just make a point of always allocating 
> "enough" PE buffers in practice.
>

It seems brittle, not robust to GStreamer changes, and requires tweaking
to avoid bad cases where we would copy buffers. The general solution
is simple and I have it already implemented. I'm not going to rewrite
everything just to get rid of a callback.


> Well, sure. I just ask partly because tainting memory is not the most 
> obvious way of accomplishing our goals, and I wanted to see if other 
> options were considered. (Also, at this point, because of the problem 
> described below.)

Yes, I have explored what could be done with a pool, I actually wanted
to use one, as it seems more natural. It just doesn't work and doesn't
help us doing anything except maybe free the released buffer
automatically.

Though if, after all, the pool cannot be safely used for zero-copy as in
the case discussed below, we also wouldn't want to free buffers. The
default pool does all this exactly as we want, depending on whether
memory has been tainted.


> If we read an entire buffer but the decoder is still holding onto the 
> GstBuffer, we won't be able to "taint" it because it's not writable, but 
> we'll still remove the wg_sample. Later when the decoder does free the 
> GstBuffer it'll be untainted and hence can be reused. Hence the buffer 
> pool will pick up that buffer instead of the zero-copy buffer we want.

If the decoder and the pipeline (it also depends on what videoconvert
decides to do) does hold on the buffers, then it will likely do it all
the time. In this case there's no point in trying the zero-copy every
time.

After a while and after enough buffers have been tried and not freed by
the pool, we won't get any more useless allocations, and we'll continue
in a mode where the buffers are just copied the normal way.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/197#note_1734



More information about the wine-devel mailing list