00:21imirkin: enunes: fyi, clip planes were part of ES1.1 (but removed in ES2). if you have an ES1.1 driver, you could see how glClipPlane works there.
00:23imirkin: e.g. a2xx/a3xx had enough hw to implement 6 fixed clip planes, but not enough to support e.g. gl_ClipVertex from GL 2.0, or the clip distance stuff from GL 3.0
01:12airlied: is all that stands between lavapipe and vk 1.0 conformance
01:21imirkin: airlied: just stop advertising 4x msaa
01:46airlied: imirkin: spec requires it unfortuately
02:02ishitatsuyuki: I'm trying to investigate the color management support with overlays on AMD GPUs, but it seems that the whole display engine source is undocumented... anyone happens to know more about that?
02:02imirkin: there used to be docs online, but not sure if there are for the latest gens
02:03imirkin: i don't see anything too relevant though =/
02:04ishitatsuyuki: yeah, they talk nothing about DCN, which is added in Raven Ridge
02:21karolherbst: airlied: you know what? we can't pass the OCL CTS in full profile :/
02:21karolherbst: or maybe we can, but it is still not conformant once we enable images
02:23airlied: karolherbst: yeah I've been fixing things towards completing CL 3.0 CTS, but I have turned off images :-P
02:24karolherbst: the biggest issue is supporting 64 textures :/
02:24karolherbst: that will require some major rewrite...
02:24karolherbst: luckily I think I already did it...
02:25airlied: 64 images?
02:25karolherbst: no, textures
02:25airlied: is 64 the minimum?
02:25karolherbst: we need 16 samplers inside a kernel
02:26karolherbst: uhm.. wait
02:26karolherbst: 64 images.. right
02:26karolherbst: 128 textures :D
02:26karolherbst: soo read_images_args == textures is 128
02:26karolherbst: and write_image_args == images is 64
02:26karolherbst: embedded devices have to have 8 each
02:28karolherbst: there is some core support for some of it
02:28karolherbst: PIPE_MAX_SHADER_SAMPLER_VIEWS == 128
02:29karolherbst: so 128 textures are supported by core, but not all drivers
02:29karolherbst: PIPE_MAX_SHADER_IMAGES == 32
02:29karolherbst: so this is what we need to bump to 64
02:30karolherbst: okay, so we don't have enough images... not textures
02:30karolherbst: it's all very confusing :/
02:31airlied: ah yeah bumping that to 64 shouldn't be too much trouble
02:31airlied: just lead to some more memory conspumption in llvmpipe
02:39karolherbst: just some 64 instead of 32 bitfields
02:39karolherbst: ohh no, I don't have code for it I think :D
02:39karolherbst: I was trying bumping samplers to 128 once
02:42karolherbst: airlied: :p https://gist.github.com/karolherbst/d99b2fb10028a9d01e1f9a78ec0e75cb
02:42airlied: karolherbst: nice!
02:44karolherbst: airlied: spend some time digging through the spec to extract all the version, embedded vs full and custom type reqs: https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/rusticl/src/gallium/frontends/rusticl/core/device.rs
02:44karolherbst: should be more or less complete
03:38karolherbst: ahhh.. even rust regex is an external crate :/
03:55HdkR: While C++ regex is a nightmare? :P
03:55tehcloud: lol, Rust... they tried to recruit me but I knew something was wrong when I heard the chanting and saw all the white robes
03:58karolherbst: HdkR: you mispelled C++ is a nightmare
04:05dcbaker[m]: I know you all hate it, but c++11 is actually pretty nice. Much nicer than C
04:05imirkin:thinks c++ is great
04:06imirkin: which these days is pretty much a guarantee that everyone here will hate it
04:07jekstrand: imirkin: lol
04:07jekstrand: I like C++ in theory
04:07dcbaker[m]: C++98 is not that great, but c++11 (or even better 14 or 17) really are nice. C++ has a lot of baggage, but so will rust when it's 50 years old
04:07jekstrand: I just don't like 95% of the C++ code I've ever read.
04:08imirkin: yeah, i mean i'm not advising for the Turbo C++ pre-standard variant here...
04:08airlied: yeah if someone wrote a mesa c++ style guide maybe it would be more consumable
04:08airlied: but the range of acceptable c++ usage seems to be a sliding window per developer with not much overlap :-P
04:09airlied: and people slip back into older c++ idioms the longer they've used it for
04:09airlied: or which stack overflow article they learned it from
04:10imirkin: yeah, definitely the gcc-2.95-safe c++ is strong within me. haven't had much excuse to learn the new stuff too much
04:10imirkin: the c++11 stuff seems really nice
04:10jekstrand: Yeah, unique_ptr itself is a pretty good reason.
04:11jekstrand: Builtin threading and atomics is nice too
04:12dcbaker[m]: Having generics and type safe containers in the stdlib is also fantastic
04:12jekstrand: Some of them aren't as nice as you'd want them to be
04:12jekstrand:loves intrusive linked lists
04:14HdkR: dcbaker[m]: https://github.com/FEX-Emu/FEX/blob/master/CMakeLists.txt#L35 I have C++20 enabled by default. Can't complain :P
04:15jekstrand: But std::vector would be soooo nice....
04:17dcbaker[m]: I have a piglit implementation in c++14. Other than interfacing with expat and zlib it's been really nice
04:18jekstrand: dcbaker[m]: What's the status of that? Are we using it in CI? Is it in piglit yet?
04:27dcbaker[m]: Neither. It works well enough for a lot of OpenGL cases. Can do vkrunner as well. I've got some wip code for junit output and for multi shader tests. Still haven't started on OpenCL
04:28dcbaker[m]: It's much faster than piglit on my 8 thread icelake though, and uses a lot less memory
09:19bbrezillon: danvet: did I get the dmafence annotation right in https://patchwork.freedesktop.org/patch/399259/ ?
09:23danvet: bbrezillon, lgtm
09:27bbrezillon: danvet: ok, thx
09:56danvet: mripard, is your latest series culmulative?
09:57danvet: or do I now have to like review 2 or something like that?
10:30mripard: danvet: which one, the one about drm_atomic_helper_commit?
11:47tzimmermann: danvet, sravn, do you remember why shmem helpers are incompatible with fbdev's deferred i/o ?
13:04jophish: Where might I find some high-level documentation on RADV?
13:33neobrain[m]: jophish: what kind of information are you looking for?
13:34neobrain[m]: We don't really have much beyond the amd docs themselves, other than documenting the env vars radv uses I guess
13:40sravn: tzimmermann: I have no idea about deferred I/O - sorry
13:40tzimmermann: ok, np
14:11jophish: neobrain[m]: I'm afraid I don't really know what I want to know yet!
14:11jophish: I'm just generally interested, and wanted to understand a little better how things work
14:12neobrain[m]: fair enough :)
14:14neobrain[m]: what's nice about Vulkan drivers is that the API itself is slim enough that there isn't much of a driver architecture to comprehend anymore, so a good understanding of Vulkan will get you a long way ahead already
14:14jophish: yeah, that's actually the observation I would make after perusing the source a little but
14:14neobrain[m]: (though that said, our shader compiler ACO is a different beast :p)
14:15jophish: I spent a bit of time today exploring the nvidia driver with radare2, I have to say that radv is much more approachable!
14:17neobrain[m]: haha well, it does help being able to write the driver based on actual docs instead of spending all day reversing the hardware first
14:18dschuermann: jophish: in src/amd/vulkan/ you find the RADV bits, while the shader compiler can be found in (frontend) src/compiler/nir/ and (backend) src/amd/compiler/
14:25danvet: tzimmermann, sravn both use the same fields in struct page
14:25danvet: to make them compatible we need some way to intercept the page fault stuff
14:25danvet: and we'd need to keep track of dirty pages in some separate bitfield array
14:25danvet: I think, I haven't actually tried to implement that
14:26danvet: intercept page fault stuff = wrap vma->vm_ops somehow
14:26danvet: without upsetting shmem vma->vm_ops
14:27tzimmermann: danvet, thanks for answering. i tried to run shmem with fbdev without shadow fb and got a console on the display. so i wonderde why it's considered incompatible
14:35jophish: thanks, dschuermann. Looking forward to reading the shader compiler :)
14:36danvet: tzimmermann, only starts going boom when you do userspace mmap
14:36danvet: so maybe fire up that igt and watch
14:37dschuermann: jophish: also have a look at src/amd/compiler/README.md . if questions remain, feel free to ask :)
14:59jophish: dschuermann: thanks! will do
15:19danvet: airlied, CI would be sooooooooooo nice :-/
15:30karolherbst: dcbaker[m]: I guess that proc-macro crates are not wired up inside meson as well?
15:30mimi89999: Are there any OpenCL tests in Mesa?
15:31karolherbst: why should the tests be in mesa?
15:31karolherbst: there are some in piglit, but then there is also the OpenCL CTS
15:32mimi89999: To test if there are no regressions for example
15:33karolherbst: sure, but we don't put API tests in mesa, there are all in their own projects
15:33mimi89999: Ah. OK.
17:17ajax: anyone want to trade reviews? !7369
17:21tango_: «I'll review yours if you review mine»
17:22jekstrand: ajax: Hah! Nice try. :P
17:22jekstrand: ajax: I don't have any MRs that I want reviewed that badly. :)
17:23tango_: mimi89999: pocl gets its opencl tests from a plethora of sources, you could follow those
17:25tango_: mimi89999: -- Available testsuites: AMD;AMDSDK2.9;AMDSDK3.0;ASL;arrayfire;clBLAS;CLBlast;clFFT;conformance;CloverLeaf;Halide;IntelSVM;opencl-book-samples;OpenCV;Parboil;piglit;PyOpenCL;Rodinia;shoc;VexCL;ViennaCL;Glow
17:25tango_: this is what pocl uses
17:54jenatali: curro, karolherbst: Clover's LLVM deps includes all-targets, do you know if that's actually needed?
17:54karolherbst: jenatali: probably not
17:55jenatali: I apparently have to rebuild LLVM to add RTTI :(
17:55karolherbst: jenatali: but where is that specified?
17:55jenatali: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/meson.build#L1469
17:57karolherbst: seems like it was always like this
17:57karolherbst: but yeah.. we really just need the CPU and AMD target
17:57karolherbst: CPU being.. native arch thingy
17:57karolherbst: maybe check what llvmpipe depends on
17:58karolherbst: but yeah.. it kind of depends on what drivers to pull in
17:58jenatali: I don't think Clover needs any specific target
17:58jenatali: Yeah the driver can pull in what they want, but Clover itself just needs the IR libs
17:58karolherbst: ohh, wait
17:58karolherbst: you are right
17:58karolherbst: we just need AMD
17:58jenatali: No, AMD needs AMD ;)
17:58karolherbst: we do some LLVM stuff inside clover
17:58karolherbst: and some of it is AMD specific
17:58karolherbst: so I wouldn't be surprised if we actually need it
17:58jenatali: Only if the AMD driver is being built though, right?
17:59karolherbst: no, I think it's always built atm
17:59jenatali: I'm trying to actually build Clover on Windows so I can address curro's comments about sharing more code, we'll see how far I get
18:00karolherbst: but maybe it indeed works without a target...
18:00karolherbst: but we have this "t->createTargetMachine(target.triple, target.cpu,..." code
18:00karolherbst: in clover
18:01jenatali: Yeah the target should be spir though
18:01karolherbst: not for AMD
18:01jenatali: Sure, but that'd be a runtime error if you tried running with AMD, not a linker error
18:01Venemo: why does this matter? AFAIK radeonsi just gets a NIR shader from you, doesn't it?
18:01Venemo: or am I misunderstanding something here?
18:01karolherbst: we still support the LLVM path
18:02karolherbst: jenatali: ahh, yeah
18:02jenatali: Right, no NIR involved there
18:02jenatali: karolherbst: For the record, here's what we were able to get by with for our CLC frontend: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7565/diffs?commit_id=581a3c5c4b134dbcfdae411c5b84d9a826f4acd3#0cc1139e3347f573ae1feee5b73dbc8a8a21fcfa_1469_1490
18:02gitbot: Mesa issue (Merge request) 7565 in mesa "Add Microsoft CLC CLOn12 compiler stack" [Nir, Opencl, Spir-V, D3D12, Panfrost, Opened]
18:02karolherbst: I think airlied made the nir path work as well.. but no idea what the state is
18:02karolherbst: jenatali: it doesn't matter anyway.. just use libLLVM :p
18:03karolherbst: I just think people statically linking are the only one bothering
18:03karolherbst: and on linux you get your big fat libLLVM.so
18:03karolherbst: which contains everything anyway
18:03jenatali: Windows doesn't build a shared LLVM
18:03jenatali: We have to link static
18:04karolherbst: yeah.. I know. I just don't think our list is cleaned up and things just got added once we ran into a problem
18:04jenatali: Yep, I'll see if I can help you prune it :P
18:11mimi89999: jenatali: Still on that Proronix article?
18:11Venemo: karolherbst: what is the LLVM path?
18:11jenatali: mimi89999: Which one?
18:11mimi89999: About sharing code
18:11dcbaker[m]: karolherbst: In my branch? Haven't gotten there yet
18:12jenatali: I don't remember a Phoronix article about sharing code...
18:13dcbaker[m]: mimi89999: The Intel one? If so you're confusing jenatali with someone else
18:18karolherbst: Venemo: clover handing over the LLVM directly to r600 and radeonsi
18:18karolherbst: and it's an llvm with the AMD target
18:18Venemo: oh, I see
18:19Venemo: could that work with NIR too?
18:20airlied: karolherbst: not even sure clover is involved
18:21airlied: ph I suppose we do pull IR out at some point
18:22karolherbst: clover/llvm/codegen/ and stuff
18:22karolherbst: there is a bunch of things
18:22karolherbst: and all very AMD specific
18:23airlied: well the idea is to just generate machine code from clang frontend, it's technically not amd specific, just no one else has a backend in llvm that wants that :-P
18:24karolherbst: ohh, it is amd specific as the AMD target has some ABI which clover fullfills
18:25jenatali: airlied: Like printf :P
18:25karolherbst: it's just not visible if you look at the code
18:25karolherbst: yeah, and kernel args for images and other things
18:25Venemo: what happens with drivers that don't use LLVM?
18:25karolherbst: they don't go that path
18:25jenatali: Venemo: They get NIR
18:25karolherbst: we have some code generating SPIR targeting LLVM
18:25karolherbst: and this gets translated to spir-v
18:25jenatali: Right, Clang -> SPIR -> SPIR-V -> NIR
18:26Venemo: by Clang, do you mean LLVM IR?
18:26jenatali: SPIR is an LLVM IR
18:26karolherbst: clang essentially parses the CLC code and gives us llvm
18:27Venemo: is it the same LLVM IR that for example RADV's LLVM backend creates?
18:27karolherbst: LLVM IR always has a target
18:27jenatali: Venemo: For Clover we'd use the spir target triple for Clang
18:27karolherbst: and it depends what instructions you emit
18:27karolherbst: they are just incompatible
18:28Venemo: so, theoretically, if we were interested in the future in using ACO there, it could get NIR, right?
18:29Venemo: thanks, that's what I was curious about
18:29karolherbst: and the amount of additional nir instructions is quite low
18:29Venemo: I never really paid attention to clover to be honest, so am a bit out of speed here.
18:30Venemo: for example I don't even fully see why you need llvm there
18:30karolherbst: because we are too lazy to write a C/C++ parser
18:30jenatali: I guess someone could write an OpenCL C -> NIR compiler...
18:30Venemo: oh, I see
18:31jenatali: Clang just already happens to have one
18:31karolherbst: yeah.. but preprocessor support?
18:31karolherbst: all that include magic?
18:31karolherbst: -D support
18:31karolherbst: it's quite a lot
18:31karolherbst: glsl is childs play in comparison
18:31Venemo: sorry, I wasn't aware that OpenCL was basically C.
18:31jenatali: Yep. A few restrictions, and a bunch of extensions
18:31Venemo: yeah, I wouldn't expect you to write a C compiler :)
18:32dschuermann: karolherbst: wait, you go OpenCL C -> LLVM -> SPIR-V -> NIR?
18:32karolherbst: well, OpenCL also allows you to hand in SPIR-V directly
18:32jenatali: Or SPIR
18:33karolherbst: yeah, but SPIR is highly optional
18:33karolherbst: where SPIR-V is kind of required
18:33jenatali: True :)
18:33karolherbst: anyway, going through SPIR-V is the natural choice
18:33dschuermann: well, ok that is also what the khronos tooling does
18:33jenatali: karolherbst: Do you know if SPIR-V is required for 3.0?
18:33karolherbst: no idea
18:33karolherbst: but I assume it is
18:33dschuermann: it's not required by that garbage release
18:33jenatali: airlied: ^^?
18:34karolherbst: dschuermann: "garbage release"?
18:34karolherbst: and here we thought CL 3.0 was the first _sane_ release since CL 1.2
18:34karolherbst: jenatali: ahh "Creating programs from an intermediate language (such as SPIR-V) is optional for devices supporting OpenCL 3.0."
18:34jenatali: Huh, interesting
18:34karolherbst: oh well
18:35dschuermann: the vendor can give you a list of supported IRs, be it SPIR, SPIR-V or whatever (PTX anyone?)
18:35karolherbst: yeah.. it surprises me as well
18:35dschuermann: how is that a good spec by any means?
18:35karolherbst: dschuermann: that was true since CL 1.0
18:35jenatali: I thought for sure they would've kept that as required
18:35jenatali: karolherbst: IRs was 2.0 I believe, with SPIR-V becoming a required IR in 2.1 I think
18:36karolherbst: could abuse it for PTX if you wanted to
18:36jenatali: Yeah but SPIR was the only IR that could go down that path as an extension, IRs wasn't really spec'd until 2.0
18:36dschuermann: don't have to: In addition, platform vendors may support their own IL if this is appropriate.
19:04karolherbst: dschuermann: point was, this was possible since CL 1.0 anyway
19:04karolherbst: jenatali: I guess SPIR-V is optional for all those FPGA vendors who don't bother with vulkan anyway
19:05dschuermann: yes, but now spir-v is optional again... so, for portability you can only rely on OpenCL C
19:05jenatali: I guess
19:05karolherbst: ahh, yeah
19:05karolherbst: maybe we should push for 3.1 making it required again :D
19:05jenatali: dschuermann: For portability, it's always only been OpenCL C, since there's plenty of implementations that stopped at 1.2
19:06karolherbst: nvidia *cough*
19:06airlied: just need to write a spir-v ptx and do CLonCUDA
19:06imirkin: llvm has a ptx output i think
19:07karolherbst: airlied: you mean spir-v -> llvm -> ptx?
19:07karolherbst: well, llvm do has PTX output
19:07airlied: I suppose you could involve llvm in there but I'm going to guess it's non-trivial
19:07jenatali: airlied: I'm pretty sure NVIDIA's proprietary CL driver (at least on Windows) *is* CL on CUDA
19:07dschuermann: there is already sycl on cuda iirc
19:07karolherbst: jenatali: yep
19:07airlied: having ptx output and getting the LLVM IR that backend expects might be different things
19:08imirkin: jenatali: there's a cuda-ish core, you can see its ugly head in GL too
19:08imirkin: like when you trigger some error, it'll give you some nonsensical error which makes it clear there are 10 layers of conversion going on
19:08karolherbst: especially if you do compute shaders
19:30mimi89999: OpenCL on CUDA isn't already implemented by POCL?
19:31karolherbst: I think it actually is
19:31imirkin: but NIH...
19:33airlied: mimi89999: indeed they've done some stuff, must see if it ever landed in their master branch
19:34airlied: yup it's in there
19:35airlied: I think we talked back in time about using pocl as the frontend instead of clover
19:36airlied: I wonder if they do barriers yet or just ignore them
19:37karolherbst: airlied: biggest question is on how to integrate it into mesa though
19:37airlied: yeah it has an accel plugins backend
19:38airlied: not sure how to integrate that
19:38karolherbst: yeah.. that's my biggest worry as well
19:38karolherbst: do we really want to expose galliums API to the outside?
19:38karolherbst: I guess the answer is no
19:38airlied: no we would need a wrapper around it
19:38airlied: which means inventing another API
19:38airlied: pocl might be good for CL on lvl0 type thing
19:39imirkin: we could call it the Gallium Library
19:39imirkin: aka GL
19:39karolherbst: airlied: might be
19:40dcbaker[m]: imirkin: let's pick a different metal. Mercurial has a nice ring to it :D
19:40dcbaker[m]: that way we wont confuse anyone
19:40imirkin: good idea
19:40imirkin: (sadly the metal itself, in english, is 'mercury')
19:42tanty: dcbaker[m] : could I get too quick reviews at
19:42gitbot: Mesa issue (Merge request) 413 in piglit "templates: fix summary generation when not all image keys exist" [Infrastructure, Regression, Opened]
19:42gitbot: Mesa issue (Merge request) 414 in piglit "cmake: move the INCLUDE commands after the project command" [Infrastructure, Opened]
19:43imirkin: dcbaker[m]: but dma-buf could have been called bitbucket ... missed opportunity
19:43dcbaker[m]: imirkin: I came up with something even better "The Gallium Serialized Interchange Format" TGSI for short
19:44imirkin: the T = Tungsten btw
19:44imirkin: (which is actually W iirc)
19:45dcbaker[m]: Yeah, from Tungsten Graphics
19:45imirkin: yep. just in case you weren't aware. you clearly were though :)
19:46vsyrjala: clearly gallium should have been called wolfram graphics library (wgl)
19:47karolherbst: or cupper graphics library (cgl)
19:48dcbaker[m]: "Graphics Interface Translation HUB"
19:49mimi89999: I tried to run the CL test in Piglit with `./piglit run cl results/cl`, but got `FileNotFoundError: [Errno 2] No such file or directory: '/home/michel/git/piglit/generated_tests/cl/builtin/int'`.
19:49dcbaker[m]: you need to build the opencl tests
19:49dcbaker[m]: they're not on by default
19:49dcbaker[m]: -DPIGLIT_BUILD_OPENCL=true IIRC
19:50danvet: robclark, should I apply the msm patches in Lee Jones series to drm-misc-next or will you apply?
19:50danvet: [PATCH v2 00/42] Rid W=1 warnings from GPU (non-Radeon)
19:50danvet: patches 15-20
19:51danvet: agd5f_, I'll leave patch 1 in that series to you since amd
19:51danvet: I think the others I'll just all apply and done
19:51danvet: sravn, ^^ or did you want to do that?
19:51robclark: danvet: iirc they were all standalone.. so I can pick them up
19:52dcbaker[m]: tanty: done
19:52mimi89999: `Manually-specified variables were not used by the project:
19:53jenatali: karolherbst: Any idea why Clover has a dependency on libelf?
19:53tanty: dcbaker[m]: thanks a lot!
19:54danvet: robclark, yeah they're all standalone
19:54karolherbst: jenatali: src/gallium/frontends/clover/llvm/codegen/native.cpp
19:54danvet: it's more that there's a ton
19:54danvet: and "maybe merging right before merge window pull" doesn't scale for this I think :-)
19:54mimi89999: Maybe `cmake . -D PIGLIT_BUILD_CL_TESTS=on`
19:54danvet: agd5f_ does a great job applying, but I think that's about it
19:55dcbaker[m]: mimi89999: I also just end up using ccmake because figuring out what arguments a cmake project takes is otherwise impossible :)
20:01sravn: danvet: my only concern is that we get them merged so we avoid a lot of lingering patches. So please go ahead
20:03sravn: I did a quick W=1 run if drivers/gpu/ and there was a tons of warnings, but I think Lee's series will fix the most. The ones remaining are drivers that requires specific archs or configs
20:10jenatali: curro: FYI, Clover won't build with MSVC very easily... Fun fact, Mesa's c99_compat.h breaks LLVM headers by #defining restrict to __restrict, meaning that __declspec(restrict) becomes invalid
20:17agd5f_: danvet, yeah, I'll take care of all the AMD ones
21:30airlied: jenatali: I hadn't considered changing the spirv parsing for printf, I suppose I can extract the strings easier there
21:30jenatali: airlied: That'd work, or you could during during the lowering from printf intrinsic -> nir sequence of variable stores
21:33jekstrand: Are there Fedora packages for clang 10? I see libclang-10 but not the executable
21:34airlied: jekstrand: just clang?
21:34airlied: we don't tend to package older compiler frontend though
21:35jekstrand:links clang-11 to clang-10 and hopes no one notices...
21:36airlied: jenatali: in vtn_opencl.c I assume you mena
21:36jenatali: jekstrand: I meant in nir_lower_printf
21:36airlied: jenatali: doing it in the nir lowering pass seems non-trivial
21:37jenatali: Ok, that works
21:37airlied: jenatali: that hits the problem of needing two passes
21:37jenatali: airlied: I'm not sure I follow why that's the case
21:37airlied: you don't know what the printf vars are until you hit the printf
21:37airlied: so once you do then you have to find every store to that var
21:37airlied: it's not SSA
21:38jenatali: I'm still not following... at the beginning of the lowering pass there's no var
21:38jenatali: Ohhhh wait yeah, the args are a local var, right
21:39jenatali: Sorry I was thinking you meant the buffer where the actual printf data gets stored
21:39jenatali: airlied: Yeah seems reasonable to pull it all the way to vtn_opencl.c then
21:40airlied: of course maybe we can just work out how to map things using the address but I'm not confident
21:42jenatali: Yeah, I didn't expect that to work for everyone
21:44airlied: yeah I can't see with clover how I can make it work for gpus
21:45mimi89999: `[710/710] skip: 3, pass: 685, fail: 19, crash: 3` seems quite bad.
21:46airlied: mimi89999: what is that against?
21:46gitbot: Mesa issue 3768 in mesa "OpenCL might produce incorrect output" [Opened]
21:46mimi89999: My issue with te RX 580
21:46karolherbst: mimi89999: seems good enough
21:47karolherbst: anyway, runing against piglit will probably not fix your problems
21:50mimi89999: Is it a lost case?
21:51karolherbst: no, just needs proper debugging
22:00mimi89999: Can I help with that? I can test anything on that device.
22:06airlied: writing a piglit test that reproduces the failure might help, if one of the current failing ones isn't obviously it
22:45mimi89999: airlied: `cl-custom-r600-create-release-buffer-bug` seems like a good candidate.
23:03karolherbst: curro: I can't remember but was there something I wanted to change to the CL 1.2 image MR?
23:11curro: karolherbst: IIRC there were some hacks to convert between the CL and gallium array coordinate ordering you were trying to implement a better fix for. or did you fix that already?
23:11karolherbst: ohhh, right
23:12karolherbst: totally forgot about it :D
23:12karolherbst: all I could came up was, making the subclassing suck less or inline samplers super hackish implemented
23:12karolherbst: btw, did you had a chance to look at the inline sampler stuff?
23:14curro: karolherbst: why does the subclassing affect how we process coordinates in transfer.cpp?
23:14curro: karolherbst: i don't think so, do you have a link to it?
23:15karolherbst: curro: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7241/diffs?commit_id=d4b50e02db544100512736777203ce62f9873a9c
23:15gitbot: Mesa issue (Merge request) 7241 in mesa "Draft: OpenCL 1.2 image support" [Opencl, Clover, Opened]
23:15karolherbst: curro: ohh, no, this was just a general thing to improve maybe
23:16karolherbst: like having an templated image_base instead of the variants and just use that
23:16karolherbst: and it would implement the mem type and dimensions stuff directly
23:16karolherbst: which is more or less the only hard reason we have subclasses
23:17karolherbst: anyway.. just an idea
23:17karolherbst: the coordination fixup is critical though ;)
23:18curro: karolherbst: lemme look through your patches
23:25mimi89999: I can't find the commit fixing the r600 create release buffer bug that the test is for.