Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-30 Thread Emil Velikov 
On 29 March 2017 at 13:34, Emil Velikov  wrote:
> On 29 March 2017 at 13:02, Thomas Hellstrom  wrote:
>> Hi, Emil,
>>
>> On 03/29/2017 01:30 PM, Emil Velikov wrote:
>>> Hi Thomas,
>>>
>>> On 28 March 2017 at 20:39, Thomas Hellstrom  wrote:
 Drivers may queue dma operations on the context at unmap time so we need
 to flush to make sure the data gets to the bo. Ideally the application
 would take care of this, but since there appears to be no exported gbm
 flush functionality we need to explicitly flush at unmap time.

 This fixes a problem where kmscube on vmwgfx in rgba textured mode would
 render using an uninitialized texture rather than the intended
 rgba pattern.

>>> I haven't checked but the issue should not be restricted to vmwgfx, right ?
>>>
>>> Perhaps we should add the following
>>> Fixes: 8aeb6d768b4 ("gbm: Add map/unmap functions")
>>> CC: 
>>
>> Unfortunately I've, perhaps a bit prematurely, already pushed the fix.
>> Is there a way to get it
>> into stable after push?
>>
> Adding mesa-stable@ to the CC list should do it. Check out the
> instructions for more examples.
>
> https://www.mesa3d.org/submittingpatches.html#nominations
>
>>
>>>
 Signed-off-by: Thomas Hellstrom 
 ---
  src/gbm/backends/dri/gbm_dri.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/src/gbm/backends/dri/gbm_dri.c 
 b/src/gbm/backends/dri/gbm_dri.c
 index ac7ede8..6c2244c 100644
 --- a/src/gbm/backends/dri/gbm_dri.c
 +++ b/src/gbm/backends/dri/gbm_dri.c
 @@ -243,7 +243,7 @@ struct dri_extension_match {
  };

  static struct dri_extension_match dri_core_extensions[] = {
 -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
 +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
>>> Currently the classic nouveau, radeon/r200 and i915 drivers do not
>>> support v4 of the extension.
>>> As-is this will 'break' them... if they ever worked to begin with.
>>>
>>> One solution is to bail out (return -ENOSYS or similar) in map/unmap
>>> API of the when the DRI module is too old.
>>> Just some ^^ food for thought.
>>
>> Hmm. Is there even a use-case for gbm with those drivers? If so we
>> should perhaps make them up-to-date with the flush extension.
>>
> Of the above:
>
> - nouveau: Does not support DRI_IMAGE, thus it doesn't work even
> before the patch.
> - i915: I have some untested ancient patches. Will see if I can rebase
> + send out.
It seems that the Intel CI regressed since it is also testing i915.

I'll try to respin my patches later on today/tomorrow.

In the meanwhile: Thomas, can you fix this patch to use v4 only in
gbm_map/unmap ?

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-30 Thread Michel Dänzer 
On 30/03/17 05:09 PM, Thomas Hellstrom wrote:
> On 03/30/2017 05:48 AM, Michel Dänzer wrote:
>> On 30/03/17 12:56 AM, Thomas Hellstrom wrote:
>>> On 03/29/2017 02:34 PM, Emil Velikov wrote:
 On 29 March 2017 at 13:02, Thomas Hellstrom  wrote:
> On 03/29/2017 01:30 PM, Emil Velikov wrote:
>> On 28 March 2017 at 20:39, Thomas Hellstrom  
>> wrote:
>>> Signed-off-by: Thomas Hellstrom 
>>> ---
>>>  src/gbm/backends/dri/gbm_dri.c | 9 -
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gbm/backends/dri/gbm_dri.c 
>>> b/src/gbm/backends/dri/gbm_dri.c
>>> index ac7ede8..6c2244c 100644
>>> --- a/src/gbm/backends/dri/gbm_dri.c
>>> +++ b/src/gbm/backends/dri/gbm_dri.c
>>> @@ -243,7 +243,7 @@ struct dri_extension_match {
>>>  };
>>>
>>>  static struct dri_extension_match dri_core_extensions[] = {
>>> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
>>> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
>> Currently the classic nouveau, radeon/r200 and i915 drivers do not
>> support v4 of the extension.
>> As-is this will 'break' them... if they ever worked to begin with.
>>
>> One solution is to bail out (return -ENOSYS or similar) in map/unmap
>> API of the when the DRI module is too old.
>> Just some ^^ food for thought.
> Hmm. Is there even a use-case for gbm with those drivers? If so we
> should perhaps make them up-to-date with the flush extension.
>
 Of the above:

 - nouveau: Does not support DRI_IMAGE, thus it doesn't work even
 before the patch.
 - i915: I have some untested ancient patches. Will see if I can rebase
 + send out.
 - radeons: ??

 If someone reports an issue we can ask them to write/test some code, I 
 guess ;-)
>>> Indeed. It looks like gbm is mostly used together with KMS anyway...
>> All of the above drivers are KMS based, FWIW.
>>
>>
> Do you think it's worthwhile to have them functioning with GBM?

I think it could make sense at least for r200, possibly also radeon, but
I don't know their current status wrt GBM.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-30 Thread Thomas Hellstrom 
On 03/30/2017 05:48 AM, Michel Dänzer wrote:
> On 30/03/17 12:56 AM, Thomas Hellstrom wrote:
>> On 03/29/2017 02:34 PM, Emil Velikov wrote:
>>> On 29 March 2017 at 13:02, Thomas Hellstrom  wrote:
 On 03/29/2017 01:30 PM, Emil Velikov wrote:
> On 28 March 2017 at 20:39, Thomas Hellstrom  wrote:
>> Signed-off-by: Thomas Hellstrom 
>> ---
>>  src/gbm/backends/dri/gbm_dri.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c 
>> b/src/gbm/backends/dri/gbm_dri.c
>> index ac7ede8..6c2244c 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -243,7 +243,7 @@ struct dri_extension_match {
>>  };
>>
>>  static struct dri_extension_match dri_core_extensions[] = {
>> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
>> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
> Currently the classic nouveau, radeon/r200 and i915 drivers do not
> support v4 of the extension.
> As-is this will 'break' them... if they ever worked to begin with.
>
> One solution is to bail out (return -ENOSYS or similar) in map/unmap
> API of the when the DRI module is too old.
> Just some ^^ food for thought.
 Hmm. Is there even a use-case for gbm with those drivers? If so we
 should perhaps make them up-to-date with the flush extension.

>>> Of the above:
>>>
>>> - nouveau: Does not support DRI_IMAGE, thus it doesn't work even
>>> before the patch.
>>> - i915: I have some untested ancient patches. Will see if I can rebase
>>> + send out.
>>> - radeons: ??
>>>
>>> If someone reports an issue we can ask them to write/test some code, I 
>>> guess ;-)
>> Indeed. It looks like gbm is mostly used together with KMS anyway...
> All of the above drivers are KMS based, FWIW.
>
>
Do you think it's worthwhile to have them functioning with GBM?

I can of course condition the flush on version 4 or above if necessary.

/Thomas


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-29 Thread Michel Dänzer 
On 30/03/17 12:56 AM, Thomas Hellstrom wrote:
> On 03/29/2017 02:34 PM, Emil Velikov wrote:
>> On 29 March 2017 at 13:02, Thomas Hellstrom  wrote:
>>> On 03/29/2017 01:30 PM, Emil Velikov wrote:
 On 28 March 2017 at 20:39, Thomas Hellstrom  wrote:
>
> Signed-off-by: Thomas Hellstrom 
> ---
>  src/gbm/backends/dri/gbm_dri.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c 
> b/src/gbm/backends/dri/gbm_dri.c
> index ac7ede8..6c2244c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -243,7 +243,7 @@ struct dri_extension_match {
>  };
>
>  static struct dri_extension_match dri_core_extensions[] = {
> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
 Currently the classic nouveau, radeon/r200 and i915 drivers do not
 support v4 of the extension.
 As-is this will 'break' them... if they ever worked to begin with.

 One solution is to bail out (return -ENOSYS or similar) in map/unmap
 API of the when the DRI module is too old.
 Just some ^^ food for thought.
>>> Hmm. Is there even a use-case for gbm with those drivers? If so we
>>> should perhaps make them up-to-date with the flush extension.
>>>
>> Of the above:
>>
>> - nouveau: Does not support DRI_IMAGE, thus it doesn't work even
>> before the patch.
>> - i915: I have some untested ancient patches. Will see if I can rebase
>> + send out.
>> - radeons: ??
>>
>> If someone reports an issue we can ask them to write/test some code, I guess 
>> ;-)
> 
> Indeed. It looks like gbm is mostly used together with KMS anyway...

All of the above drivers are KMS based, FWIW.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-29 Thread Thomas Hellstrom 
Hi, Emil,

On 03/29/2017 02:34 PM, Emil Velikov wrote:
> On 29 March 2017 at 13:02, Thomas Hellstrom  wrote:
>> Hi, Emil,
>>
>> On 03/29/2017 01:30 PM, Emil Velikov wrote:
>>> Hi Thomas,
>>>
>>> On 28 March 2017 at 20:39, Thomas Hellstrom  wrote:
 Drivers may queue dma operations on the context at unmap time so we need
 to flush to make sure the data gets to the bo. Ideally the application
 would take care of this, but since there appears to be no exported gbm
 flush functionality we need to explicitly flush at unmap time.

 This fixes a problem where kmscube on vmwgfx in rgba textured mode would
 render using an uninitialized texture rather than the intended
 rgba pattern.

>>> I haven't checked but the issue should not be restricted to vmwgfx, right ?
>>>
>>> Perhaps we should add the following
>>> Fixes: 8aeb6d768b4 ("gbm: Add map/unmap functions")
>>> CC: 
>> Unfortunately I've, perhaps a bit prematurely, already pushed the fix.
>> Is there a way to get it
>> into stable after push?
>>
> Adding mesa-stable@ to the CC list should do it. Check out the
> instructions for more examples.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mesa3d.org_submittingpatches.html-23nominations=DwIBaQ=uilaK90D4TOVoH58JNXRgQ=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ=BrXsoWQ8oh4YpiBU4MHB3Ajw6fCc8eSvWV1W36tTgt0=FQVDFEI-7Yq6wpypsxCCS-KRkWVaGhtGF3RuN4ZepGY=
>  

Ok. I'll try the option of forwarding the commit id to mesa-stable...



>
 Signed-off-by: Thomas Hellstrom 
 ---
  src/gbm/backends/dri/gbm_dri.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/src/gbm/backends/dri/gbm_dri.c 
 b/src/gbm/backends/dri/gbm_dri.c
 index ac7ede8..6c2244c 100644
 --- a/src/gbm/backends/dri/gbm_dri.c
 +++ b/src/gbm/backends/dri/gbm_dri.c
 @@ -243,7 +243,7 @@ struct dri_extension_match {
  };

  static struct dri_extension_match dri_core_extensions[] = {
 -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
 +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
>>> Currently the classic nouveau, radeon/r200 and i915 drivers do not
>>> support v4 of the extension.
>>> As-is this will 'break' them... if they ever worked to begin with.
>>>
>>> One solution is to bail out (return -ENOSYS or similar) in map/unmap
>>> API of the when the DRI module is too old.
>>> Just some ^^ food for thought.
>> Hmm. Is there even a use-case for gbm with those drivers? If so we
>> should perhaps make them up-to-date with the flush extension.
>>
> Of the above:
>
> - nouveau: Does not support DRI_IMAGE, thus it doesn't work even
> before the patch.
> - i915: I have some untested ancient patches. Will see if I can rebase
> + send out.
> - radeons: ??
>
> If someone reports an issue we can ask them to write/test some code, I guess 
> ;-)

Indeed. It looks like gbm is mostly used together with KMS anyway...

/Thomas


>
> -Emil


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-29 Thread Emil Velikov 
On 29 March 2017 at 13:02, Thomas Hellstrom  wrote:
> Hi, Emil,
>
> On 03/29/2017 01:30 PM, Emil Velikov wrote:
>> Hi Thomas,
>>
>> On 28 March 2017 at 20:39, Thomas Hellstrom  wrote:
>>> Drivers may queue dma operations on the context at unmap time so we need
>>> to flush to make sure the data gets to the bo. Ideally the application
>>> would take care of this, but since there appears to be no exported gbm
>>> flush functionality we need to explicitly flush at unmap time.
>>>
>>> This fixes a problem where kmscube on vmwgfx in rgba textured mode would
>>> render using an uninitialized texture rather than the intended
>>> rgba pattern.
>>>
>> I haven't checked but the issue should not be restricted to vmwgfx, right ?
>>
>> Perhaps we should add the following
>> Fixes: 8aeb6d768b4 ("gbm: Add map/unmap functions")
>> CC: 
>
> Unfortunately I've, perhaps a bit prematurely, already pushed the fix.
> Is there a way to get it
> into stable after push?
>
Adding mesa-stable@ to the CC list should do it. Check out the
instructions for more examples.

https://www.mesa3d.org/submittingpatches.html#nominations

>
>>
>>> Signed-off-by: Thomas Hellstrom 
>>> ---
>>>  src/gbm/backends/dri/gbm_dri.c | 9 -
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>>> index ac7ede8..6c2244c 100644
>>> --- a/src/gbm/backends/dri/gbm_dri.c
>>> +++ b/src/gbm/backends/dri/gbm_dri.c
>>> @@ -243,7 +243,7 @@ struct dri_extension_match {
>>>  };
>>>
>>>  static struct dri_extension_match dri_core_extensions[] = {
>>> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
>>> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
>> Currently the classic nouveau, radeon/r200 and i915 drivers do not
>> support v4 of the extension.
>> As-is this will 'break' them... if they ever worked to begin with.
>>
>> One solution is to bail out (return -ENOSYS or similar) in map/unmap
>> API of the when the DRI module is too old.
>> Just some ^^ food for thought.
>
> Hmm. Is there even a use-case for gbm with those drivers? If so we
> should perhaps make them up-to-date with the flush extension.
>
Of the above:

- nouveau: Does not support DRI_IMAGE, thus it doesn't work even
before the patch.
- i915: I have some untested ancient patches. Will see if I can rebase
+ send out.
- radeons: ??

If someone reports an issue we can ask them to write/test some code, I guess ;-)

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-29 Thread Thomas Hellstrom 
Hi, Emil,

On 03/29/2017 01:30 PM, Emil Velikov wrote:
> Hi Thomas,
>
> On 28 March 2017 at 20:39, Thomas Hellstrom  wrote:
>> Drivers may queue dma operations on the context at unmap time so we need
>> to flush to make sure the data gets to the bo. Ideally the application
>> would take care of this, but since there appears to be no exported gbm
>> flush functionality we need to explicitly flush at unmap time.
>>
>> This fixes a problem where kmscube on vmwgfx in rgba textured mode would
>> render using an uninitialized texture rather than the intended
>> rgba pattern.
>>
> I haven't checked but the issue should not be restricted to vmwgfx, right ?
>
> Perhaps we should add the following
> Fixes: 8aeb6d768b4 ("gbm: Add map/unmap functions")
> CC: 

Unfortunately I've, perhaps a bit prematurely, already pushed the fix.
Is there a way to get it
into stable after push?


>
>> Signed-off-by: Thomas Hellstrom 
>> ---
>>  src/gbm/backends/dri/gbm_dri.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index ac7ede8..6c2244c 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -243,7 +243,7 @@ struct dri_extension_match {
>>  };
>>
>>  static struct dri_extension_match dri_core_extensions[] = {
>> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
>> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
> Currently the classic nouveau, radeon/r200 and i915 drivers do not
> support v4 of the extension.
> As-is this will 'break' them... if they ever worked to begin with.
>
> One solution is to bail out (return -ENOSYS or similar) in map/unmap
> API of the when the DRI module is too old.
> Just some ^^ food for thought.

Hmm. Is there even a use-case for gbm with those drivers? If so we
should perhaps make them up-to-date with the flush extension.

>
> -Emil

/Thomas



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-29 Thread Emil Velikov 
Hi Thomas,

On 28 March 2017 at 20:39, Thomas Hellstrom  wrote:
> Drivers may queue dma operations on the context at unmap time so we need
> to flush to make sure the data gets to the bo. Ideally the application
> would take care of this, but since there appears to be no exported gbm
> flush functionality we need to explicitly flush at unmap time.
>
> This fixes a problem where kmscube on vmwgfx in rgba textured mode would
> render using an uninitialized texture rather than the intended
> rgba pattern.
>
I haven't checked but the issue should not be restricted to vmwgfx, right ?

Perhaps we should add the following
Fixes: 8aeb6d768b4 ("gbm: Add map/unmap functions")
CC: 

> Signed-off-by: Thomas Hellstrom 
> ---
>  src/gbm/backends/dri/gbm_dri.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index ac7ede8..6c2244c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -243,7 +243,7 @@ struct dri_extension_match {
>  };
>
>  static struct dri_extension_match dri_core_extensions[] = {
> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
Currently the classic nouveau, radeon/r200 and i915 drivers do not
support v4 of the extension.
As-is this will 'break' them... if they ever worked to begin with.

One solution is to bail out (return -ENOSYS or similar) in map/unmap
API of the when the DRI module is too old.
Just some ^^ food for thought.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-29 Thread Marek Olšák 
Reviewed-by: Marek Olšák 

Marek

On Tue, Mar 28, 2017 at 9:39 PM, Thomas Hellstrom  wrote:
> Drivers may queue dma operations on the context at unmap time so we need
> to flush to make sure the data gets to the bo. Ideally the application
> would take care of this, but since there appears to be no exported gbm
> flush functionality we need to explicitly flush at unmap time.
>
> This fixes a problem where kmscube on vmwgfx in rgba textured mode would
> render using an uninitialized texture rather than the intended
> rgba pattern.
>
> Signed-off-by: Thomas Hellstrom 
> ---
>  src/gbm/backends/dri/gbm_dri.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index ac7ede8..6c2244c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -243,7 +243,7 @@ struct dri_extension_match {
>  };
>
>  static struct dri_extension_match dri_core_extensions[] = {
> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
> { __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
> { __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
> { __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
> @@ -992,6 +992,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
>return;
>
> dri->image->unmapImage(dri->context, bo->image, map_data);
> +
> +   /*
> +* Not all DRI drivers use direct maps. They may queue up DMA operations
> +* on the mapping context. Since there is no explicit gbm flush
> +* mechanism. We need to flush here.
> +*/
> +   dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 0);
>  }
>
>
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-29 Thread Thomas Hellstrom 
On 03/28/2017 10:36 PM, Eric Anholt wrote:
> Thomas Hellstrom  writes:
>
>> Drivers may queue dma operations on the context at unmap time so we need
>> to flush to make sure the data gets to the bo. Ideally the application
>> would take care of this, but since there appears to be no exported gbm
>> flush functionality we need to explicitly flush at unmap time.
>>
>> This fixes a problem where kmscube on vmwgfx in rgba textured mode would
>> render using an uninitialized texture rather than the intended
>> rgba pattern.
>>
>> Signed-off-by: Thomas Hellstrom 
>> ---
>>  src/gbm/backends/dri/gbm_dri.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index ac7ede8..6c2244c 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -243,7 +243,7 @@ struct dri_extension_match {
>>  };
>>  
>>  static struct dri_extension_match dri_core_extensions[] = {
>> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
>> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
>> { __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
>> { __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
>> { __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
>> @@ -992,6 +992,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
>>return;
>>  
>> dri->image->unmapImage(dri->context, bo->image, map_data);
>> +
>> +   /*
>> +* Not all DRI drivers use direct maps. They may queue up DMA operations
>> +* on the mapping context. Since there is no explicit gbm flush
>> +* mechanism. We need to flush here.
> With the following change:
>
> s/mechanism. We/mechanism, we/
>
> Reviewed-by: Eric Anholt 
>
> Reminder for anyone else looking at this patch: The context being
> flushed here isn't some main GL context made by the app, it's this
> little dummy context that was created internally in gbm so that these
> kinds of GPU transfers could be done for the image mapping functions.

Thanks for reviewing. Suggested change incorporated.

/Thomas





>> +*/
>> +   dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 
>> 0);
>>  }



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-28 Thread Eric Anholt 
Thomas Hellstrom  writes:

> Drivers may queue dma operations on the context at unmap time so we need
> to flush to make sure the data gets to the bo. Ideally the application
> would take care of this, but since there appears to be no exported gbm
> flush functionality we need to explicitly flush at unmap time.
>
> This fixes a problem where kmscube on vmwgfx in rgba textured mode would
> render using an uninitialized texture rather than the intended
> rgba pattern.
>
> Signed-off-by: Thomas Hellstrom 
> ---
>  src/gbm/backends/dri/gbm_dri.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index ac7ede8..6c2244c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -243,7 +243,7 @@ struct dri_extension_match {
>  };
>  
>  static struct dri_extension_match dri_core_extensions[] = {
> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
> { __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
> { __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
> { __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
> @@ -992,6 +992,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
>return;
>  
> dri->image->unmapImage(dri->context, bo->image, map_data);
> +
> +   /*
> +* Not all DRI drivers use direct maps. They may queue up DMA operations
> +* on the mapping context. Since there is no explicit gbm flush
> +* mechanism. We need to flush here.

With the following change:

s/mechanism. We/mechanism, we/

Reviewed-by: Eric Anholt 

Reminder for anyone else looking at this patch: The context being
flushed here isn't some main GL context made by the app, it's this
little dummy context that was created internally in gbm so that these
kinds of GPU transfers could be done for the image mapping functions.

> +*/
> +   dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 0);
>  }


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gbm/dri: Flush after unmap

2017-03-28 Thread Thomas Hellstrom 
Drivers may queue dma operations on the context at unmap time so we need
to flush to make sure the data gets to the bo. Ideally the application
would take care of this, but since there appears to be no exported gbm
flush functionality we need to explicitly flush at unmap time.

This fixes a problem where kmscube on vmwgfx in rgba textured mode would
render using an uninitialized texture rather than the intended
rgba pattern.

Signed-off-by: Thomas Hellstrom 
---
 src/gbm/backends/dri/gbm_dri.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index ac7ede8..6c2244c 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -243,7 +243,7 @@ struct dri_extension_match {
 };
 
 static struct dri_extension_match dri_core_extensions[] = {
-   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
+   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
{ __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
{ __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
{ __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
@@ -992,6 +992,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
   return;
 
dri->image->unmapImage(dri->context, bo->image, map_data);
+
+   /*
+* Not all DRI drivers use direct maps. They may queue up DMA operations
+* on the mapping context. Since there is no explicit gbm flush
+* mechanism. We need to flush here.
+*/
+   dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 0);
 }
 
 
-- 
2.5.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev