08:14j4ni: airlied: ping about http://email@example.com
08:51airlied: j4ni: was waiting to get back to work to bother with next, will process it tomorrow
08:56j4ni: airlied: okay, thanks. no rush, was just wondering if it's the holidays or fallen between the cracks
14:05robert_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:09robert_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:13robert_mader: Oh never mind, the spec says it: To be clear; the entire contents
14:13robert_mader: of the back buffer will still be swapped to the front so
14:13robert_mader: applications using this API must still ensure that the entire
14:13robert_mader: back buffer is consistent.
14:14imirkin_: robert_mader: i think the damage stuff is to help tilers out with not redoing every tile if not necessary
14:15imirkin_: a perfectly valid implementation would be to just ignore the damage stuff entirely
14:16robert_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:17imirkin_: it'd be a valid impl to just reimplement it with swap_buffers_without_damage :)
14:25shakesoda: urjaman: thanks!
15:24tomeu: 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:24tomeu: so it accesses past the buffer in the last line
15:24tomeu: (besides writing garbage in the rest, but I'm more interested in avoiding crashes than in correctness, right now)
15:38tomeu: ah, got it, internal_format needs to be different from format
17:14alyssa: tomeu: separate_stencil, everyone's favourite
18:53robclark: anyone know offhand what desktop gl version/extensions are required for webgl2?
18:55linkmauve: robclark, OpenGL 4.3 has GL_ARB_ES3_compatibility, but some of that can probably be emulated before.
18:56robclark: huh, that is unfortunate/annoying
18:56robclark: (for drivers that have sufficient gles but not gl 4.3)
18:56linkmauve: “OpenGL 3.3, ARB_ES2_compatibility, ARB_invalidate_subdata, and ARB_texture_storage are required.”
18:57linkmauve: Plus ETC2 and EAC compressed textures.
18:57linkmauve: That’s for ES 3.0 support.
18:58robclark: ok, that's not too bad.. a6xx is *nearly* at gl3.3..
18:58imirkin_: GL_ARB_ES3_compatibility is an ext on its own
18:58imirkin_: which should be exposable on GL3+ drivers
18:59robclark: hmm, ok.. I guess I should check then why that is not exposed
18:59imirkin_: it's not for freedreno? that's highly surprising
18:59imirkin_: maybe it's core-only? that'd be surprising too.
18:59robclark: oh, actually it is exposed..
19:00robclark: so maybe it is ffox/chromium being lame and looking for more than just that extension
19:00imirkin_: ARB_ES3_1_compatibility has the annoying dependency on, effectively, ARB_compute_shader, which in turn has other implications
19:00robclark: afaiu webgl2 is basically just gles3.0
19:01linkmauve: 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:01imirkin_: basically those *_compat exts get you the ability ot say "#version 300 es" or whatever in glsl
19:01imirkin_: and have it work
19:01imirkin_: and very little if anything beyond that
19:03imirkin_: 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:04robclark: 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:05imirkin_: all this information is a mere glxinfo away :)
19:06alyssa: linkmauve: fancy seeing you here :p
19:06linkmauve: alyssa, hi!
19:07linkmauve: I’ve been here for years. ^^
19:07alyssa:struggling to debug blend shader madness
19:07alyssa: I thought it would be a good idea to do 8-bit things
19:10robclark: 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:10alyssa:jealous that y'all have 8 MRT support so GL3 is an option
19:11imirkin_: alyssa: for a3xx, we just lie.
19:11robclark: yeah, a3xx is only 4 MRT
19:12robclark: (not that I've ever seen anything use more than 4 MRTs)
19:13alyssa: And then our early midgard don't support any MRT
19:13imirkin_: we lie about a lot of things
19:13alyssa: despite advertising ES3.1
19:13alyssa: the lowering ain't pretty
19:13imirkin_: but it just mostly doesn't matter
19:13imirkin_: edge flags, separate front/back polygon modes
19:42robclark: 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:42robclark: possibly we should be already exposing a higher glsl
19:43imirkin_: one minor little thing gl3.2 needs are geometry shaders
19:43robclark: well, we have that part ;-)
19:43imirkin_: ARB_depth_clamp works on a3xx/a4xx, but try as i might, couldn't crack the a5xx nut
19:43imirkin_: i checked every bit, and it was none of them :)
19:44robclark: (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:45imirkin_: right, for a6xx?
19:45imirkin_: i'm sure a5xx has the depth clamp thing somewhere
19:46imirkin_: the trick is that it's not just for clipping, it's also clamping the literal Z values at the RB level
19:46robclark: I don't suppose there is a gles version of that extension?
19:46imirkin_: iirc i managed to disable the depth check
19:46imirkin_: but not the actual clamping
19:46imirkin_: i think someone added one recently, but it's not supported by anything
19:47imirkin_: it was to make virgl work with GL over GLES or something
19:47robclark: ahh, makes sense
19:47imirkin_: there are some decent piglits though
19:48imirkin_: that's how i tracked down the bits for a3xx/a4xx -- just have a for loop setting each bit and checking piglit results
19:48imirkin_: env vars ftw!
19:49imirkin_: obviously i didn't check _every_ register, but ...
19:49imirkin_: you're looking for 16x min/max floats somewhere (for 16 viewport settings)
19:49imirkin_: + bits to enable the clamping + bits to disabling the clipping
19:50imirkin_: (sometimes those will be separate for near/far, sometimes combined)
19:53robclark: looks like a4xx had separate near/far bits
19:53imirkin_: yeah, a4xx should be all set for ARB_depth_clamp
19:53imirkin_: a3xx shows failures in some of the tests, but that's due to precision fail iirc
19:55robclark: for a6xx, looks like it involves finding a register we don't know about yet
19:56imirkin_: not just the one
19:56imirkin_: you need the equivalent of these: A4XX_GRAS_CL_CLIP_CNTL_ZNEAR_CLIP_DISABLE | A4XX_GRAS_CL_CLIP_CNTL_ZFAR_CLIP_DISABLE
19:57imirkin_: and this one: A4XX_RB_DEPTH_CONTROL_Z_CLAMP_ENABLE
19:57robclark: 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:58imirkin_: and these ones: REG_A4XX_RB_VPORT_Z_CLAMP
22:11anholt_: daniels: looks like gitlab 12.6 broke marge: https://gitlab.com/gitlab-org/gitlab/issues/121620
22:11anholt_: (and I didn't look at gitlab version initially because i didn't see it get bumped in the helm repo)
22:14alyssa: daniels: sounds like someone's having fun :)
22:32anholt_: airlied: I didn't see a branch in your repo, I did go looking first
22:40airlied: anholt_: it's hiding in my old repo I think
22:40anholt_: Mmm. Aging in your code cellar.
22:43airlied: anholt_: yeah it's abanboned now for me
22:43airlied: since I got llvmpipe to use nir instead
22:44airlied: anholt_: https://paste.centos.org/view/b40d4f49 was the last diff I had
22:44airlied: not sure if any of it is useful at this point
22:44anholt_: airlied: I'll scavenge that and add a note about partial authorship if that sounds good
22:44airlied: sounds good to me
22:45airlied: anholt_: I feel hooking it into softpipe and running piglits in both ways might be a good way to get it further along
22:46anholt_: airlied: that's the plan!
22:46anholt_: well, seeing what happens to softpipe in CI if we flip the switch
22:46anholt_: should probably rig up softpipe piglit though.
22:55airlied: am I right in thinking the the spirv rem vs mod different is just which operand picks the sign
23:09airlied: j4ni: turns out I'd already pulled it locally, just hadn't pushed it out!
23:13airlied: uggh tip conflict in i915 :-(