Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Trevor Woerner]

Even without the patch, simply adding:

PACKAGECONFIG_append_pn-mesa = "dri3"

to my conf/local.conf has glmark2-es2 running, and chromium-x11 is running
accelerated out-of-the-box (i.e. I don't have to install the egl/gles
libraries it builds itself).

I'm re-building my rpi3-64 image to see if things are better there too under
vc4.

I guess the patch is to address some of the other things you were seeing?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Andreas Müller]

On Mon, Apr 2, 2018 at 3:05 PM, Andreas Müller  wrote:
> On Mon, Apr 2, 2018 at 2:42 PM, Daniel Stone  wrote:
>> Hi Andreas,
>>
>> On 31 March 2018 at 15:18, Andreas Müller  wrote:
>>> Thanks for prompt an VERY helpful support. I did:
>>>
>>> * Check my configure and found: --disable-dri3!
>>> * Tested your patch (with --disable-dri3) and as expected it fixes the issue
>>> * Found what causes --disable-dri3 - it came in by the Openembedded
>>> update mentioned in first email. FWIW: I use a fork for
>>> meta-raspberrypi - the original is not affected so I am the only one
>>> with this issue...
>>
>> Glad to hear it!
>>
>>> I have two questions related to dri2/your patch (sorry asking for more :)
>>>
>>> 1. Your patch fixes improper initialized variable. Do you think it is
>>> worth being applied?
>>
>> Yes, definitely: I've sent it in now. It's sadly missed 17.3.8
>> (scheduled to be released about an hour ago), but hopefully we can get
>> it in for a 17.3.9, if we have one. Else it'll be in 18.0.1.
>>
>>> 2. In the thread I mentioned in my first email Trevor mentioned that
>>> he has seen error message 'Modifier 0x0 vs. tiling(0x7001)
>>> mismatch' when trying to get chromium GLES accelerated. Maybe a stupid
>>> question but is it possible that applications running at X can ask for
>>> dri2 explicitly?
>>
>> He said that only happened when using the system (rather than bundled)
>> libraries, which would presumably be using DRI2 by default. I've
>> submitted a bug to OE to ask them to enable DRI3 by default, but in
>> the meantime this Mesa fix should hopefully work anyway.
> Thanks - I was thinking same. OE-Core enables DRI3 for x11 AND vulcan
> only - and vulcan is not in my distro features (and does not make much
> sense for VC4)
>
> Added yocto mailing list to merge both threads together and avoid cross-tak.
>
> Thanks again for taking care
>
Hi Daniel,

Just sent out patches to oe-core

* Apply your patch with dri2 modifier init
* Prefer dri3 over dri2 for x11/opengl distro features

See what happens...

Cheers

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Andreas Müller]

On Mon, Apr 2, 2018 at 2:42 PM, Daniel Stone  wrote:
> Hi Andreas,
>
> On 31 March 2018 at 15:18, Andreas Müller  wrote:
>> Thanks for prompt an VERY helpful support. I did:
>>
>> * Check my configure and found: --disable-dri3!
>> * Tested your patch (with --disable-dri3) and as expected it fixes the issue
>> * Found what causes --disable-dri3 - it came in by the Openembedded
>> update mentioned in first email. FWIW: I use a fork for
>> meta-raspberrypi - the original is not affected so I am the only one
>> with this issue...
>
> Glad to hear it!
>
>> I have two questions related to dri2/your patch (sorry asking for more :)
>>
>> 1. Your patch fixes improper initialized variable. Do you think it is
>> worth being applied?
>
> Yes, definitely: I've sent it in now. It's sadly missed 17.3.8
> (scheduled to be released about an hour ago), but hopefully we can get
> it in for a 17.3.9, if we have one. Else it'll be in 18.0.1.
>
>> 2. In the thread I mentioned in my first email Trevor mentioned that
>> he has seen error message 'Modifier 0x0 vs. tiling(0x7001)
>> mismatch' when trying to get chromium GLES accelerated. Maybe a stupid
>> question but is it possible that applications running at X can ask for
>> dri2 explicitly?
>
> He said that only happened when using the system (rather than bundled)
> libraries, which would presumably be using DRI2 by default. I've
> submitted a bug to OE to ask them to enable DRI3 by default, but in
> the meantime this Mesa fix should hopefully work anyway.
Thanks - I was thinking same. OE-Core enables DRI3 for x11 AND vulcan
only - and vulcan is not in my distro features (and does not make much
sense for VC4)

Added yocto mailing list to merge both threads together and avoid cross-tak.

Thanks again for taking care

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7

[Daniel Stone]

Hi Andreas,

On 31 March 2018 at 15:18, Andreas Müller  wrote:
> Thanks for prompt an VERY helpful support. I did:
>
> * Check my configure and found: --disable-dri3!
> * Tested your patch (with --disable-dri3) and as expected it fixes the issue
> * Found what causes --disable-dri3 - it came in by the Openembedded
> update mentioned in first email. FWIW: I use a fork for
> meta-raspberrypi - the original is not affected so I am the only one
> with this issue...

Glad to hear it!

> I have two questions related to dri2/your patch (sorry asking for more :)
>
> 1. Your patch fixes improper initialized variable. Do you think it is
> worth being applied?

Yes, definitely: I've sent it in now. It's sadly missed 17.3.8
(scheduled to be released about an hour ago), but hopefully we can get
it in for a 17.3.9, if we have one. Else it'll be in 18.0.1.

> 2. In the thread I mentioned in my first email Trevor mentioned that
> he has seen error message 'Modifier 0x0 vs. tiling(0x7001)
> mismatch' when trying to get chromium GLES accelerated. Maybe a stupid
> question but is it possible that applications running at X can ask for
> dri2 explicitly?

He said that only happened when using the system (rather than bundled)
libraries, which would presumably be using DRI2 by default. I've
submitted a bug to OE to ask them to enable DRI3 by default, but in
the meantime this Mesa fix should hopefully work anyway.

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7

[Andreas Müller]

On Fri, Mar 30, 2018 at 4:41 PM, Daniel Stone  wrote:
> Hi Andreas,
>
> On 30 March 2018 at 15:18, Andreas Müller  wrote:
>> What happened: I build all images cross with Openembedded/Yocto. To
>> prepare next release there I updated my builds and that moved mesa
>> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
>> glmark2-es - tried others - same) complain with
>>
>> | Modifier 0x0 vs. tiling (0x701) mismatch
>>
>> and drawable region remains black.
>> There was some discussion on meta-raspberrypi mailing list and it
>> seems to happen to others too [1].
>>
>> I've attached a patch. That fixes glmark2-es and many others but e.g
>> on KDE desktop mouse pointer is just pixel dust so I think that my
>> (naive) approach only works around an issue caused somewhere else. To
>> ne honest my background understanding is poor but it seems that
>> modifier gets not properly for all cases.
>
> Odd. That happens when something has already allocated the buffer as a
> tiled buffer, but Mesa is being told that the buffer is linear. Are
> you able to get a backtrace from when this error happens? (Either set
> a breakpoint by hand, or just add 'uint32_t *crash = NULL; *crash =
> 1;' to force a segfault.)
>
> I could only find one place where this would happen, which is when
> using the old DRI2 interface with Gallium, but it really should be
> using DRI3 ... nonetheless, does the attached patch help at all?
>
> Cheers,
> Daniel
Hi Daniel,

Thanks for prompt an VERY helpful support. I did:

* Check my configure and found: --disable-dri3!
* Tested your patch (with --disable-dri3) and as expected it fixes the issue
* Found what causes --disable-dri3 - it came in by the Openembedded
update mentioned in first email. FWIW: I use a fork for
meta-raspberrypi - the original is not affected so I am the only one
with this issue...

I have two questions related to dri2/your patch (sorry asking for more :)

1. Your patch fixes improper initialized variable. Do you think it is
worth being applied?
2. In the thread I mentioned in my first email Trevor mentioned that
he has seen error message 'Modifier 0x0 vs. tiling(0x7001)
mismatch' when trying to get chromium GLES accelerated. Maybe a stupid
question but is it possible that applications running at X can ask for
dri2 explicitly?

Cheers

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7

[Daniel Stone]

Hi Andreas,

On 30 March 2018 at 15:18, Andreas Müller  wrote:
> What happened: I build all images cross with Openembedded/Yocto. To
> prepare next release there I updated my builds and that moved mesa
> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
> glmark2-es - tried others - same) complain with
>
> | Modifier 0x0 vs. tiling (0x701) mismatch
>
> and drawable region remains black.
> There was some discussion on meta-raspberrypi mailing list and it
> seems to happen to others too [1].
>
> I've attached a patch. That fixes glmark2-es and many others but e.g
> on KDE desktop mouse pointer is just pixel dust so I think that my
> (naive) approach only works around an issue caused somewhere else. To
> ne honest my background understanding is poor but it seems that
> modifier gets not properly for all cases.

Odd. That happens when something has already allocated the buffer as a
tiled buffer, but Mesa is being told that the buffer is linear. Are
you able to get a backtrace from when this error happens? (Either set
a breakpoint by hand, or just add 'uint32_t *crash = NULL; *crash =
1;' to force a segfault.)

I could only find one place where this would happen, which is when
using the old DRI2 interface with Gallium, but it really should be
using DRI3 ... nonetheless, does the attached patch help at all?

Cheers,
Daniel
diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c
index 31d17d46c29..58a6757f037 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -806,6 +806,7 @@ dri2_allocate_textures(struct dri_context *ctx,
  whandle.handle = buf->name;
  whandle.stride = buf->pitch;
  whandle.offset = 0;
+ whandle.modifier = DRM_FORMAT_MOD_INVALID;
  if (screen->can_share_buffer)
 whandle.type = DRM_API_HANDLE_TYPE_SHARED;
  else
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7

[Andreas Müller]

On Fri, Mar 30, 2018 at 4:18 PM, Andreas Müller  wrote:
> Hi,
>
> hope here is the right place for this - my first post.
>
> What happened: I build all images cross with Openembedded/Yocto. To
> prepare next release there I updated my builds and that moved mesa
> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
> glmark2-es - tried others - same) complain with
>
> | Modifier 0x0 vs. tiling (0x701) mismatch
>
> and drawable region remains black.
> There was some discussion on meta-raspberrypi mailing list and it
> seems to happen to others too [1].
>
> I've attached a patch. That fixes glmark2-es and many others but e.g
> on KDE desktop mouse pointer is just pixel dust so I think that my
> (naive) approach only works around an issue caused somewhere else. To
> ne honest my background understanding is poor but it seems that
> modifier gets not properly for all cases.
>
> [1] https://lists.yoctoproject.org/pipermail/yocto/2018-March/040587.html
>
> If further information is required, please let me know.
>
Forgot to mention: At wayland/weston glmark-es2-wayland works without
issues without modification. By source update xserver-xorg moved
1.19.3 -> 1.19.6

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

[Mesa-dev] VC4 not working for me with mesa 17.3.7

[Andreas Müller]

Hi,

hope here is the right place for this - my first post.

What happened: I build all images cross with Openembedded/Yocto. To
prepare next release there I updated my builds and that moved mesa
17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
glmark2-es - tried others - same) complain with

| Modifier 0x0 vs. tiling (0x701) mismatch

and drawable region remains black.
There was some discussion on meta-raspberrypi mailing list and it
seems to happen to others too [1].

I've attached a patch. That fixes glmark2-es and many others but e.g
on KDE desktop mouse pointer is just pixel dust so I think that my
(naive) approach only works around an issue caused somewhere else. To
ne honest my background understanding is poor but it seems that
modifier gets not properly for all cases.

[1] https://lists.yoctoproject.org/pipermail/yocto/2018-March/040587.html

If further information is required, please let me know.

Regards

Andreas
From 5012db89d3704d383e455376922bd45f45b5683f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
Date: Thu, 29 Mar 2018 22:18:25 +0200
Subject: [PATCH] VC4: Do not error out when linear modifier is requested but
 kernel supports tiling
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes:
| Modifier 0x0 vs. tiling (0x701) mismatch

and black screen for glmark2

Tested withj mesa 17.3.7

Signed-off-by: Andreas Müller 
---
 src/gallium/drivers/vc4/vc4_resource.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/vc4/vc4_resource.c b/src/gallium/drivers/vc4/vc4_resource.c
index cdcbcc917e..472e6dd618 100644
--- a/src/gallium/drivers/vc4/vc4_resource.c
+++ b/src/gallium/drivers/vc4/vc4_resource.c
@@ -742,6 +742,9 @@ vc4_resource_from_handle(struct pipe_screen *pscreen,
 whandle->modifier = DRM_FORMAT_MOD_LINEAR;
 } else if (whandle->modifier == DRM_FORMAT_MOD_INVALID) {
 whandle->modifier = get_tiling.modifier;
+} else if (whandle->modifier == DRM_FORMAT_MOD_LINEAR && 
+   get_tiling.modifier == DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED) {
+whandle->modifier = get_tiling.modifier;
 } else if (whandle->modifier != get_tiling.modifier) {
 fprintf(stderr,
 "Modifier 0x%llx vs. tiling (0x%llx) mismatch\n",
-- 
2.14.3

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