00:55 airlied: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7741 well caught, not sure how I screwed up that
01:02 mstoeckl: Hi all, I have a few questions about libgbm. Is it safe, in general, to call fork() after gbm_create_device()?
01:04 mstoeckl: My tests (with iris) seem to work fine, but I don't know if there are cases where this might not be supported...
01:04 HdkR: If there are any threads at that point then it is relying on a lot of things to go right :P
01:09 mstoeckl: iris_dri.so makes a few threads, so it looks like I'm lucky. Then again, I'm not doing anything between gbm_create_device and forking
01:12 HdkR: If you're doing a fork just to execve then you should be fine still. Anything else is lost mutex hell :)
01:13 mstoeckl: No exec -- I'm trying to avoid the 50msec runtime x 100 forks
01:14 HdkR: Sounds like you're asking for trouble
03:20 airlied: oh man opencl-c.h needs updating for cl3, the c11 atomic stuff is a horror show
03:33 Curi0: is r600 ever going to support ARB_gl_spirv or maybe even Vulkan ?
03:34 HdkR: doubt it'll gain Vulkan support
03:35 Curi0: hardware not capable ?
03:35 HdkR: Hardware would need a lot emulated, which makes it very difficult at least
03:35 Curi0: such as what would require emulation ?
03:39 HdkR: Scalar atomics come to mind, but there are plenty of things
03:39 HdkR: I just don't have a list :P
03:43 airlied: it doesn't have a proper virtual memory support either
03:44 airlied: cayman maybe, but you'd have to rewrite the kernel driver
03:44 airlied: ARB_gl_spirv might be possible once the NIR backend is done
03:52 Curi0: lucky mine is new enough for that
03:53 Curi0: i think older ones dont even support gl 4.2 without some emulation
03:53 airlied: lots of them don't support gl.40 without fp64
04:02 HdkR: Time for FP64 soft float
04:05 dcbaker[m]: That's already done :)
04:09 HdkR: Just needs wired up at this point I guess?
04:13 airlied: needs the nir backend
04:20 mareko: nir_to_tgsi?
04:21 airlied: I think the nir backend is probably closer to being less work at this stage
04:21 airlied: and also avoids having to use sb
04:39 mareko: draw doesn't use nir_to_tgsi, which causes some mess in st/mesa having to generate both NIR and TGSI
04:40 mareko: anholt: do you think we are ready to start using nir_to_tgsi in st/mesa?
04:41 airlied: mareko: draw should just do nir, why does it need tgsi?
04:41 mareko: airlied: without llvm
04:41 airlied: ah softpipe draw
04:41 mareko: or arm
04:42 airlied: hmm I thought anholt merged softpipe nir->tgsi
04:42 airlied: which should have covered draw as well
04:42 mareko: not st/mesa -> draw
04:45 airlied: ah that should probably be switched over
04:45 airlied: just to use nir between st/mesa and draw
04:48 airlied: it should be draw_has_llvm to check if draw supports nir
04:50 airlied: ah draw itself doesn't do nir->tgsi, it relies on softpipe
05:45 airlied: https://reviews.llvm.org/D92004 cl3 atomics ftl
05:45 airlied: jenatali_: no CL 3 without that monster :-P
05:54 airlied: oh have to fill in spirv opatomicflagtestandset and opatomicflagclear
05:54 airlied: do we have nir ops for those?
07:39 sravn: mripard, danvet, airlied: Do we want to limit what patches to apply for legacy/old drivers?
07:39 sravn: I did a small push-back on the via driver to avoid checkpatch style fixups
07:39 sravn: And now a new Frozen thing is suggested for the MAINTAINERS
08:08 arnd: mripard: I'm getting a build regression with the new drivers/soc/sunxi/sunxi_mbus.c driver: https://gitlab.com/Linaro/lkft/users/arnd.bergmann/playground/-/jobs/867464604
08:57 mripard: arnd: yeah, I should have build-tested with hch patch applied
08:57 mripard: do you want the fix as a separate patch or a new PR entirely?
09:23 danvet: sravn, I wonder whether some of those contributors might become more involved eventually
09:23 danvet: but it does seem a bit a dead end
09:23 danvet: otoh, those drivers also don't matter, next step for them is deletion
09:23 danvet: so *shrug*
09:24 danvet: sravn, if it annoys you, suggest some of the more involved cleanup tasks from our todo.rst
09:24 danvet: like one of the beginner ones
09:24 danvet: it's what I do sometimes when I see a name with checkpatch patches a bit too often
09:24 danvet: maybe they bite
09:26 arnd: mripard: a fix on top would be great, a single patch to soc@kernel.org would be the easiest, no need for a pull request
09:47 sravn: danvet: good idea with the todo.rst. We have had a lot of chrunch this cycle with warnings and so.
09:48 sravn: On the other hand, processing the trivial patches is simple with the setup with drm-misc-next
09:49 sravn: So I will try to be less grumpy and just process them and maybe suggest some challenges for people that shows up more than once
10:35 mripard: arnd: done
12:50 che: Heyyas
12:50 che: The microsoft-clc patch seems to cause build issues.
12:51 che: even though when set to auto it seems to get set to false, the condition is still enabled on my linux build and causes the build to fail.
12:51 che: i then tried with:
12:51 che: -Dmicrosoft-clc=false and i get:
12:52 che: meson.build:21:0: ERROR: Value "false" for combo option "Build support for the Microsoft CLC to DXIL compiler" is not one of the choices. Possible choices are: "enabled", "disabled", "auto".
12:52 che: setting: -Dmicrosoft-clc=disabled makes the build work as expected.
12:53 che: building on multiple fedora versions with meson: meson-0.55.3
13:08 che: thats the one crapping out: https://gitlab.freedesktop.org/mesa/mesa/-/commit/a5227465c13ae74651a932a82aeae65683f4a063
13:13 emersion: thanks pq for your feedback on the drm_mode_get_connector patch, these are good points
13:19 pq: emersion, I'm happy to be uneducated!
13:19 emersion: ahah
13:44 pq: I'm looking at https://gitlab.freedesktop.org/wayland/weston/-/blob/aee1f2b75e07b8be7d2e074eac94bbd36e00bfb9/libweston/renderer-gl/gl-shaders.c and wondering, there must be a better way to generate multiple variants of GLSL shaders from C. But what kind of approach would you recommend?
13:45 pq: It's basically a small combinatorial explosion of shaders, that in this approach are complied on-demnand in a display server. Which I suppose is not the best?
13:46 pq: each shader is practically trivial on its own, for now
13:48 pq: GLES 2.0+, FWIW
13:49 pq: maybe a single shader source but choose with #defines which parts to include? or compile just one mega-shader and use uniforms(?) to choose which paths to execute?
13:55 MrCooper: che: I'd try "meson <build directory> --wipe" if you haven't
13:57 MrCooper: pq: FWIW, the latter is often referred to as ubershader (Übershader for those who can handle real German spelling :)
14:03 emersion: isn't an uber-shader one you'd compile many variants of using #define?
14:04 emersion: i guess it's both
14:05 emersion: apparently a switch-on-uniform isn't too bad
14:10 che: MrCooper, i am doing rpmbuilds in a clean chroot each time
14:12 jenatali: airlied: O.O wow that's a big change. I'll see if I can get a chance to read through it
14:17 pq: thinking it again... the #define version of the shader collection would probably have more #-lines than actual code, so it'd wouldn't be any more readable, probably just worse
14:17 emersion: how so, pq?
14:17 pq: which makes me think that concatenating string constants in C is not actually that bad
14:18 emersion: you can do functions in glsl
14:18 emersion: #ifdef ASDF
14:18 emersion: vec3 get_pixel(vec pos) { … }
14:18 pq: emersion, see the tiny little pieces in that gitlab link above
14:20 emersion: pq: i don't think it would be that bad
14:22 pq: emersion, do you think the uniform definitions could all be unconditional as they get complied away if not used?
14:23 pq: maybe unused functions as well?
14:23 emersion: you could squeeze them right before the get_pixel definition
14:24 emersion: i'd assume unused functions will be optiized away, my understanding is that everything is inlined anyways…
14:25 emersion: maybe would be better to have an #ifdef switch for uniforms/globals/etc, and another one for code
14:25 daniels: yes, unused functions will be DCEd
14:25 daniels: as well as statically not-taken branches
14:25 emersion: ah, that one is interesting
14:25 emersion: so you don't actually need to #ifdef everything
14:26 daniels: I mean, Mesa's highly performant with AAA games, so I wouldn't worry about Weston's workload being too onerous
14:26 emersion: you can just define a const which changes at compile-time, and it'll be just as fast as #ifdefs
14:27 emersion: but i want weston to run on my mechanical pocket watch!
14:47 kisak: congrats to v3dv passing vulkan 1.0 conformance ( https://www.raspberrypi.org/blog/vulkan-update-were-conformant/ )
15:06 pq: but if dead GLSL code references an undefined variable, that's still a build failure always, right?
15:07 pq: which means I can't combine static conditions and #ifdefs that way
15:08 emersion: yeah, you need to define all uniforms unconditionally if you want to use dynamic branching
15:09 pq: that's a possibility too
15:09 pq: since AFAIU, unreferenced uniforms won't actually exist
15:17 pq: I do see one big advantage with piecing together the shader source from snippets: debugging. When you print the source text, you don't have to track if conditions are true or false since the conditions and dead code don't exist.
15:19 pq: OTOH... if you only have a single source text, you don't even need to print it, hmm.
18:11 daniels: if anyone sees CI breaking because of MinIO failures - I know about it, I'm working on it, and I'm watching Marge to see if any MRs need to be reassigned
19:01 airlied: jenatali, jenatali : spir-v op AtomicFlagTestAndSet AtomicFlagClear, ideas on the back of a postcard please :-)
19:02 jenatali: airlied: Sounds like new nir opcodes?
19:03 airlied: yeah does seem like the best option
21:53 lrusak: is there a way to get the edid from the drm connector through wayland?
21:56 emersion: lrusak: sorry, i missed your question earlier, can you repeat?
21:56 emersion: lrusak: why do you need the EDID?
21:56 emersion: and the answer is no, there is no way to get the EDID
21:56 emersion: that's intentional
21:57 lrusak: ok no worries :)
21:57 lrusak: I would like the edid to see if the tv supports a specific colorspace, and if not then to apply some transformations using shaders
21:59 lrusak: emersion, my question earlier was about egl images and uploading them. VAAPI surfaces for P010 can be split into two planes/layers. DRM_FORMAT_R16 and DRM_FORMAT_GR1616. If I upload these into a default framebuffer that uses a XRGB2101010 context, how can I be sure that the bit depth is preserved?
21:59 lrusak: or is it just "magic"?
22:00 emersion: re colorspace question: you'll probably be interested in https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/
22:01 emersion: tl;dr is that color management on wayland won't work like on X11, but clients will still be able to optimize for the sink if they want to
22:02 emersion: re P010: so you want to be sure you don't loose precision during the P010→XRGB2101010 conversion?
22:02 lrusak: right, I won't be able to change the connector colorspace anyway in DRM so there is no point to query for it
22:02 lrusak: emersion, yes
22:03 lrusak: I have the conversion, I just have no way to verify it really
22:03 lrusak: I don't know if some internal conversion is going on at all
22:03 emersion: how do you upload them? do you have a custom shader that glues the R16 and GR1616 planes back together?
22:03 emersion: or do you just blit the P010 texture?
22:04 emersion: (if you know about color management, your thoughts on the wayland stuff are welcome -- se article!)
22:04 emersion: see*
22:04 lrusak: upload using glEGLImageTargetTexture2DOES, then in shaders deal with the YUV->RGB conversion
22:05 emersion: ok, so you do the conversion manually. but then you are in control of the precision right?
22:05 lrusak: I've read through the article, (I think I retweeted it on the kodi twitter also) It has a nice kodi shout out :)
22:05 emersion: ahah, yes :)
22:05 lrusak: emersion, yes :)
22:07 emersion: hm, i'm not even sure how one would check that the shader doesn't loose precision, since there's some YUV→RGB conversion going on…
22:07 lrusak: yea :)
22:08 lrusak: here is our code for calculating the YUV->RGB matrix https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/VideoRenderers/VideoShaders/ConversionMatrix.cpp
22:08 lrusak: sorry it's a bit of a mess....
22:08 emersion: maybe there is some reference images somewhere, with both YUV and RGB values, that you could integrate into a test suite…
22:09 emersion: pq: do you have plans to test weston's YUV shaders?
22:09 lrusak: I guess we check here for the bit depth to adjust the matrix -> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/VideoRenderers/VideoShaders/ConversionMatrix.cpp#L473-L479
22:09 lrusak: emersion, where are you at with DMA hints for wayland?
22:10 kusma: dcbaker[m]: I can't disable the microsoft-clc feature any longer, it always acts as it's "auto" for me...
22:10 emersion: ah, that is some interesting code indeed… lots of magic numbers :)
22:11 emersion: (but that is to be expected for YUV conversion ofc)
22:12 emersion: lrusak: i've recently updated my MR, and daniels hopes that someone from collabora can help with this effort Real Soon, Anytime Now™ :P
22:12 emersion: it's complicated to push things forward when nobody's here to review your work
22:13 kusma: dcbaker[m]: TBH, it seems mostly like meson is unable to understand that it's really a feature. It keeps insisting that possible choices on the cmdline is "auto", "true" and "false", which are the old possible values...
22:13 lrusak: emersion, well if you need a test case.... https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/DVDVideoCodecDRMPRIME.cpp#L267
22:14 emersion: ahah, cool, maybe i'll give it a stab
22:14 lrusak: what I don't really understand is if it's possible to have an ARGB2101010 EGL context and only an 8bit surface format?
22:14 jenatali: kusma: Have you tried reconfiguring the build from scratch? Sounds like maybe there's something stale?
22:14 emersion: lrusak: i guess it all depends how you allocate your surface
22:15 kusma: jenatali: I have not, but if that's the case I really think someone *cough* should fix meson, because nuking the build-folder is really awful.
22:15 jenatali: kusma: While playing around with things previously, it seemed that changes to options only took effect after a successful regeneration
22:16 jenatali: E.g. change the meson.build, regenerate, then you can set the new option and regenerate again
22:16 kusma: jenatali: that sounds really broken
22:16 jenatali: kusma: I don't disagree, just suggesting potential workarounds :)
22:16 lrusak: emersion, well I don't know much about wayland, but I imagine you can query the available surface formats? when using DRM/KMS in kodi we query the supported output planes and create a gbm surface using the same format available. Then we create the EGL context with that format also... I'm not sure if this is the correct way to do it
22:17 emersion: yeah that sounds fine
22:17 kusma: jenatali: Sure, but I think we should revert this change if it breaks for people. It doesn't seem I'm the only one affected, if I understand the ticket from earlier today correctly.
22:18 emersion: lrusak: with wayland, the visuals are WL_SHM_FORMAT_*
22:18 kusma: I'm not at all happy about nuking my tree-state just because someone wants to use shiny features
22:18 emersion: so you can just pick the config with the WL_SHM_FORMAT_ARGB2101010 visual
22:19 emersion: and then your EGLSurfaces should have the right format
22:19 jenatali: kusma: Fair. Though it seems any change to an already-existing option would have painful consequences for anyone with a build tree
22:19 emersion: maybe there's a way to check that
22:19 lrusak: ok, well, currently on my wayland session I have this
22:19 lrusak: 2020-11-24 14:09:55.119 T:2663213 DEBUG <general>: OpenGL(ES): framebuffer size: red: 10 green: 10 blue: 10 alpha: 2
22:19 kusma: jenatali: yeah, at least as long as meson is broken like this.
22:19 lrusak: that's reading from glGetFramebufferAttachmentParameteriv
22:20 lrusak: in kodi that is
22:20 emersion: with framebuffer=0 and attachment= GL_DRAW_FRAMEBUFFER?
22:20 emersion: sounds like it works fine then?
22:21 lrusak: glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_BACK, GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE, &red);
22:21 emersion: hm, yeah, this sounds better indeed
22:22 lrusak: yes ok, so it seems that I'm also able to get 10bit output from my intel NUC when using an XRGB2101010 output plane
22:22 lrusak: [ 81.205960] i915 0000:00:02.0: [drm:intel_hdmi_compute_config] picking 12 bpc for HDMI output (pipe bpp: 36)
22:22 lrusak: so I guess we have all our ducks in a row so far?
22:23 lrusak: emersion, I'm also not sure if you still have access to our kodi slack to avoid flooding the channel here :)
22:24 emersion: ah, no, i think i lost access because it was tied to my @intel.com email
22:24 lrusak: emersion, want to PM me a new email and I can add you to our #video-external channel (if you want of course)
22:24 emersion: can do
22:26 emersion: i guess there's always #kodi-dev
22:33 kusma: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3877
22:36 robclark: kusma: don't we have windows builds in CI?
22:36 jenatali: robclark: They got turned off due to unreliability
22:36 jenatali: daniels is working on getting them reliable again
22:37 robclark: oh.. doh
22:37 kusma: robclark: yeah, what jenatali said. We had, but daniels is working on fixing it.
22:39 kusma: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7760
22:40 jenatali: I would've said for MSVC we could just replace get_once as declaring the var and initializing it in one line, since that's thread-safe on Windows by default, but that's apparently not legal in C :(
22:42 robclark: kusma: at a minimum, you don't need to revert the whole thing..
22:43 robclark: kusma: probably the best thing to do is: #if MSVC / #define get_once(__expr) __expr / #else ... #endif
22:44 robclark: at least for short term, that should be ok
22:46 jenatali: robclark: That'd always run it though, right?
22:47 robclark: yeah, not a great long term solution
22:48 robclark: seems like MSVC supports clang? Is that an option? If not, we can change get_once() to pass the type in (but typeof makes it much nicer looking)
22:48 kusma: robclark: there's no way of writing that in a protable way. Sorry, but this is your mess to clean up, not mine.
22:49 jenatali: Yeah, not in C
22:50 kusma: robclark: we have call_one which might be sorta what you want, but it's not going to fit in that interface.
22:50 robclark: well, I mean if clang and gcc both support a thing...
22:50 kusma: robclark: yeah. two compilers. Not the only two.
22:50 robclark: well, nearly the only two
22:51 robclark: call_once is kinda awkward, we could just use more do_once {} which doesn't depend on typeof
22:51 robclark: or just go back to passing the type as a param to the macro, which an earlier version of my series did
22:51 jenatali: robclark: I'd vote for just passing the type
22:52 swick: pq: IIRC in my weston branch the shader main calls other functions and only the function implementation depends on the shader variant
22:52 robclark: ok, I'll put together something
22:53 kusma: robclark: great :)
23:02 robclark: kusma: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7761
23:05 kusma: robclark: oh, yeah. ({ ... }) is also a GCC extension.
23:05 kusma: So sadly, still no dice.
23:06 kusma: I need to go to bed now, it's past midnight here... perhap jenatali can help you test?
23:06 jenatali: Sure, I can try it out if you have another change
23:07 dcbaker[m]: kusma: try `meson builddir --reconfigure` first
23:07 kusma: robclark: or actuall, just re-enable the CI step on your branch to test. See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7537 for how ;)
23:07 dcbaker[m]: kusma: There was a bug until 0.56 or 0.57 that caused meson to not handle changed option types correctly in a lot of cases (there still may be some that it doesn't)
23:07 dcbaker[m]:can't remember when it got fixed
23:09 kusma: dcbaker[m]: same issue, but If I change the feature on the same invocation as I use --reconfigure on, it seems to work. Thanks.
23:10 kusma: I'm also on meson 0.54.2, so perhaps updating would have helped.
23:11 dcbaker[m]: It's quite possible. I know I fixed a bug related to array and combo choices changing, and features are just special combos internally, so it may be fixed in a newer version
23:11 dcbaker[m]: I'm always dogfooding master, so it's easy to forget what version stuff landed in
23:12 jenatali: I ran into problems trying to set new options while regenerating while also running master (trying to implement a new command line option for MSVC), but I also probably had no idea what I was doing :)
23:13 dcbaker[m]: jenatali: the way meson does per-compiler options is entirely too clever. I'm not at all surprised that there's bugs there :/
23:14 robclark: hmm, even icc supports ({}) and typeof :-/
23:15 karolherbst: robclark: icc is also a proper C compiler :p
23:15 jenatali: What even is ({})?
23:16 robclark: a godsend for macros ;-)
23:17 karolherbst: {} as in scope, right?
23:17 dcbaker[m]: robclark: if you want to be super frustrated though, icl (the intel compiler on windows) almost certainly doesn't support it
23:17 robclark: karolherbst: yeah, ({}) lets you declare variables in an expression and fun things like that
23:18 karolherbst:thinks compiler not capable of at least C11 are just plain garbage
23:18 jenatali: That... sounds like a terrifying idea
23:18 karolherbst: jenatali: why?
23:18 karolherbst: proper scoping is always good
23:18 jenatali: karolherbst: Just use a function call
23:18 robclark:wonders if it is really too much of a hardship to just use clang for windows builds
23:18 jenatali: Except of course C doesn't support templates so you can't pass type information into the function call...
23:19 karolherbst: welll....
23:19 jenatali: robclark: Unfortunately yeah it kinda is
23:19 karolherbst: one can do type generic functions in C though
23:19 dcbaker[m]: jenatali: what happend to that msvc backend clang frontend thing?
23:19 jenatali: dcbaker[m]: Hm, I do remember seeing something about that but I'm not super familiar with it
23:20 robclark: so, I think we can do `do_once` in a dumber way on MSVC.. it won't have locking but it won't be worse than before
23:20 airlied: hmm I wonder should I just lower atomic flag at vtn or add nir instrs for it
23:20 airlied: I assume I can lower it to atomic store + atomic cas
23:20 dcbaker[m]: I haven't heard anything about it in a long time
23:21 kusma: robclark: if locking is required on other platforms it's almost certainly going to be required on windows.
23:21 robclark: hmm, or maybe not because you need the ({}) to have something static
23:22 jenatali: robclark: You could emit a function using __LINE__ or something to give it a unique name to introduce a new scope, then call that?
23:22 robclark: kusma: we've survived without it for this long.. not having the locking makes helgrind hella noisy, but other than that it is fine
23:23 karolherbst: .... it would be so nice to just have C11 ....
23:23 jenatali: karolherbst: For _Generic? Cause ({}) still isn't C11
23:24 dcbaker[m]: 2019 has _Generic
23:24 karolherbst: or atomics, or threading or... literally anything else :p
23:24 karolherbst: is more amused why "__typeof__(__expr)" doesn't work...
23:24 karolherbst: seriously
23:24 jenatali: It's nonstandard
23:25 karolherbst: which you could workaround with _Generic
23:28 airlied: jenatali, jekstrand, karolherbst : opinions on atomic_flag* always lower to a 32-bit store/cas at vtn or expend the effort to pipe them through all the global/shared/ssbo bits
23:28 karolherbst: airlied: well.. we have hw support for those flags
23:29 airlied: karolherbst: and it's there for all memoryt types?
23:30 karolherbst: afaik yes
23:30 karolherbst: but let me check
23:33 karolherbst: yeah. looks that way
23:33 airlied: okay guess I'll pipe it down then
23:35 karolherbst: but also not 100% sure
23:35 karolherbst: it's at least int he encoding
23:38 karolherbst: mhhh.. but I think it only works if I use a generic address or something.. it's a ll a bit strange
23:38 karolherbst: ATOMS doesn't have strong/weak modifiers, but ATOM and ATOMG do
23:40 karolherbst: airlied: btw, I wrote a lowering pass for 64 bit atomics to cas in some MR
23:40 karolherbst: just never finished as I wasn't able to get it to work on intel reliably
23:41 jenatali: airlied: I don't think we care, doesn't look like DXIL has any flag functions yet. I wouldn't complain if Mesa had lowering available until we get them though :P
23:41 airlied: I'll probably just add a lowering pass alright
23:41 airlied: once I get the pluminb in
23:41 karolherbst: how would you lower them anyway, inserting mem bars?
23:42 jenatali: CAS loop?
23:43 karolherbst: you sure that would be enough?
23:43 jenatali: No :) but it sounds like it should
23:44 karolherbst: yeah... well
23:44 karolherbst: I'd rather have hw supporting it directly :D
23:44 karolherbst: but yeah
23:44 karolherbst: I looked into trying to get 64 bit atomics to work at all for intel
23:44 karolherbst: it was a mess
23:44 karolherbst: I mean.. on shared mem
23:45 karolherbst: imagine, they don't have CAS
23:56 airlied: karolherbst: my assumpyion was to lower to a 32 bit cas for a store for clear
23:56 airlied: though ive given it 1 minute of thought
23:57 karolherbst: yeah.. I mean for 32 bit atomics that's all solveable
23:57 karolherbst: 64 bit is what is more annoying
23:57 karolherbst: but for atomic_flag directly it's probably fine
23:58 karolherbst: but I was also thinking about the full situation, memory order and all the other advanced things
23:59 airlied: not sure i have to consider that yet
23:59 karolherbst: not sure either
23:59 airlied: cl 3.0 has lots of steps
23:59 karolherbst: I just now, that you can't rely on CAS for everything
23:59 karolherbst: 32 bit probably yes though
23:59 airlied: flags are bool