04:01anholt_: progress: https://gitlab.freedesktop.org/anholt/mesa/-/jobs/1523950
04:12robclark: nice :-)
04:23anholt_: might switch to conserver instead of ser2net on daniels's recommendation, which would also help a lot with debug if I could watch what lava was actually doing instead of trying to read their logs.
09:03imirkin: gah! does someone remember what the rule is wrt texelFetch and srgb?
09:03imirkin: i remember it was something highly unintuitive.
09:13Kayden: ignores the SRGB_DECODE_EXT flag entirely
09:14Kayden: it's as if it's always GL_DECODE_EXT
09:14imirkin: so ... always srgb? or never srgb?
09:18imirkin: (and how does this come out in gallium? do i just look at the format in the sampler view?
09:20Kayden: always srgb
09:20HdkR: https://gitlab.freedesktop.org/mesa/mesa/issues/1867 Wow, this issue has some fun nuggets in it about that
09:20gitbot: Mesa issue 1867 in mesa "texelFetch not retrieving textures properly" [Needs Information, Closed]
09:20Kayden: Yeah, st_atom_texture.c takes care of all of that for you.
09:21Kayden: You just use the sampler view and ignore the whole thing.
09:21imirkin: unrelated - is there an allowance in GL to do max samples = 4 for rgba32, but samples = 8 for everything else?
09:21Kayden: Not a good one.
09:21Kayden: The idea is to advertise MAX_SAMPLES = 4, and apps that use ARB_internalformat_query2 (which is basically 0 apps?) can query and possibly get a higher sample count for specific formats
09:22Kayden: but there's some language that makes that sound sorta illegal too
09:22Kayden: but they were very adamant that doing 8 but not for a few formats was not OK and not allowed
09:22Kayden: even though ... it's basically an entire class of DX hardware that can do that exact thing
09:22imirkin: what does intel do?
09:22imirkin: (or does it not come up?)
09:23Kayden: broken crap
09:23Kayden: haswell was advertising 8 for a long time
09:23Kayden: it would have to drop to 4
09:23imirkin: does it still advertise 8?
09:23Kayden: there were patches to do that, which we were using in our get-it-passing-the-CTS branch, but I don't remember if they ever landed
09:24Kayden: I think they did not
09:27imirkin: hah, looks like nvidia dx10 hw is busted wrt srgb + swizzling
09:27imirkin: it does the decode on the wrong side of the swizzle it seems
09:29kusma: jekstrand: awesome, thanks for taking a look! I'll test with your change ASAP :)
14:32Vanfanel: Hi! Do you guys know if glDiscardFramebufferEXT is implemented in the MESA GLES2 implementation? Looking at the current MESA 188.8.131.52 sources, it does not look like it is.
14:47Vanfanel: Oh, sorry, glDiscardFramebufferEXT() seems to be implemented in src/mesa/main/fbobject.c. But then, not all GLES2 implementations in MESA seem to support it.
14:47Vanfanel: Is VC4 Gallium supposed to support it?
14:58flto: Vanfanel: note that glDiscardFramebufferEXT() being a no-op is valid behavior.. but it should have the expected behavior on freedreno at least, no idea about vc4
15:03Vanfanel: flto: from what I see, glDiscardFramebufferEXT() is exposed if GL_GLEXT_PROTOTYPES is defined. That is OK. But then, there is no implementation, so I get an "undeclared symbol" for it when linking. So, do you know what am I missing here, please?
15:03Vanfanel: flto: to my knowledge, what is happening to me is that there is a prototype for it but not an actual implementation.
15:04Vanfanel: So, being a no-op is ok, but only if the code can build and link
15:05bnieuwenhuizen: since it is an ext, maybe you need to use eglGetProcAddress?
15:06flto: Vanfanel: if you don't want to use eglGetProcAddress, there's glInvalidateFramebuffer
15:09Vanfanel: flto: isnt glInvalidateFramebuffer() an Android-only thing? I can not see its prototype in the MESA GLES2 headers on my system
15:10flto: it is the GLES3 version of glDiscardFramebufferEXT
15:13Vanfanel: bnieuwenhuizen: I am already trying with eglGetProcAddress, with no luck, same undefined symbol error on linking
15:13Vanfanel: flto: but VC4 Gallium driver is GLES2 only
15:14pq: Vanfanel, never use GL_GLEXT_PROTOTYPES. Use glxGetProcAddress/eglGetProcAddress instead.
15:15pq: that is exactly to avoid the undefined symbol errors
15:17pq: Vanfanel, IOW, do not try to call the function directly. Instead, define a function pointer variable, check that the GL version or extension string actually says the function is available, and fetch the function pointer with GetProcAddress.
15:18pq: Vanfanel, if that seems an awful lot of typing for every single extension function, you can use a library like libepoxy.
15:30Vanfanel: pq: good suggestion, thanks!
20:32Viciouss: I'm trying to build mesa 20.0 with aosp and there are some compilation issues with mako, in the installation info on mesa3d.org a repository/jenkins job from rob h is mentioned for the aosp build but there is no link. could anyone help me out here?
20:32humand: is there any external way of injecting faults to test GL_ARB_robustness / EGL_EXT_create_context_robustness from driver sources (e.g. DRM_IOCTL_I915_GET_RESET_STATS)?
20:41imirkin: chrisf: fyi, created a PR for VK-GL-CTS to better support older things: https://github.com/KhronosGroup/VK-GL-CTS/pull/189
20:41gitbot: KhronosGroup issue (Pull request) 189 in VK-GL-CTS "Improve support for KHR-GL33.* tests" [Open]
21:11Kayden: humand: there's a hangcheck test in igt IIRC. personally I've been using a mesa patch: https://gitlab.freedesktop.org/kwg/mesa/commit/ec5adea5c05da79d68c76b916dd433680e5fa5f9
21:11Kayden: every 40000 batches, tank the GPU
21:11Kayden: then just like, run glxgears with that mesa or something.
21:19humand: Kayden: just what I needed, thanks
22:32bnieuwenhuizen: Kayden: I think deqp also has some infinite shader loops
22:33Kayden: yeah true
22:34Kayden: I just wanted to crash hard with a page fault rather than be actually running a program beyond a certain time