On Mon, May 2, 2016 at 9:51 PM, Rob Clark wrote:
> On Mon, May 2, 2016 at 3:21 PM, Marek Olšák wrote:
>> On Mon, May 2, 2016 at 9:05 PM, Rob Clark wrote:
>>> This is for the non-zero-copy case.. for example pixels live in gl
>>> texture in host (vmwgfx/virtgl), or in vram for discrete gpu perha
On Mon, May 2, 2016 at 3:21 PM, Marek Olšák wrote:
> On Mon, May 2, 2016 at 9:05 PM, Rob Clark wrote:
>> This is for the non-zero-copy case.. for example pixels live in gl
>> texture in host (vmwgfx/virtgl), or in vram for discrete gpu perhaps
>> (or some tiled format, etc).
>>
>> Since in those
On Mon, May 2, 2016 at 9:05 PM, Rob Clark wrote:
> This is for the non-zero-copy case.. for example pixels live in gl
> texture in host (vmwgfx/virtgl), or in vram for discrete gpu perhaps
> (or some tiled format, etc).
>
> Since in those cases, you have to copy part of the buffer, as
> specified
This is for the non-zero-copy case.. for example pixels live in gl
texture in host (vmwgfx/virtgl), or in vram for discrete gpu perhaps
(or some tiled format, etc).
Since in those cases, you have to copy part of the buffer, as
specified by the bounding box, to and/or from staging buffer (based on
On 05/01/2016 11:58 PM, Daniel Vetter wrote:
Adding Greg Hackmann from the Android side. Greg, please add anyone
else who might be relevant.
On Sat, Apr 30, 2016 at 2:54 PM, Rob Clark wrote:
On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák wrote:
On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark wrote
Adding Greg Hackmann from the Android side. Greg, please add anyone
else who might be relevant.
On Sat, Apr 30, 2016 at 2:54 PM, Rob Clark wrote:
> On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák wrote:
>> On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark wrote:
>>> On Sat, Apr 30, 2016 at 5:39 AM, Miche
On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák wrote:
> On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark wrote:
>> On Sat, Apr 30, 2016 at 5:39 AM, Michel Dänzer wrote:
>>> On 26.04.2016 03:51, Rob Herring wrote:
On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov
wrote:
> On 25 April 2016 at
On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark wrote:
> On Sat, Apr 30, 2016 at 5:39 AM, Michel Dänzer wrote:
>> On 26.04.2016 03:51, Rob Herring wrote:
>>> On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov
>>> wrote:
On 25 April 2016 at 13:46, Daniel Stone wrote:
> On 23 April 2016 at 03:08,
On Sat, Apr 30, 2016 at 5:39 AM, Michel Dänzer wrote:
> On 26.04.2016 03:51, Rob Herring wrote:
>> On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov
>> wrote:
>>> On 25 April 2016 at 13:46, Daniel Stone wrote:
On 23 April 2016 at 03:08, Rob Herring wrote:
> On Fri, Apr 22, 2016 at 6:32 PM
On 26.04.2016 03:51, Rob Herring wrote:
> On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov
> wrote:
>> On 25 April 2016 at 13:46, Daniel Stone wrote:
>>> On 23 April 2016 at 03:08, Rob Herring wrote:
On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
wrote:
> Can we take a look at the G
Rob Herring writes:
> On Wed, Apr 27, 2016 at 5:01 PM, Emil Velikov
> wrote:
>> On 27 April 2016 at 19:51, Eric Anholt wrote:
>>> Rob Herring writes:
>>>
On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
> Rob Herring writes:
>
>> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herr
On Wed, Apr 27, 2016 at 5:01 PM, Emil Velikov wrote:
> On 27 April 2016 at 19:51, Eric Anholt wrote:
>> Rob Herring writes:
>>
>>> On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
Rob Herring writes:
> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
>> On Fri, Apr 22,
On 27 April 2016 at 19:51, Eric Anholt wrote:
> Rob Herring writes:
>
>> On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
>>> Rob Herring writes:
>>>
On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
> wrote:
>> Hi Rob,
>>
Rob Herring writes:
> On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
>> Rob Herring writes:
>>
>>> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
wrote:
> Hi Rob,
>
> On 22 April 2016 at 16:50, Rob Herring wrote:
On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
> Rob Herring writes:
>
>> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
>>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
>>> wrote:
Hi Rob,
On 22 April 2016 at 16:50, Rob Herring wrote:
> This adds map and unmap fu
Rob Herring writes:
> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
>> wrote:
>>> Hi Rob,
>>>
>>> On 22 April 2016 at 16:50, Rob Herring wrote:
This adds map and unmap functions to GBM utilizing the DRIimage extension
mapImage/u
On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
> wrote:
>> Hi Rob,
>>
>> On 22 April 2016 at 16:50, Rob Herring wrote:
>>> This adds map and unmap functions to GBM utilizing the DRIimage extension
>>> mapImage/unmapImage functions or existing
On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov wrote:
> Hi all,
>
> On 25 April 2016 at 13:46, Daniel Stone wrote:
>> Hi,
>>
>> On 23 April 2016 at 03:08, Rob Herring wrote:
>>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
>>> wrote:
Can we take a look at the GBM gralloc as well. One thin
Hi,
On 25 April 2016 at 15:25, Emil Velikov wrote:
> On 25 April 2016 at 13:46, Daniel Stone wrote:
>> On 23 April 2016 at 03:08, Rob Herring wrote:
>>> I'm not using GBM_BO_USE_WRITE and that is not a condition for mapping
>>> given that flag is tied to cursors (according to comments) and give
Hi all,
On 25 April 2016 at 13:46, Daniel Stone wrote:
> Hi,
>
> On 23 April 2016 at 03:08, Rob Herring wrote:
>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
>> wrote:
>>> Can we take a look at the GBM gralloc as well. One thing that worries
>>> me is that (most likely) you are requesting/cr
Hi,
On 23 April 2016 at 03:08, Rob Herring wrote:
> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
> wrote:
>> Can we take a look at the GBM gralloc as well. One thing that worries
>> me is that (most likely) you are requesting/creating a bo without
>> GBM_BO_USE_WRITE whist using MAP + CPU writ
Hi,
On 22 April 2016 at 19:21, Eric Anholt wrote:
> I don't think we want to always make a spare context just in case
> someone uses the map API. Contexts can be pretty expensive to set up,
> in time (for piglit tests on gbm) and memory (for X.Org).
>
> It's too bad I don't think we have a way t
On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov wrote:
> Hi Rob,
>
> On 22 April 2016 at 16:50, Rob Herring wrote:
>> This adds map and unmap functions to GBM utilizing the DRIimage extension
>> mapImage/unmapImage functions or existing internal mapping for dumb
>> buffers.
> Ftr that this is quite
Hi Rob,
On 22 April 2016 at 16:50, Rob Herring wrote:
> This adds map and unmap functions to GBM utilizing the DRIimage extension
> mapImage/unmapImage functions or existing internal mapping for dumb
> buffers.
Ftr that this is quite sensitive and apart from the obvious breakage
(coming in a seco
On Fri, Apr 22, 2016 at 1:21 PM, Eric Anholt wrote:
> Rob Herring writes:
>
>> This adds map and unmap functions to GBM utilizing the DRIimage extension
>> mapImage/unmapImage functions or existing internal mapping for dumb
>> buffers. Unlike prior attempts, this version provides a region to map
Rob Herring writes:
> This adds map and unmap functions to GBM utilizing the DRIimage extension
> mapImage/unmapImage functions or existing internal mapping for dumb
> buffers. Unlike prior attempts, this version provides a region to map and
> usage flags for the mapping. The operation follows th
This adds map and unmap functions to GBM utilizing the DRIimage extension
mapImage/unmapImage functions or existing internal mapping for dumb
buffers. Unlike prior attempts, this version provides a region to map and
usage flags for the mapping. The operation follows the same semantics as
the galliu
27 matches
Mail list logo
