02:58 <icecream95> It looks like there might be a second bug to do with preload-CRC interactions...

02:59 <icecream95> This time I don't think doing an apitrace of Xephyr -glamor will work, so fixing it might be harder

03:00 <macc24> icecream95: does xephyr on xwayland run faster than xorg?

03:03 <icecream95> macc24: I don't notice a massive difference, but why would you want to do that?

03:05 <macc24> icecream95: if it would run faster... then maybe

03:06 <icecream95> Note that while Xephyr -glamor itself is accelerated, any applications running inside it won't be

03:06 <macc24> why?

03:07 <icecream95> no idea

03:08 <macc24> ok

08:16 <icecream95> Note to self: For apitrace to work for WebGL in Firefox, the sandbox level needs to be turned down, for example security.sandbox.content.level=0

08:29 <amonakov> (yeah, same for Chromium, which had a command-line option)

09:30 <macc24> note to icecream95: there is gfx.apitrace.enabled

09:31 <icecream95> macc24: Did you actually test it? "gfx.apitrace.enabled (ANDROID only)"

09:33 <macc24> oh

09:34 <HdkR> --no-sandbox is the chromium option, I know that one well :P

09:45 <icecream95> alyssa: Remember https://rosenzweig.io/uh.txt? That bug is still there, for example see https://gitlab.freedesktop.org/-/snippets/1947

10:02 <icecream95> The G72 blob puts the ATEST in its own clause

12:36 <daniels> warpme_: your build issue sounds like a gar bug (are you using garnome or something?!) where it doesn't pass a for-build CMake path down to Meson, as it would do for pkgconfig

12:47 <chewitt> bbrezillon Your "drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv" patch was not in 5.13 (so far)

12:47 <chewitt> is this something I should keep or drop from my patch-set?

12:48 <chewitt> the other patch I have is "drm/panfrost: fix reference leak in panfrost_job_hw_submit" .. also not merged

12:49 <chewitt> (not from you, but was sent to mailing lists back in Nov)

13:18 <warpme_> daniels: isn't that llvm cmake path is used for building against static llvm libs? I'm linking with shared llvm libs so i think cmake isn't involved in my case. i still think my build system is ok as it works for x86/aarch64. only arm target has issue.

13:22 <daniels> ah sorry, llvm-config indeed

13:23 <daniels> is the llvm-config path pointed to in the config output actually the correct one to use, and when you call it does it emit paths valid for the target (rather than host) build?

13:42 <warpme_> daniels: whole llvm-config thing in cross-compile is a bit unclear for me. llvm-config is binary called at configure - so to detect llvm at mesa configure i need to provide llvm-config build for build machine arch (x86_64 in my case) - not for target (armv7). But such llvm-config - when asked i.e. for path for llvm libdir - returns path for x86_64 libs - not for armv7 libs (so wrong imho). But it looks like mesa meson

13:42 <warpme_> for aarch64/x86 targets have intelligence to pick correct libllvm - but armv7 target seems not have such intelligence.....

13:43 <daniels> hmm?

13:43 <daniels> llvm-config is just a shell script, like a worse & specialised version of pkg-config

13:43 <daniels> you need to tell Meson where to find the llvm-config which will return the correct paths for your armv7 build

13:43 <warpme_> in my llvm it is binary

13:44 <daniels> oh huh, so it is

13:44 <daniels> in which case you'll need qemu to run the generated binary I suppose

13:46 <warpme_> i overcome this by building 2 llvm builds: "build" & "target". build is only for llvm-config. target is for libs used by target mesa build

13:46 <daniels> but yeah, either way, `llvm-config --libdir` must return the path to where your armv7 LLVM libraries are stored, because that's the way it discovers it

13:46 <daniels> sure

13:46 <daniels> whatever works for the build system to be able to discover the path :)

13:48 <daniels> (on a personal note, I can very strongly recommend whatever works as the path of least resistance and gives you the lowest exposure to LLVM's build system)

13:54 <warpme_> i think description https://docs.mesa3d.org/meson.html#llvm as a bit unclear (imho wrong). In my case it instructs to use "build" version of llvm-config - but this version returns wrong path for llvmlibs....

14:08 <warpme_> nevertheless - mesa cross-compile for armv7 target with llvm is not possible for me. i think this is mesa meson bug....

17:25 <macc24> warpme_: i just remembered that i built mesa with llvm on arm machine

21:48 <bschiett> hi guys, working on some code here and can't figure out how to enable debugging for my openGLES context... i'm on rk3288/mali with panfrost/mesa, using DRM/KMS and EGL

21:50 <HdkR> I'd recommend https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_debug.txt

21:50 <bschiett> i'm passing EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR, to eglCreateContext

21:51 <HdkR> Which KHR_debug is different than a debug context

21:51 <HdkR> Additionally you can use mesa environment variables to help narrow bits down. LIBGL_DEBUG and/or MESA_DEBUG as described https://docs.mesa3d.org/envvars.html

21:52 <HdkR> Additionally https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_debug.txt for the GL/ES side of debugging rather than EGL side :)

21:52 <HdkR> Probably more useful if you're having issues on the GL side than the EGL side

21:53 <bschiett> @HdkR ok thanks, there is inconsistent info online about how to correctly use KHR_debug

21:53 <bschiett> like using glDebugMessageCallback vs glDebugMessageCallbackKHR

21:53 <bschiett> the latter is not in my libGLESv2 i'm linking with.

21:54 <HdkR> This is because you're supposed to be using a function loader instead of pulling symbols by linking to libGLESv2

21:54 <HdkR> Symbol resolution should be done at runtime with eglGetProcAddress

21:56 <bschiett> @HdkR yeah, in the past I used glad on linux desktop with my gpu but for some reason I can't make this work on my rk3288 platform

21:56 <HdkR> Something like libepoxy will handle this transparently

21:57 <HdkR> glad had GL/ES issues last time I tried it

21:58 <HdkR> libepoxy is pretty much perfect :)

21:58 <HdkR> https://www.khronos.org/opengl/wiki/OpenGL_Loading_Library#libepoxy

21:58 <bschiett> @HdkR ok... so you just link with that instead of libGLESv2?

21:59 <HdkR> Yea. Think you may need to adjust some header usage in your application but then it should "just work"

22:03 <HdkR> Github readme has a bit more information to using it https://github.com/anholt/libepoxy

22:04 <bschiett> @HdkR ok thanks. maybe I am just using the wrong functions which is why this debug stuff isn't working.

22:05 <HdkR> Once you get it nailed down then you should get a torrential flood of information through the callback

22:05 <bschiett> @HdkR thanks. I should probably fix this first before enabling the mesa env vars...

22:28 <bschiett> @HdkR do I still need to link with -lGLESv2 ? or just link with -lepoxy?

22:28 <HdkR> Should just need epoxy and egl

22:29 <bschiett> thx

22:30 <HdkR> Maybe not even egl anymore. It might do runtime selection of that?

22:30 <bschiett> @HdkR ok, i'll try without -lEGL ... btw how does it know what GLES version to use?

22:31 <HdkR> Once you create the context and use some GL function it'll query everything

22:31 <HdkR> Voodoo dispatching magic

22:34 <bschiett> btw is GLX required? I didn't enable that in my buildroot config

22:34 <bschiett> it complains about epoxy/glx.h missing

22:35 <bschiett> also can't find egl functions so prolly have to link with -lEGL after all.

22:36 <bschiett> got it compiled now :-)

22:40 <bschiett> @HdkR hmm, callback still not being called. is glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS_KHR); and glDebugMessageCallbackKHR(glDebugOutput, NULL); enough?

22:41 <bschiett> or are the mesa env vars required as well

22:43 <HdkR> You also need glEnable(GL_DEBUG_OUTPUT_KHR)

22:44 <HdkR> the enable you are using only enables the synchronous option, not the debugging itself

22:45 <HdkR> Although this might be a spec bug in mesa, theoretically if you have a debug context that is supposed to be enabled by default...

22:47 <bschiett> ok thanks. so are these KHR suffixes required? or would this also work without the suffixes now that i'm using libepoxy?

22:47 <HdkR> It would also work without the suffixes purely because they are the same value

22:47 <HdkR> Some extensions don't have that so watch out

22:48 <HdkR> You have to make sure to read the spec pages for the extension and core featureset to know when things change, it isn't always entirely clear

22:50 <bschiett> @HdkR btw it's not necessary to link with -lEGL. I forgot to include egl.h in libepoxy which is why I had an issue. so I removed -lEGL and it compiles.

22:50 <HdkR> nice

22:54 <bschiett> @HdkR for some reason callback still not begin claled.

22:55 <bschiett> being claled

22:57 <HdkR> You also need glDebugMessageControl if you're missing that

22:58 <bschiett> @HdkR ah good point

22:58 <HdkR> glDebugMessageControl(GL_DONT_CARE, GL_DONT_CARE, GL_DONT_CARE, 0, nullptr, true);

23:00 <bschiett> glDebugMessageControl or glDebugMessageControlKHR?

23:01 <HdkR> Match the suffix of the other ones you're using

23:03 <bschiett> that didn't fix it. are these the correct flags to set when creating the context ? EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR,

23:04 <HdkR> I don't actually know, debug context and khr_debug can live independently of each other

23:04 <bschiett> @HdkR ok, I thought this khr_debug was actually replacing debug context

23:05 <HdkR> Supplementary

23:05 <bschiett> @HdkR hmm ok

23:19 <bschiett> @HdkR still can't seem to add any other attributes for debugging when creating EGL context

23:19 <bschiett> for example EGL_CONTEXT_OPENGL_DEBUG

23:19 <HdkR> Those are the main ones

23:20 <HdkR> You can also try a glDebugMessageInsert after you've set things up to ensure the callback is actually working

23:20 <bschiett> https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglCreateContext.xhtml specifies EGL_CONTEXT_CLIENT_VERSION can be specified for attrib_list, and I have EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR, as well, but i cannot add EGL_CONTEXT_OPENGL_DEBUG, EGL_TRUE,

23:24 <HdkR> Curious

23:34 <bschiett> @HdkR so I added a call to glDebugMessageInsert and that DOES trigger the callback

23:35 <HdkR> I guess mesa just isn't telling you a failure then :)

23:35 <bschiett> @HdkR so the question is whether I need to add the mesa debug env vars like you mentioned above, for this to debug context to work/

23:35 <HdkR> Nah, those environmente variables will have mesa spam you with messages in stderr

23:41 <bschiett> yeah, then I have no clue what's going on

23:42 <HdkR> Maybe your code has no errors to report :)

23:43 <bschiett> yeah, that could be the case

23:46 <bschiett> @HdkR ok, so I passed an incorrect VAO to a function and I do get a callback now. so you are right, maybe there is nothing to report.

23:46 <HdkR> Nice

23:46 <bschiett> @HdkR question is, why the hell none of my rectangles are being drawn.

23:46 <bschiett> @HdkR I have 3 VBOs, and one VAO. and I'm using glDrawArrays.

23:47 <HdkR> That's a harder one

23:47 <HdkR> Renderdoc has a new feature that could theoretically help with that

23:49 <bschiett> wow that looks awesome

23:50 <bschiett> do you run this on your dev machine and connect to the target over the network?

23:50 <HdkR> Run it on the machine running the program

23:51 <HdkR> You launch it through renderdoc then hit f12 to capture a frame. Works quite well

23:51 <bschiett> run it on the rk3288 board you mean ?

23:51 <HdkR> aye

23:51 <bschiett> I don't have an x server on the board or a keyboard connected

23:52 <HdkR> You should be able to wrap the application with renderdoccmd still

23:52 <bschiett> hmm ok cool going to check that

23:53 <HdkR> Which then might support remote capture, never tested that workflow :)

23:59 <bschiett> @HdkR taking a break here :-) thanks so much for all your help!