00:10Lyude: is it me or has `make -j$(nproc) htmldocs` gotten a lot slower?
00:11imirkin: did nproc decrease? :)
00:11Lyude: hehe, nah, I've still got 12 threads :)
00:31jekstrand: Who builds the docs?
00:31jekstrand: Who reads the docs?
00:31jekstrand: Who writes docs?!?
00:31imirkin: Lyude, apparently
00:31imirkin: to all 3
00:32Lyude: docs are always good
00:32jekstrand: Unless they're wrong. :P
00:32imirkin: docs often start out right
00:32vsyrjala: i never read them. i sometimes tried to build them, but then sphinx broke and i stopped caring entirely again
00:33Lyude: sure, but then you fix the docs. I don't think it makes you more likely to hit a mistake with docs that have a few mistakes vs. not having any docs
00:33Lyude: i've definitely also fixed some pretty big bugs just by reading through hardware PRMs before :)
00:33imirkin: you could read the docs and thought they were right
00:34jekstrand: Lyude: It never causes me any problem with the mesa docs. I've not read them in years. :P
00:35Lyude: sure, but you've also worked on mesa for years!
00:36imirkin: diff people have diff inclinations
00:36imirkin: like it never even occurs to me to look for docs
00:37imirkin: whereas other people i know look for docs first thing they do
00:37Lyude: that as well, I think it's good to have info in multiple forms. plus, it gives you something to compare against if one or the other is wrong
00:37Lyude: unless they're both wrong, but, that would have been painful anyway
00:37imirkin: but differently wrong!
00:38vsyrjala: i usually read just hardware docs. and then i reverse engineer the hw anyway to figure out how it actually works
00:40imirkin: same on nvidia, except for the first step :)
01:44emersion: i usually read just uapi docs. except they don't exist so then i reverse engineer the kernel anyway to figure out how it actually works
08:21MrCooper: zmike: hence "adapt [...] to the piglit jobs" :) i.e. make a corresponding change for them
08:36danvet: airlied, for the kcmp patch, should I do a separate topic branch or so?
09:31hakzsam: dcbaker: when 21.0 is expected ? do we still have blockers?
09:33HdkR: ^ I'm also curious. I can only assume early next week atm
11:22pq: MrCooper, re: pbuffer swap behavior; maybe a tiled renderer could perhaps throw all GL commands away that do not have observable behavior within the chunk of commands up to eglSwapBuffers()?
11:23pq: or not sync the tiles back to the buffer
11:24pq: in case of EGL_BUFFER_DESTROYED swap behavior
11:27MrCooper: sounds like a nasty kind of going out of its way :)
11:27pq: but it's an optimization!
11:27MrCooper: more like a trap for innocuous SwapBuffers callers
11:28pq: tomato, tomato...
11:54tanty: tomeu: about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8939
11:55tanty: I'm wondering if I can get a r-b there. It fixes the open issue following the current implementation.
11:56tanty: Additionally, if wanted, I could open a new issue to replace with a python script (?)
11:56tzimmermann: danvet, hi. i'd need reviews of ast-cursor patches and the prepare_fb bikeshed. I'd cross review with someone, if that helps ;)
12:51zmike: MrCooper: right, I meant that more will CI pick it up if I move the piglit results to that directory?
13:37MrCooper: you need to adjust the script(s) making use of those files accordingly
13:37zmike: ok, will check that out
13:37zmike: thanks for the tips
13:38MrCooper: at least, there may be more
13:39MrCooper: the whole CI configuration is in tree, there's no external magic
13:41Peste_Bubonica: hi folks. A R9 M375 have vulkan support with radeonsi ?
13:42MrCooper: radeonsi is a Gallium driver, but all Radeon Vulkan drivers should support that
13:43Peste_Bubonica: MrCooper, its not clear to me, if this GPU is based on GCN, and if it has Vulkan support
13:44Peste_Bubonica: Sorry, its not a m375. Its a M385X
13:44MrCooper: if you meant the radeon kernel driver, no Vulkan support with that
13:45hch12907: considering it's GCN, it probably has Vulkan support
13:45MrCooper: according to https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units that's GCN 2nd gen (aka CIK), so Vulkan is supported with the amdgpu kernel driver
13:47Peste_Bubonica: MrCooper, nice.. thanks for yuouir help
13:47MrCooper: no worries
13:48kisak: Peste_Bubonica: for a bit of clarity, radeonsi is the OpenGL userspace for your video card. Vulkan support for your card would come from one of three userspace solutions, mesa/RADV, AMDVLK, or AMDGPU-PRO
13:49Peste_Bubonica: kisak, thanks for this details. I will try it with AMDGPU DRM + radv here.. :)
13:49kisak: on the kernel side, CIK cards use the radeon kernel module by default to talk to the hardware, none of the Vulkan userspace solutions work with that kernel module, but does with the amdgpu kernel module
13:50kisak: the amdgpu kernel module can work CIK cards, but not all edge cases are solved to get it switched on by default
13:53Peste_Bubonica: kisak, so I will need to use a kernel boot parameter to load amdgpu on kernel right?
13:54kisak: Peste_Bubonica: https://github.com/ValveSoftware/Proton/wiki/For-AMD-users-having-issues-with-non-OpenGL-games
13:55Peste_Bubonica: thank you for point this documentation. I will follow it (with a friend, this GPU is not mine)
13:55Peste_Bubonica: I use a navi gpu here, with full opengl/vulkan :)
13:56Peste_Bubonica: I'm trying to help him
16:19robert_mader: Hi there. I'm trying to debug why glGetString is not wired up when using or forcing GLES 2.0 under EGL. It works fine on GLX and EGL if GLES >= 3.0 is supported or requested. Currently trying to grep through the sources where _mesa_GetString is wired up but it's a bit confusing. Any idea hint where the issue could be?
16:20robert_mader: FTR. _mesa_GetString never gets called in the scenario. On GLX in work for for all GLES version.
16:24ajax: that's... wild.
16:24ajax: do you have a reproducer handy?
16:24robert_mader: unfortunately only firefox nightly
16:24ajax: (how do you mean, "forcing". afaik CreateContext will promote you to 3.x if the driver supports it.)
16:24robert_mader: on wayland
16:25robert_mader: I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/4283 about it
16:25ajax: (afk a second)
16:25robert_mader: with forcing I mean MESA_GLES_VERSION_OVERRIDE=2.0
16:25robert_mader: MESA_GLES_VERSION_OVERRIDE=3.0 makes things work as expected
16:25robert_mader: MESA_GLES_VERSION_OVERRIDE=1.0 is also broken
16:26robert_mader: I suppose it fell through the cracks because eglinfo doesn't use it
16:27robert_mader: firefox nightly reproduces it when enabling the EGL backend, but by now I'm pretty sure it's not their fault
16:45zmike: MrCooper: think I got it, doing a test run now
16:48imirkin: robert_mader: glGetString is used to get extensions, so CTS / dEQP couldn't work if it didn't work properly. there's some glGetStringi thing that you're supposed to use at some point, but i forget the details
16:49imirkin: ah, looks like that happened in GL core contexts
16:49robert_mader: yeah :/
16:49MrCooper: zmike: hold on a second
16:50imirkin: robert_mader: so it looks like glGetStringi is also in ES3.0 - can you confirm you're calling glGetString and not glGetStringi?
16:50robert_mader: What's striking to me is that `MESA_GL_VERSION_OVERRIDE` doesn't seem to have a similar effect - it's only `MESA_GLES_VERSION_OVERRIDE`
16:50MrCooper: zmike: never mind
16:50imirkin: MESA_GL_VERSION_OVERRIDE only affects desktop contexts
16:50imirkin: not gles
16:50robert_mader: can confirm, already added debug prints in mesa to make sure
16:50imirkin: and vice-versa
16:50zmike: MrCooper: haha ok
16:50zmike: how do I run the piglit jobs manually though? do I have to go through the full ci pipeline first?
16:51robert_mader: imirkin: actually we're using gl, not gles
16:51imirkin: robert_mader: how did you confirm?
16:51imirkin: robert_mader: basically my guess is that something about what you're saying isn't right
16:51robert_mader: imirkin: by adding debug prints in mesa for `_mesa_GetString` and `_mesa_GetStringi`
16:51imirkin: but you said it doesn't hit _mesa_GetString
16:52robert_mader: yes, but *only* if MESA_GLES_VERSION_OVERRIDE=2.0 is set
16:52imirkin: hm, maybe that override carries over into desktop contexts somehow? i forget precisely what it does
16:52robert_mader: with MESA_GLES_VERSION_OVERRIDE=3.0 it properly hits `_mesa_GetString`
16:52imirkin: that really should have 0 effect over GL contexts
16:53imirkin: yeah, there's no way what you're saying is 100% right
16:53imirkin: some part of your assumptions are false
16:54imirkin: robert_mader: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/version.c#n59
16:54imirkin: it only looks at GLES override when api is not a desktop GL api
16:54MrCooper: can't seem to reproduce with wflinfo, neither with GLVND nor without
16:55MrCooper: robert_mader: can you reproduce with wflinfo --platform=wayland --api=gl ?
16:56imirkin: perhaps your software picks a desktop context if ES 2.0 is reported, but keeps the ES contexzt when ES 3.0 is reported
16:56robert_mader: hm indeed I can't
16:59robert_mader: hm ok, let me check something
17:12robert_mader: imirkin: ok, thanks, turns out it *is* a context creation issue in FF... thanks for your time!
17:13imirkin: glad you worked it out. these issues can be maddening
17:15robert_mader: btw. didn't know about wflinfo, only knew glxinfo and eglinfo. That's very handy!
17:29MrCooper: yep :)
17:32zmike: MrCooper: looks like I got it this time 💪💪💪
17:32MrCooper: CI achievement unlocked!
17:34zmike: should make zink ci much faster
17:34zmike: thanks again!
17:44zmike: if any ci experts are in the mood to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9017
17:44robclark: vsyrjala, danvet: any thoughts on "[v2] drm/msm/disp/dpu1: turn off vblank irqs aggressively in dpu driver"... tl;dr: vblank irq comes before the actual vblank (and before the hw line counter increments)
17:45robclark: (I mean hw frame counter.. but same probably applies to hw line counter)
17:47danvet: robclark, if you know when it's fired I think you can patch it up
17:47danvet: the timestamp thing supports negative lines
17:47danvet: for this case where your irq/counter flips before start of frame
17:48danvet: so if you check the line counter in your hw frame counter
17:48danvet: and if it's in that line right before it flips where the irq might fire already, you add one
17:48robclark: hmm, I'm not entirely sure what the line count will be during this window..
17:48danvet: ofc needs a retry loop
17:49danvet: and same in the timestamp function, you don't just give a negative line counter value for the line where the hw counter flips, but one earlier (up to end of vblank time ofc, then positive numbers)
17:49danvet: I /think/ that should work
17:49danvet: but only if line counter and frame counter flip atomically, i.e. you can sample them accurately with a retry loop
17:50zmike: getting random ci job failures on 'depthcharge' tasks
17:50zmike: is this known?
17:50danvet: robclark, either way sounds like fun :-/
17:51danvet: drm_vblank.c doesn't care when your irq happens, as long as everything is consistent
17:52danvet: i.e. your irq firing time, the hw readout function, and the timestamp function needs to be negatively counting lines if your counter switches/irq fires before end of vblank
17:52robclark: I was hitting a WARN_ON_ONCE() that claimed otherwise ;-)
17:53danvet: well if your irq fires before the hw counter flips, then yes that's not consistent
17:53danvet: and you need to correct for that in your code
17:53robclark: right, that is the root problem
17:53danvet: e.g. appreciate the timestamp code we have from vsyrjala for i915
17:53danvet: drm_vblank.c does guarantee that your timestamp code is consistent wrt the hw vblank counter already
17:53danvet: since it retries
17:54danvet: but if your hw is too botched for that, you need to do more corrections in the callbacks
17:54danvet: I think vsyrjala ended u r/e-ing when things actually happen for the various outputs
17:55danvet: because ofc it's all different
17:56vsyrjala: yeah, cute little differences in exactly when counters increment and what offset they have
17:58vsyrjala: not to mention the cases where the counters don't work and instead you have to work backwards from timestamps
18:55mdnavare: hwentlan: kgz: vsyrjala: In case of VRR, the vblank events should indicate the correct timestamp when the vblank occured now even though its variable? So we shuld be capuring that an not the flip event completion
19:08ajax: is r600 actually missing something for gl 4.6 in hardware?
19:08dcbaker: only some of them have fp64 IIRC
19:09ajax: iirc evergreen and ni have it, r600 and r700 don't
19:09imirkin: ajax: some parts do, others don't
19:09dcbaker: I know evergreen does because i have one of those (somehwere)
19:09ajax: which, whatever, we have softfloat if we really care
19:09dcbaker: or mayb it was NI
19:09dcbaker: can't remember
19:10ajax: i was thinking more like xfb overflow query or atomics
19:10imirkin: in fact some r700 have fp64
19:10imirkin: (i think?)
19:10imirkin: the overflow query stuff should be supportable
19:10imirkin: it's part of DX11 i think
19:11imirkin: but only the super-high end EG/NI parts have fp64
19:11imirkin: only like cypress for EG and ... aruba? for NI
19:12imirkin: soft fp64 will likely run into technical issues
19:12imirkin: due to some very unfortunate internal driver details
19:13imirkin: namely the IR uses hardware registers, which only go up so high, so if you have too many temps, ka-boom
19:13imirkin: (and soft fp64 sure uses a lot of temps...)
19:14imirkin: (this is a wider problem with the r600 compiler backend, not fp64-specific, of course)
19:14ajax: wiki's Big List says r700 was dx10.1/gl3.3 but evergreen was dx11.3/gl4.5
19:15imirkin: that is correct.
19:15imirkin: gen11 also supports GL 4.x despite not having fp64
19:15ajax: features.txt says 4.5 for the whole of r600 and doesn't distinguish between r600/r700/eg/ni
19:15imirkin: (and nvidia's GT200 had fp64, despite being a DX10 / GL3 part)
19:16imirkin: pretty sure it's "where hw support exists"
19:16jekstrand: mslusarz: What happened with https://gitlab.freedesktop.org/freedesktop/mr-label-maker?
19:16jekstrand: mslusarz: Did we just never get a place to host it?
19:16jekstrand: daniels: Does such a place exist now, maybe?
19:17ajax: imirkin: that's not really the convention for the other drivers though. nouveau distinguishes nv50/nvc0, i965 mentions gens...
19:18ajax: someone should update that for iris
19:18imirkin: ajax: ok. well i'm like 99% sure what i'm saying is correct.
19:19ajax: imirkin: oh i'm not questioning you, i apologize if that's how i'm coming across
19:19imirkin: ajax: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r600/r600_pipe.c#n410
19:19imirkin: (nir is very much experimental there, so it's not a practical option at this point i believe)
19:20imirkin: (iirc hemlock is just 2x cypress, and cayman is 2x aruba. or the other way.)
19:21ajax: reason i ask is i have an imac with an rv710 that's beyond eol for macos updates but perfectly serviceable for a real operating system
19:21ajax: wondering what i'd be getting myself into
19:21imirkin: that said, xfb overflow query should not be difficult to support on eg/ni if it's not there already
19:21imirkin: well, rv710 is a dx10 part
19:21imirkin: i.e. GL 3.3
19:22imirkin: r600 works fine afaik
19:22imirkin: just don't go to shadertoy.com
19:22ajax: you understand why i might not consider that "works fine" ;)
19:23imirkin: well, more things work than don't work :p
19:23imirkin: and you can play many/most games (of that feature level)
19:23ajax: yeah, car's in great shape, just don't turn the volume down on the stereo while accelerating or the engine will explode
19:23imirkin: mmm ... dunno if explode is the right analogy
19:23imirkin: i think 'universe will end' is more like it
19:24kisak: well, if you want a hobby, I'm fairly sure Gerddie would welcome expanded testing for r600/nir
19:24imirkin: since i doubt recovery is very good for those parts
19:24imirkin: although something like shadertoy won't break - the shaders will just fail to compile
19:24imirkin: (i mean, it won't hang the board)
19:33jekstrand: ajax: I'm assuming said iMac is power-pc?
19:33jekstrand:is guessing at ages
19:33jekstrand: Ok, so no big-endian problems. THat's good. :)
19:34jekstrand: I guess power-pc would probably put it in D3D9-era
19:34ajax: no, sorry, big-endian you have to pay me to care about.
19:34jekstrand:can't be paid enough
19:36ajax: yeah. last ppc macs were late 2005 and came with at best a geforce 6600 or a radeon 9600
19:36jekstrand:can't wait for someone to get their hands on an Intel discrete card and shove it in their old Mac G5 tower.
19:38ajax: huh, no, that's just the towers. last g5 imac had a radeon x600
19:38ajax: still dx9
19:40jekstrand: Making Intel work on big-endian would be an interesting challenge. It's not switchable at all.
19:40imirkin: that's almost better
19:40jekstrand: So you'd have to throw byte-swapping code into the shaders everywhere.
19:40imirkin: trying to work out what the "switch" does on nvidia was responsible for many headaches
19:40imirkin: the main challenge is like index buffer data
19:41imirkin: which might be 8- 16- or 32-bit
19:41imirkin: and you don't know at data upload time
19:41jekstrand: I think if you made GenXML byteswap and wrote some NIR lowering to insert byte swaps, it'd take care of most of it.
19:41jekstrand: Index buffers are tricky. Those are actually interpreted by HW.
19:41jekstrand: Come to think of it, those might be about the only thing that are interpreted directly by HW.
19:41imirkin: well - textures as well
19:42jekstrand: So you'd have to run a quick VS or something to swap vertex buffer data.
19:42imirkin: thankfully those dx9 boards don't have a lot of texture formats supported
19:42jekstrand: Yeah, you'd have to be careful with texture formats.
19:42imirkin: so the problem never really came up
19:42jekstrand: And it'll depend on how stuff is specified.
19:42jekstrand: Oh, wait, no, you're screwed.
19:42jekstrand: R32F doesn't work.
19:43jekstrand: Or really any 16-bit-per-element array format
19:43jekstrand: Integer textures you might be able to fix in the shader with some hackery.
19:43jekstrand: Float is just toast.
19:43imirkin: jekstrand: take an advil now, for the headache you're about to get
19:43jekstrand: Actually... No, this is fixable.
19:43jekstrand: No, it's not.
19:43jekstrand: Well, maybe.
19:43imirkin: sounds like you're making the same progress i was.
19:44jekstrand: For buffer textures, only texelFetch is allowed, so we can swap in the shader.
19:44imirkin: "this works" "no it doesnt" "actually it does" "no, it's broken"
19:44jekstrand: For non-buffer textures, we can enforce TILED and do the byte-swap on uplaoad.
19:44imirkin: and then when you e.g. map a buffer
19:44jekstrand: Or maybe not
19:44jekstrand: Because I'm not sure texture views would work
19:44imirkin: coherent might be out ;)
19:44jekstrand: What if you view a R32F as R16G16F?
19:45imirkin: then you're gonna have a bad time
19:45imirkin: dx9 had none of that
19:45jekstrand: imirkin: Sure. But I don't work on ancient APIs. :P
19:45imirkin: but it was still very confusing
19:45imirkin: like should "GART" memory be BE or LE
19:45jekstrand: TBH, I know that anyone has ever run Vulkan on BE ever
19:45imirkin: and when you upload data via an auto-flip-pushbuf method, how does it end up exactly
19:46ajax: jekstrand: we could do it in ci with the s390x cross image!
19:46imirkin: making GART memory be LE is going to kill perf (effectively negating the usefulness of GART)
19:46ajax: piglit -> zink -> lavapipe -> qemu-user-s390x
19:46jekstrand: ajax: I'll let airlied do that with lavapipe first and see just how badly it goes. :)
19:47ajax: warning: may not complete before the universe achieves uniform entropy
19:53airlied: I should spin up an s390x image and see if lavapipe even loads
19:56imirkin: well, with a BE "gpu", should be simpler
19:56imirkin: it's the mixed endian stuff which is the true headache inducer
19:56jekstrand: The real headache is trying to decide whether bugs are in the driver or the CTS.
19:56imirkin: i always just assume CTS
19:57imirkin: until proven otherwise
19:57bnieuwenhuizen: why not both?
19:57jekstrand: Especially with dEQP-VK's stellar output
19:57jekstrand: Why not several bugs in each?
19:57imirkin: because my code doesn't appear double-spaced in a code editor
19:57jekstrand: imirkin: dEQP isn't double-spaced, it just has a 250-character line-length minimum. :)
19:57imirkin: when wrapped to 80 chars
19:58imirkin: i was like "wait, why is all this code double-spaced. who would do that"
19:58airlied: everyone that works on CTS has wide curved monitors
19:58imirkin: and then i realized it was just the "leading" space
19:58jekstrand: If you're reading dEQP code with anything less than a full-screen terminal at 2560x1440, you're asking for trouble. :P
19:58Sachiel: also set tabs to be 4 spaces
19:58jekstrand: Some days, that's not even enough pixels. :-/
19:58ajax: ... why is this still not a thing that our editors just correct for us
19:59jekstrand: ajax: If the editor did it all for us then we wouldn't be able to be pedantic about enforcing our terrible coding style.
19:59ajax: jekstrand: don't threaten me with a good time, sir
19:59airlied: looking at dEQP makes me realise I probably do need glasses
19:59danvet: jekstrand, the kernel is way ahead of you here with checkpatch.pl
20:10jekstrand: Woo! Debugging 1500-line OpenCL kernels....
20:12airlied: debugging seems to imply that it's possible to work out what's going on :-P
20:12jekstrand: airlied: Well, HW simulators help *a lot*
20:12jekstrand: But, also, I've got a BO mapped at a fixed address and I dump it on every vkWaitForFences
20:12jekstrand: Then I just stuff something like this in the kernel:
20:13jekstrand: // DEBUG
20:13jekstrand: const uint subgroupLocalID = get_sub_group_local_id();
20:13jekstrand: ((global float *)0x010000000640ull)[subgroupLocalID] = p.y;
20:13jekstrand: ((global uint *)0x010000000680ull)[subgroupLocalID] = i.y;
20:13airlied: just add printfs :-P
20:13jekstrand: airlied: That would require getting printf working. I refuse. :P
20:15jenatali: jekstrand: Isn't it already done?
20:16jenatali: Oh, I guess you're doing kernel dispatches inside your Vulkan driver, not using Clover, nevermind
20:16jekstrand: jenatali: Yeah
20:17jekstrand: I think I found the bug and it's in the CL code...
20:18jekstrand: Someone tried to average something and forgot to divide by 2.....
20:28jekstrand: or not?
20:28jekstrand:is confused by this code
20:39imirkin: "but it works on nvidia"
20:59Lyude: anyone know if thierry reading is on irc?
20:59imirkin: tagr_: --^
21:02Lyude: tagr_: tl;dr, I'm trying to store each drm_dp_aux's drm_device in the drm_dp_aux struct, but it would appear that tegra_dpaux_probe() is called without any knowledge of what drm_device the dp aux channel belongs to. Do you know any way we might be able to retrieve that info from that function?
21:05Lyude: I think we could do it by just leaving drm_dp_aux.drm_dev NULL until drm_dp_aux_attach() gets called, but if there's any way we could just fill it out from tegra_dpaux_probe() that'd be much nicer
22:40agd5f: even some r6xx and r7xx asics had fp64, but they were only DX10 parts
22:56dcbaker: karolherbst: Is this helpful for your rust project? https://github.com/mesonbuild/meson/pull/8335
23:22daniels: jekstrand: literally been working on that today but pre-empted IRL
23:36alyssa:looking into making scoped_barrier The One True Intrinsic and getting rid of the GLSL style ones
23:36alyssa: trying to gauge how much work fixing up everyone's driver will be
23:37jekstrand: Likely not much. Just update the switch statements.
23:37jekstrand: Do what ever looks right, hope for the best and ask the driver maintainer for fixup patches when you blow up CI. :)
23:40jenatali: Hooray, looks like we don't even support non-scoped_barrier
23:41alyssa: jenatali: How'd you manage that?
23:43jenatali: alyssa: We don't have GL compute yet, barriers were only added for CL
23:44jenatali: And scoped_barrier was added for DXIL IIRC, since it matches much better
23:44alyssa: Oh, got it.
23:44alyssa: Forgot about CLon12
23:46jekstrand: Yeah, we should get rid of non-scoped barriers and move on with life.
23:46jekstrand: I'd love to delete them from our back-end
23:46jekstrand: Not that they cause us much more work
23:50alyssa: intrinsic scoped_barrier () (4, 6, 3, 384) /* execution_scope=WORKGROUP */ /* memory_scope=DEVICE */ /* mem_semantics=ACQ|REL */ /* mem_modes=ssbo|shared */
23:50alyssa: from GL. I'm satisfied =)
23:51jekstrand: alyssa: You probably want execution_scope=NONE
23:51alyssa: jekstrand: that's control + shared + ssbo
23:51alyssa: or + buffer maybe
23:51jekstrand: Oh, ok.
23:52jekstrand: Also, you want available + visible in mem_semantics along with ACQ|REL
23:56jekstrand: I think I just reviewed basically this same code for zmike the other day. (-:
23:57jekstrand: Only I forgot to tell him to throw in AVAIL|VIS
23:58zmike: jekstrand: yea that's on my todo list since it's not technically required that I do it, just that either I or the vk driver does it
23:58jekstrand: zmike: ?
23:59zmike: the availability flags
23:59jekstrand: How is the vk driver supposed to add them?
23:59zmike: ah actually might be different on barriers
23:59zmike: for atomic ops in the vk mem model it's ambiguous such that either the driver or the app has to ensure the ops generate those flags