On 14/07/16 09:57, John Högberg wrote:
> On 14/07/16 10:53, John Högberg wrote:
>> If I were you I'd just create a temporary image to hold the result and
>> enqueue a copy operation that waits for the kernel event. It'll work
>> everywhere and the performance penalty is tiny.
>
> ... If you
On 14/07/16 10:53, John Högberg wrote:
> If I were you I'd just create a temporary image to hold the result and
> enqueue a copy operation that waits for the kernel event. It'll work
> everywhere and the performance penalty is tiny.
... If you really must have it in-place that is. Is there
On 13/07/16 20:39, Mark Thompson wrote:
> The target I'm using (Intel/Beignet) declares OpenCL 1.2 but the in-place
> modification works anyway (with no qualifier, see the example in the first
> email), so I'm not sure what, if anything, should be done here. Is it likely
> to actually cause
On 13/07/16 20:39, Mark Thompson wrote:
> Is it likely to actually cause problems? (If nothing else, we can
> just document the in-place filter as possibly failing on <2.0.)
I guess would be good enough.
lu
___
libav-devel mailing list
On 13/07/16 11:54, John Högberg wrote:
> On 13/07/16 01:45, Mark Thompson wrote:
>> * 2D images. Are they actually sensible in general? I was pushed into
>> using them by tiled memory on Intel (if you take a buffer instead of an
>> image then you have to untile addresses yourself - not fun,
On 13/07/16 01:45, Mark Thompson wrote:
> * 2D images. Are they actually sensible in general? I was pushed into using
> them by tiled memory on Intel (if you take a buffer instead of an image then
> you have to untile addresses yourself - not fun, though certainly possible if
> it's better
Hi all,
This is kindof a dump of current progress. Only the first few patches are
plausibly complete, but I'd like to invite comments on what I've done so far.
First, some real things you can do with this:
* Hardware frame map/modify/unmap with VAAPI:
./avconv -vaapi_device
