08:14 j4ni: airlied: ping about http://mid.mail-archive.com/87lfr3rkry.fsf@intel.com
08:51 airlied: j4ni: was waiting to get back to work to bother with next, will process it tomorrow
08:56 j4ni: airlied: okay, thanks. no rush, was just wondering if it's the holidays or fallen between the cracks
14:05 robert_mader: Hello there. I have a question concerning EGL_KHR_swap_buffers_with_damage on Wayland: does it guarantee me that the buffer is up-to-date completely? That is, is it enough to always just use EGL_KHR_swap_buffers_with_damage or do I have to make sure myself that the changes from previous frames are also painted to the current buffer, even if I don't want to mark them as damaged?
14:09 robert_mader: The reason I'm asking is that people are currently trying to implement partial damage for firefox and I'd like to make sure they are not hitting a mesa bug here https://bugzilla.mozilla.org/show_bug.cgi?id=1484812
14:13 robert_mader: Oh never mind, the spec says it: To be clear; the entire contents
14:13 robert_mader: of the back buffer will still be swapped to the front so
14:13 robert_mader: applications using this API must still ensure that the entire
14:13 robert_mader: back buffer is consistent.
14:14 imirkin_: robert_mader: i think the damage stuff is to help tilers out with not redoing every tile if not necessary
14:15 imirkin_: a perfectly valid implementation would be to just ignore the damage stuff entirely
14:16 robert_mader: imirkin_: right, I was just not sure if the extension does help me with keeping the buffer up-to-date, but apparently it does not. It only allows me to give hints to the compositor
14:17 imirkin_: exactly
14:17 imirkin_: it'd be a valid impl to just reimplement it with swap_buffers_without_damage :)
14:25 shakesoda: urjaman: thanks!
15:24 tomeu: how is separate_z32s8 supposed to work? when the app tries to upload data, mesa seems to not be aware of the stencil being in a separate buffer, and tries to write the depth alternated with the stencil in https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/main/pack.c#L983
15:24 tomeu: so it accesses past the buffer in the last line
15:24 tomeu: (besides writing garbage in the rest, but I'm more interested in avoiding crashes than in correctness, right now)
15:38 tomeu: ah, got it, internal_format needs to be different from format
17:13 alyssa: OA
17:14 alyssa: tomeu: separate_stencil, everyone's favourite
18:53 robclark: anyone know offhand what desktop gl version/extensions are required for webgl2?
18:55 linkmauve: robclark, OpenGL 4.3 has GL_ARB_ES3_compatibility, but some of that can probably be emulated before.
18:56 robclark: huh, that is unfortunate/annoying
18:56 robclark: (for drivers that have sufficient gles but not gl 4.3)
18:56 linkmauve: “OpenGL 3.3, ARB_ES2_compatibility, ARB_invalidate_subdata, and ARB_texture_storage are required.”
18:57 linkmauve: Plus ETC2 and EAC compressed textures.
18:57 linkmauve: That’s for ES 3.0 support.
18:58 robclark: ok, that's not too bad.. a6xx is *nearly* at gl3.3..
18:58 imirkin_: GL_ARB_ES3_compatibility is an ext on its own
18:58 imirkin_: which should be exposable on GL3+ drivers
18:59 robclark: hmm, ok.. I guess I should check then why that is not exposed
18:59 imirkin_: it's not for freedreno? that's highly surprising
18:59 imirkin_: maybe it's core-only? that'd be surprising too.
18:59 robclark: oh, actually it is exposed..
19:00 robclark: so maybe it is ffox/chromium being lame and looking for more than just that extension
19:00 imirkin_: ARB_ES3_1_compatibility has the annoying dependency on, effectively, ARB_compute_shader, which in turn has other implications
19:00 robclark: afaiu webgl2 is basically just gles3.0
19:01 linkmauve: Note that I’m not sure if ANGLE or whatever translation shim browsers use actually requires this extension, or if they do it in some other way when it’s not.
19:01 imirkin_: basically those *_compat exts get you the ability ot say "#version 300 es" or whatever in glsl
19:01 imirkin_: and have it work
19:01 imirkin_: and very little if anything beyond that
19:03 imirkin_: and you can expose it even if you don't have full feature parity... e.g the ES3_2 one can be exposed even if you don't do ASTC
19:04 robclark: hmm, so I guess mesa *should* be exposing the ES3_1_compat extension.. but presumably the browser should only be looking for ES3_compat
19:05 imirkin_: all this information is a mere glxinfo away :)
19:06 alyssa: linkmauve: fancy seeing you here :p
19:06 linkmauve: alyssa, hi!
19:07 linkmauve: I’ve been here for years. ^^
19:07 alyssa:struggling to debug blend shader madness
19:07 alyssa: I thought it would be a good idea to do 8-bit things
19:07 alyssa: itwasnotagoodidea
19:10 robclark: so, from trial/error, it seems like ffox is looking for at least gl3.2.. this works: MESA_GL_VERSION_OVERRIDE=3.2 firefox http://webglsamples.org/WebGL2Samples/
19:10 alyssa:jealous that y'all have 8 MRT support so GL3 is an option
19:11 imirkin_: alyssa: for a3xx, we just lie.
19:11 robclark: yeah, a3xx is only 4 MRT
19:12 robclark: (not that I've ever seen anything use more than 4 MRTs)
19:13 alyssa: Fair
19:13 alyssa: And then our early midgard don't support any MRT
19:13 imirkin_: we lie about a lot of things
19:13 alyssa: despite advertising ES3.1
19:13 alyssa: the lowering ain't pretty
19:13 imirkin_: but it just mostly doesn't matter
19:13 imirkin_: edge flags, separate front/back polygon modes
19:42 robclark: looks like for gl32 we just need glsl 150 (vs 140) and ARB_depth_clamp.. and gl33 needs glsl 330 and ARB_depth_clamp
19:42 robclark: possibly we should be already exposing a higher glsl
19:43 imirkin_: one minor little thing gl3.2 needs are geometry shaders
19:43 robclark: well, we have that part ;-)
19:43 imirkin_: oh
19:43 imirkin_: ARB_depth_clamp works on a3xx/a4xx, but try as i might, couldn't crack the a5xx nut
19:43 imirkin_: i checked every bit, and it was none of them :)
19:44 robclark: (not exposed on a release branch.. but I think deqp is happy enough.. I think we have all the sysmem vs gmem things sorted)
19:45 imirkin_: right, for a6xx?
19:45 robclark: yeah
19:45 imirkin_: i'm sure a5xx has the depth clamp thing somewhere
19:46 imirkin_: the trick is that it's not just for clipping, it's also clamping the literal Z values at the RB level
19:46 robclark: I don't suppose there is a gles version of that extension?
19:46 imirkin_: iirc i managed to disable the depth check
19:46 imirkin_: but not the actual clamping
19:46 imirkin_: i think someone added one recently, but it's not supported by anything
19:47 imirkin_: it was to make virgl work with GL over GLES or something
19:47 robclark: ahh, makes sense
19:47 imirkin_: there are some decent piglits though
19:48 imirkin_: that's how i tracked down the bits for a3xx/a4xx -- just have a for loop setting each bit and checking piglit results
19:48 imirkin_: env vars ftw!
19:48 robclark: heh
19:49 imirkin_: obviously i didn't check _every_ register, but ...
19:49 imirkin_: you're looking for 16x min/max floats somewhere (for 16 viewport settings)
19:49 imirkin_: + bits to enable the clamping + bits to disabling the clipping
19:50 imirkin_: (sometimes those will be separate for near/far, sometimes combined)
19:53 robclark: looks like a4xx had separate near/far bits
19:53 imirkin_: yeah, a4xx should be all set for ARB_depth_clamp
19:53 imirkin_: a3xx shows failures in some of the tests, but that's due to precision fail iirc
19:55 robclark: for a6xx, looks like it involves finding a register we don't know about yet
19:56 imirkin_: not just the one
19:56 imirkin_: you need the equivalent of these: A4XX_GRAS_CL_CLIP_CNTL_ZNEAR_CLIP_DISABLE | A4XX_GRAS_CL_CLIP_CNTL_ZFAR_CLIP_DISABLE
19:57 imirkin_: and this one: A4XX_RB_DEPTH_CONTROL_Z_CLAMP_ENABLE
19:57 robclark: right.. looks like we at least have a GRAS_CL_CLIP_CNTL in a5xx.. but doesn't look like we've found it in a6xx.. although mostly only been looking at gles features, so haven't looked too hard
19:58 imirkin_: and these ones: REG_A4XX_RB_VPORT_Z_CLAMP
20:06 alyssa: OA3
20:06 alyssa: OA34
20:07 alyssa: xoffy
20:07 alyssa: *sorry
22:11 anholt_: daniels: looks like gitlab 12.6 broke marge: https://gitlab.com/gitlab-org/gitlab/issues/121620
22:11 anholt_: (and I didn't look at gitlab version initially because i didn't see it get bumped in the helm repo)
22:13 daniels: ffffuuuuuuuuuuuuu-
22:14 alyssa: daniels: sounds like someone's having fun :)
22:32 anholt_: airlied: I didn't see a branch in your repo, I did go looking first
22:40 airlied: anholt_: it's hiding in my old repo I think
22:40 anholt_: Mmm. Aging in your code cellar.
22:43 airlied: anholt_: yeah it's abanboned now for me
22:43 airlied: since I got llvmpipe to use nir instead
22:44 airlied: anholt_: https://paste.centos.org/view/b40d4f49 was the last diff I had
22:44 airlied: not sure if any of it is useful at this point
22:44 anholt_: airlied: I'll scavenge that and add a note about partial authorship if that sounds good
22:44 airlied: sounds good to me
22:45 airlied: anholt_: I feel hooking it into softpipe and running piglits in both ways might be a good way to get it further along
22:46 anholt_: airlied: that's the plan!
22:46 anholt_: well, seeing what happens to softpipe in CI if we flip the switch
22:46 anholt_: should probably rig up softpipe piglit though.
22:55 airlied: am I right in thinking the the spirv rem vs mod different is just which operand picks the sign
23:09 airlied: j4ni: turns out I'd already pulled it locally, just hadn't pushed it out!
23:13 airlied: uggh tip conflict in i915 :-(