04:27tarceri: cwabbott: was this intended to fallthrough https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/compiler/nir/nir_opt_access.c#L122 ?
04:28mattst88: oooh, definitely doesn't look like it
04:32tarceri: yeah was just wondering if there was something to it that I wasn't seeing
06:31airlied: tzimmermann: can you take a look at the double free patch from jia yang on the list, probably in your wheel house
06:33tzimmermann: airlied, sure
06:40itoral: looks like the windows 2019 gitlab runner is not working: https://gitlab.freedesktop.org/itoral/mesa/-/jobs/3373738
06:40itoral: who should I ping for that?
06:40airlied: itoral: yeah I've kicked a few jobs on it today
06:40airlied: daniels: ^
06:40itoral: airlied: ok, thanks
06:41airlied: if it's a problem, probably should temp disable it for a while
07:21MrCooper: airlied: "I don't think having working BE GPU support is really tractable, it's an endless game of whack a mole" neatly sums up ~15 years of my life :)
07:21daniels: airlied: I've already kicked alatiera about it, he's trying to figure out what's going on, since it looks like either a network or HTTP problem; if it continues to be a problem for people then please feel free to push a disable, I'm not able to keep an eye on it atm
07:23MrCooper: anholt_: huh, so what cache makes such a big difference for arm_build, ccache?
07:42danvet: airlied, agd5f_ I thought sfr has the same check as dim for missing sob, and drm-amd is in linux-next now?
07:52daniels: MrCooper: it's building two kernel trees, so that would probably make a pretty big difference - presumably doing so at -j4 since the FDO_CI_CONCURRENT stuff didn't land either
07:52daniels: (those really need to be untangled into two separate jobs, which I believe tomeu is working on)
07:54MrCooper: right, but is it just ccache, or is there another cache for some build artifacts?
07:56MrCooper: (BTW, arm jobs are using -j8 already without FDO_CI_CONCURRENT)
07:59daniels: there's no cache for artifacts beyond ccache, no
08:00airlied: MrCooper: I ssupect VK-GL-CTS takes the majority of the time and maybe when it hits ccache all is good
08:00airlied: but that is just a wild guess
08:01MrCooper: either that or the two kernel builds could do it I guess
08:08bbrezillon: karolherbst: I pushed a new version to https://gitlab.freedesktop.org/bbrezillon/mesa/-/commits/nir-load-store-alignment, this should fix a few more regressions. Would you mind starting an intel-CI run on this one?
08:42cwabbott: tarceri: no, don't think so
08:54tarceri: cwabbott: ok I'll add a new commit to add a break and will push it to this series https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5705
09:02danvet: uh man, I'm already seeing the next CONFIG_NOUVEAU_BROKEN :-/
09:02tarceri: cwabbott: ok I've pushed it. Its the second last commit. Its running through CI now
09:06tarceri: imirkin, karolherbst: I'm trying to enable -Wimplicit-fallthrough project wide should the following code have a /* fallthrough */ comment or should there be a break here: https://gitlab.freedesktop.org/tarceri/mesa/-/blob/master/src/gallium/drivers/nouveau/nv30/nv30_texture.c#L242
09:40karolherbst: bbrezillon: triggered
09:40karolherbst: danvet: what happened?
09:43daniels: janesma: ^ can you please add https://gitlab.freedesktop.org/bbrezillon/mesa ci/intel branch to the rotation?
10:00ElBarto: is it intentional to have only one swrast buildable at one time ? this was possible to build both with autotools
10:09karolherbst: ElBarto: both gallium ones?
10:09karolherbst: ohh I see.. mhh
10:09karolherbst: I guess that's an artificial limit
10:10ElBarto: gallium and dri (basically -Ddri-drivers=swrast -Dgallium-drivers=swrast
10:10ElBarto: I'm testing a build right now to se if it's breaking or not (I guess it will be ok)
10:10ElBarto: we use to provide both in the FreeBSD package and this I've switched us to meson people have complained
10:10karolherbst: I think you might need to do some symlink magic anyway or so
10:11karolherbst: ElBarto: really? Because I don't see people caring at all :p
10:11ElBarto: we have weird users :)
10:11karolherbst: sure, but I am sure it doesn't actually matter ;)
10:11karolherbst: llvmpipe is the one people should be using
10:12karolherbst: and I doubt people care enough to actually switch to the classic one with bugs in llvmpipe as they probably have a GPU anyway
10:12ElBarto: which one is this one ?
10:12karolherbst: and if not, it causes too much pain anyway
10:12ElBarto: the gallium one ?
10:12karolherbst: and llvm enabled
10:13ElBarto: that's the one I've enabled by default when I've switched
10:13ElBarto: then switch to the classic one as people complained
10:13karolherbst: we have too many sw drivers..
10:13karolherbst: like.. 4?
10:13ElBarto: and now people complain about not having llvmpipe ...
10:13karolherbst: just use llvmpipe
10:13ElBarto: so if I can build both it will be easier for me
10:13karolherbst: why are people actually complaining though?
10:13karolherbst: I mean.. why not llvmpipe?
10:13ElBarto: I have enough real problem to fix
10:14karolherbst: yeah, just use llvmpipe and tell others to move on :p
10:14ElBarto: "blah blah it used to work it doesn't now blah blah you suck"
10:14karolherbst: ahh, sounds like spam
10:14karolherbst: I meant like real issues
10:14karolherbst: maybe we should just remove the classic one completly :p
10:15ElBarto: if you do I'll just commit and remove it too saying "deprecated upstream, switch to llvmpipe"
10:15ElBarto: mhm, is it deprecated already ?
10:15karolherbst: no idea
10:15ElBarto: I can use that as an excuse :)
10:15ccr:rubs his head in wonder
10:16karolherbst: the classic one doesn't sees much love anyway
10:16karolherbst: last 5 commits, the oldest one is from sep 2018...
10:17karolherbst: ElBarto: just say there is closely to no development and llvmpipe is the one most effort is spend on
10:17karolherbst: also llvmpipe is faster and supports more features :)
10:17ElBarto: one user used swrast_dri on a headless machine
10:17ElBarto: I guess without drm kernel driver but I'm not sure
10:17ElBarto: does the gallium one need drm driver ?
10:17alatiera: hi, I enabled debug traces on the windows runner that keeps failing on the CI, if you encounter a new broken windows build please ping me and send me the job url
10:17karolherbst: why would it?
10:17ElBarto: there is kms in the name but I've never looked
10:18karolherbst: ElBarto: llvmpipe is close to supprt 4.6
10:18karolherbst: I think..
10:19ccr:ponders about OpenSWR
10:19ElBarto: mhm, I think that the problem was that neither of them was built (at least for one user that reported a bug)
10:20karolherbst: ElBarto: interesting..
10:20ElBarto: anyway, they both build ok now so I'll justs do that for now and deal with deprecating one on the next update we do
10:21karolherbst: yeah.. I think any real reason why one prefers the other is good to know
10:21karolherbst: but usually you don't hear any afaik
10:21MrCooper: ElBarto: the problem with building both swrast_dri.so is, which one gets installed?
10:22ElBarto: MrCooper: I have /usr/local/lib/dri/kms_swrast_dri.so and /usr/local/lib/dri/swrast_dri.so
10:22ElBarto: first one seems to be the gallium one
10:22ElBarto: that's what we had before with autotools
10:22karolherbst: ElBarto: so llvmpipe wasn't used at all it seems?
10:22MrCooper: there's a Gallium swrast_dri.so as well, sounds like that got clobbered for you then, highlighting the problem
10:23karolherbst: ElBarto: what does "LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep -i vendo" give you?
10:23karolherbst: last one
10:23ElBarto: I don't have them installed right now
10:23ElBarto: just built a package
10:23karolherbst: ElBarto: I meant originally
10:23ElBarto: but let me test on this machine
10:23ElBarto: OpenGL vendor string: Mesa Project
10:24karolherbst: that's the classic one
10:24ElBarto: and I only have /usr/local/lib/dri/swrast_dri.so on this machine
10:24ElBarto: yeah I think so too
10:25ElBarto: OpenGL vendor string: VMware, Inc.
10:25ElBarto: with my new package
10:25ElBarto: so the llvmpipe is taken first ?
10:25ElBarto: and the classic one is still there so if people used that somehow I should be good
10:26karolherbst: could be both the same
10:26karolherbst: we only have one file containing all gallium drivers
10:26karolherbst: but we do hardlink to it
10:27ElBarto: both that's the megadriver thing ?
10:27ElBarto: which explain why both depend on libllvm and also libdrm_amdgpu I guess
10:27karolherbst: the classic one shouldn't :)
10:28karolherbst: it could be that with meson the files get overwritten or something
10:28karolherbst: ElBarto: I have an idea, just tell upstream only supports installing one and llvmpipe is the one recommended upstream and see where this gets you :p
10:28ElBarto: yeah I think I'll do that :)
10:29ElBarto: the original bug was probably that it wasn't build, either my mistake at the time or the user have weird options
10:29ElBarto: thanks !
10:29karolherbst: yeah.. if there is no software driver that can be a problem
10:29karolherbst: but llvmpipe tends to... cause high CPU usages, so there could be a few reports like that
10:30karolherbst: especially on machines with turing gpus without having OpenGL support on 4k screens :)
10:30karolherbst: so all CPUs are busy doing software GL
10:30karolherbst: but well.. either have lower perf and a laggy desktop or don't use OpenGL is the only solution here anyway
10:30karolherbst: or use mesa-master
10:33MrCooper: classic swrast would be even worse there :) basically, classic swrast_dri.so is only really useful anymore on platforms where llvmpipe doesn't work
10:34karolherbst: right, that's what I meant by " lower perf and a laggy desktop" :p
10:34karolherbst: one the machine I got here, llvmpipe seems to be fast enough for a 4k screen :O
10:34karolherbst: but it's a laptop with super loud fans
10:35karolherbst: you can literally control the fans by moving windows around :)
10:35ElBarto: MrCooper: and as long as llvm is available on those platform it should be good enough for llvmpipe right ?
10:36MrCooper: in theory
11:18danvet: karolherbst, see the discussion between james jones and kyrill on dri-devel
11:18danvet: apparently something goes boom with the new modifiers (when running on existing mesa+glamor+modesetting)
11:19danvet: karolherbst, https://firstname.lastname@example.org/
11:21danvet: karolherbst, yup :-(
11:21karolherbst: regression in userspace is a kernel regression :p
11:22karolherbst: danvet: you know what annoys me most about this response?
11:24karolherbst: I replied...
11:25danvet: karolherbst, I'm still confused why there's a mesa nouveau that claims to support modifiers
11:25danvet: but totally fails at it
11:25danvet: like no one tested this before merging?
11:26danvet: agreed that it's a kernel regression, hence we probably need another CONFIG_NOUVEAU_BROKEN
11:26danvet: (about the 3rd or so)
11:26karolherbst: I have no idea.. at least I didn't test it
11:26karolherbst: skeggsb might have
11:26karolherbst: I know about a modifier change in mesa breaking tegra on some boards...
11:26imirkin: nouveau (in mesa) isn't really ready for modifiers afaik
11:26danvet: the entire "make sure it's all reviewed&tested _before_ anything is merged" is kinda to really make sure stuff like this doesn't happen
11:26danvet: imirkin, yeah but why does it blow up?
11:27imirkin: no clue
11:27danvet: the fallback for "no modifier" support should be "no modifier"
11:27danvet: not "hey let me try this random thing here" :-)
11:27karolherbst: I can try to reproduce it locally
11:27imirkin: probably some sort of partial support somewhere
11:27karolherbst: but.. that's not the only kernel regression I have to deal with right now....
11:28imirkin: as karolherbst mentioned, something was done for tegra ... not 100% sure what
11:28karolherbst: I have another one where we have a divide by zero inside the kernel :/
11:28karolherbst: no idea if that hits upstream or just downstream though
11:29karolherbst: imirkin: yeah.. on boot :)
11:33danvet: imirkin, ah yeah hacked-up modifier support for tegra sounds like what could have gone wrong here :-/
11:33karolherbst: I am already close enough to just remove the tegra driver and use kmsro...
11:33danvet: if the nouveau modifier code has implied assumption that it's running on tegra or something like that baked in
11:33karolherbst: but that seems to be a nouveau issue in the end :/
11:34danvet: karolherbst, oh the tegra mesa driver is hand-rolled kmsro?
11:34karolherbst: more or less
11:34imirkin: from before kmsro existed
11:34imirkin: but with extra bits, i think?
11:34karolherbst: danvet: but.. the tegra bit does support acceleration
11:34karolherbst: imirkin: none yet
11:34imirkin: which make it fail to work with DRI3 and depth or something
11:35karolherbst: like the video decoding is on the tegra side, not nouveau side
11:35karolherbst: and some 2D stuff
11:35karolherbst: yeah.. it's very broken
11:35danvet: ah yeah
11:35karolherbst: before that I didn't reallt care much about tegra, but now that I start caring, I get closer to just remove all of that
11:36karolherbst: but apparently the maintainer never found any bugs.. so
11:38karolherbst: danvet: anyway.. we need to discuss this with skeggsb and I don't mind to just remove all of that
11:46karolherbst: danvet: btw, this is what broke the tegra stuff: https://gitlab.freedesktop.org/mesa/mesa/commit/c56fe4118a2dd991ff1b2a532c0f234eddd435e9
11:46karolherbst: big surprise, it's modifier related
11:47danvet: karolherbst, uh if that broke tegra modifiers then it's not in good shape
11:47karolherbst: essentially we get a buffer from tegra handed over we can't render into
11:47danvet: so nouveau modifiers being busted as a collateral sounds about right
11:47karolherbst: so things just break
11:48karolherbst: what's the actual issue? no clue
11:48danvet: yeah but the kirill regression report is for big gpu nouveau
11:48karolherbst: but honestly, I also don't have time to look into it...
11:48karolherbst: yeah.. I know
11:49karolherbst: tagr: I am really close to just nuke the tegra driver... I know we had the discussion a few times, but it's still broken
11:49karolherbst: and it doesn't seem that any of this is getting any better
11:49danvet: can't we move the 2d/video stuff from tegra into nouveau?
11:49danvet: and only use it there when noveau runs on a tegra?
11:49karolherbst: there is none :p
11:49karolherbst: tegra drm is really just nothing
11:49danvet: hm I thought a libva driver exists somewhere
11:49karolherbst: tegra gallium
11:49karolherbst: but that's not in mesa
11:50karolherbst: there is a tegra vdpau thing
11:50danvet: yeah I guess kmsro it is then
11:50karolherbst: I mean, I don't want to decide this without getting an ack from tagr as he is the maintainer in the end.. or is he?
11:51karolherbst: I am quite annoyed by this issue, honestly
11:51danvet: well tegra open userspace seems to be in eternal limbo state
11:51karolherbst: yeah well... true
11:52danvet: for these I've learned to go with airlied
11:52danvet: shitty code might entice someone to start caring and fix it all up
11:52karolherbst: oh I actually care because I need to start deaing with tegra for work stuff anyway
11:52danvet: meanwhile as long as it keeps compiling and not cause additional trouble, who cares
11:52danvet: tag, you're it :-P
11:52karolherbst: I know
11:52karolherbst: I already have internal email threads about this issue :p
11:53danvet: you fixing tegra, airlied fixing s390
11:53danvet: rh must be fun right now :-)
11:54karolherbst: honestly, the worst bits we already prevented :p
11:56karolherbst: bbrezillon: guess you broke something https://mesa-ci.01.org/karolherbst/builds/149/group/63a9f0ea7bb98050796b649e85481845
11:56karolherbst: or it's random fails.. who knows
11:57bbrezillon: karolherbst: I suspect it's not random
11:57karolherbst: yeah.. looked at the log and doesn't seem to be :p
11:58karolherbst: bbrezillon: anyway, ping janesma to get a branch wired up if you didn't already
11:58bbrezillon: karolherbst: daniels did
11:58danvet: linusw, I guess you're going to push all the panel patches?
11:59danvet: hm no sam around
12:03Zeising: ElBarto: o/
12:12karolherbst: in case somebody wants to ack or review the removal of the tegra driver (and replace it with kmsro): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2960
13:25linusw: danvet: I was gonna ask the author if he feels finished :D
13:50danvet: linusw, sounds all perfect :-)
14:14MrCooper: flto: still don't want others to help you get https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5582 merged?
14:57MrCooper: anholt_: is it normal for the arm64_a630_gles3 job to take ~20 minutes? https://gitlab.freedesktop.org/kusma/mesa/-/jobs/3385432
15:22agd5f_: danvet, yeah, I thought so too. I was surprised.
15:34sravn:on very crappy internet connection
15:34sravn: linusw, danvet saw on the logs you talked about panel patches. Anything in particular?
15:35danvet: sravn, just a pile of patches that linusw was reviewing
15:35danvet: and asked him whether he's going to apply them too when ready
15:35sravn: Slowly working through my backlog atm.
15:35sravn: danvet: Got it, they did apply so I have asked for a re-spin.
15:36sravn: they dit _not_ apply
16:23MrCooper: agd5f_: "Same great flavor, now with 0.2% more S-o-b" made my day :)
16:31agd5f_: MrCooper, I was pretty pleased with that myself :)
16:56imirkin: i was sure someone implemented an explicit interpolation ext for mesa... am i wrong?
16:56imirkin: i.e. something that exposes the barycentric values
16:57imirkin: i can't find it in the extension_table.h but i also don't know what it's called :)
16:58imirkin: since when does NV support it? i thought it was AMD_* or osmething
16:58HdkR: That's the Turing one
16:58HdkR: AMD's is AMD_shader_explicit_vertex_parameter
16:58bnieuwenhuizen: ugh, and EXT?
16:58imirkin: neither of those appear in our list
16:59HdkR: I don't believe there is an EXT version
17:01HdkR: I don't think Intel has its own yet, maybe we can get the three companies locked in to a room to create an EXT :P
17:02danvet: agd5f_, lol
17:06pendingchaos: imirkin: https://cgit.freedesktop.org/mesa/mesa/commit/?id=401bfe028387dd82080a2cc65b5f1b461f0382a6
17:07imirkin: ahhhhh, vulkan. that's where i saw it. thank you!
17:08HdkR: Nice, didn't know there's a Vulkan one
17:15anholt_: MrCooper: no, definitely not. supposed to be ~10
17:16anholt_:needs a grafana dashboard of CI job times
17:17anholt_: MrCooper: doesn't look like it was the kernel uprev, I had some suspicions about that one but its pipeline is 11:42
18:46daniels: anholt_: yeah, agree
19:04mattst88: is someone (someone != me) canceling CI in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3559 ?
19:07ElBarto: that's not me since I'm the one who opened this MR :)
19:08ElBarto: but I was going to ask if there was any problem
19:08ElBarto: the first run timeout on the windows build it seems
19:09mattst88: ah, hello :)
19:09ElBarto: Hello :)
19:10mattst88: yeah, there have been some network problems with some of the windows CI runners lately
19:10mattst88: I just want to make sure that by assigning to marge-bot repeatedly that I'm not getting in the way of someone trying to fix the problem :)
19:13anholt_: we need to turn off windows again
21:27t4nk_freenode: running into trouble trying to compile mesa-9999 on gentoo: http://dpaste.com/3QXRKBT
21:28t4nk_freenode: basically ends with: AttributeError: 'Environment' object has no attribute 'wrap_resolver'
21:29t4nk_freenode: is this an issue with python 3.7 somehow?
21:49ccr: looks more like your meson is broken somehow
21:49ccr: at least to me, but I'm no expert
21:49t4nk_freenode: that thought occurred to me too, though now I'm thinking there might be some problem with my gentoo ebuild
21:49t4nk_freenode: using PYTHON_USEDEP
21:50t4nk_freenode: I don't know why it uses 3.7 otherwise
21:53ccr: your gentoo meson package seems to be git version of meson, which had that .wrap_resolver thing change just recently. might work with a release version of meson.
21:54ccr: perhaps you can downgrade (again, I've no idea how gentoo packages work)
21:55t4nk_freenode: heh I searched for wrap_resolver, but all I found was wrap.resolver ;)
21:56ccr: see https://github.com/mesonbuild/meson/commit/026e386ec2bd79fbf4fcd21e93df19c5a22f3ebf
21:56t4nk_freenode: yeh, I was already looking
22:00t4nk_freenode: (meanwhile I downgraded meson, and mesa builds...)
22:00t4nk_freenode: (so thanks ;) )
23:19karolherbst: jenatali: you did file an upstream MR for image support, didn't you?
23:19jenatali: karolherbst: Yeah, haven't updated it in a while though
23:19jenatali: I think there's a few fixups I've since found that need to be pulled over
23:19karolherbst: ahh, okay
23:20karolherbst: I was thinking about looking into it and wire it up for clover
23:20jenatali: karolherbst: It's also going to clash pretty bad with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5278 from jekstrand
23:21karolherbst: jenatali: btw, the ABI to the kernel was full indirect texture/sampler references, no?
23:21jenatali: karolherbst: Yeah, the kernel entrypoint wrapper has "shader input" pointers to images/samplers
23:22jenatali: In our compiler stack we lower those to uniforms
23:22karolherbst: yeah.. I am just questioning if we need this level of indirection :/
23:22jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5242 if you want to take a look though, that was able to run some Photoshop workloads
23:22karolherbst: I'd rather do it the GL way and just count the args or something...
23:23karolherbst: but this texture vs sampler stuff is also a bit annoying
23:24jenatali: karolherbst: Leaving them as inputs until after the kernel nir was fully generated made it easier to collect the metadata that we needed in order to implement the clSetKernelArg ops
23:25jenatali: Not sure how else we'd map from a single binding space of 0 -> N into the various mechanisms we need to use to bind the different kinds of data
23:26karolherbst: I am not even sure how the sampler stuff works out for us as sampler == texture as far as we care :p
23:27jenatali: karolherbst: Sounds like you'd have to provide a sampler for every unique combination of CL image + CL sampler?
23:27karolherbst: on the hardware it's like this anyway
23:27karolherbst: since.. ages
23:27karolherbst: I think fermi was the last gen where it was separate?
23:33karolherbst: jenatali: the more annoying part is that the sampler can also be created at runtime :/ not quite sure how that actually works out
23:33karolherbst: but the CL sampler thing also seems to be quite.. well.. annoying
23:34jenatali: It maps pretty well to D3D, so I'm sure NV harwdare can handle it somehow
23:34karolherbst: I mean the filter mode is the only bit which actually needs to be changed outside the shader/kernel, no?
23:35karolherbst: mhh.. maybe the addressing mode as well
23:35karolherbst: but I alread see that the address mode needs to be handled inside the kernel
23:35jenatali: Yeah addressing mode is the one thing D3D doesn't support
23:36karolherbst: imirkin: do you have any idea on how to deal with runtime variable filter modes inside a shader?
23:36karolherbst: nearest vs linear
23:37karolherbst: jenatali: how does the filter mode works in d3d?
23:37karolherbst: normally in GL you specify that through the API and not in glsl afaik
23:37jenatali: karolherbst: Yeah, same in D3D, you specify it at the API
23:37karolherbst: so how do you deal with samplers created inside the kernel?
23:38jenatali: karolherbst: Reflect it out and force the runtime to bind an appropriate sampler
23:40karolherbst: jenatali: I assume you map all those CL image functions to d3d texture stuff, right? Those feel kind of similiar to textures than actual images kind of
23:40karolherbst: well.. except you can write to it :/
23:41jenatali: karolherbst: Yeah, read-only images get mapped to D3D "shader resource views" which are like GL textures
23:41jenatali: Read-write or write-only images get mapped to D3D "unordered access views"
23:41karolherbst: I see
23:41jenatali: You can't read from a read-write image with a sampler
23:42karolherbst: well.. we can specify some clamping mode but it's not covering all the CL bits
23:42karolherbst: somehow CL images feel annoying misdesigned
23:42jenatali: Looks like they're similar to Vulkan
23:42karolherbst: I mean.. sure.. but creating samplers at runtime is just annoying
23:43imirkin: karolherbst: afaik there's no way to define sampler parameters from within a shader
23:43imirkin: the sampler would have had to have been pre-created and uploaded into the TSC table
23:43imirkin: the shader can then select any sampler in the TSC that it likes
23:43karolherbst: this is so annoying :/
23:43karolherbst: how many entries can we have for images?
23:43imirkin: d3d traditionally allows you to pick any combination of view and sampler you want for a particular texture operation
23:43karolherbst: in compute shaders?
23:44imirkin: which works just fine
23:44karolherbst: imirkin: yeah.. but not _inside_ the sahder
23:44imirkin: the sampler you pick is a pre-created one, yeah
23:44karolherbst: on CL you can say inside the kernel if you want to filter linear or nearest
23:44imirkin: on AMD GCN hw, all that stuff is controlled by the shader directly
23:44karolherbst: I see
23:45imirkin: for CL, i guess you have to pre-created 2x the samplers then?
23:45karolherbst: but that's not the annoying part
23:45imirkin: what about mipfilter parameters?
23:45karolherbst: the kernel can also specify OOB behaviour :)
23:45karolherbst: imirkin: https://www.khronos.org/registry/OpenCL/sdk/2.2/docs/man/html/samplers.html
23:45karolherbst: cords, OOB and fitler
23:46karolherbst: that's all you can change
23:46imirkin: oh wow ok, yeah. someone from AMD designed this :)
23:46imirkin: althoguh ... is it dynamic?
23:46karolherbst: to some degree I think..
23:46jenatali: What do you mean by dynamic?
23:46imirkin: A variable of sampler_t type declared in the program source must be initialized with a 32-bit unsigned integer constant
23:47karolherbst: "A variable of sampler_t type declared in the program source must be initialized with a 32-bit unsigned integer constant"
23:47imirkin: makes it sound like you can't have code which controls the value
23:47imirkin: i.e. it's some fixed value
23:47imirkin: for the entirety of the shader
23:47imirkin: so then there's no problem ...
23:47jenatali: You can either pass a sampler_t into the kernel from the app, or you can have it as a compile-time constant within the kernel
23:47karolherbst: you still can mix and match texture and samplers
23:47imirkin: sure. but that's standard.
23:47karolherbst: we just don't support it in nouveau :p
23:47karolherbst: or do we?
23:47imirkin: we sorta do
23:48imirkin: it's a 32-bit value passed into TEX.B -- some bits are the sampler index, others are the view index
23:48karolherbst: ohhh.. right
23:48imirkin: i forget where the cutoff is exactly
23:48karolherbst: I know
23:48imirkin: but the code knows.
23:49karolherbst: just wondering how that is different for surface ops
23:49imirkin: no samplers for surface ops
23:51karolherbst: jenatali: how does the filter mode affects image writes?
23:51jenatali: karolherbst: Filter mode is part of the sampler. Image writes don't take samplers
23:51karolherbst: ohh, I see
23:52karolherbst: ehh.. this is still super annoying
23:53karolherbst: I think I will just pull your change and fix issues ...
23:53karolherbst: the CTS has enough tests in the end
23:53karolherbst: jenatali: but the things arive as texture or image ops in nir depending on what kind of image you have or is it all just image operations?
23:53jenatali: karolherbst: Yeah, the CTS has plenty of test cases
23:54jenatali: karolherbst: If it takes a sampler, it shows up as a texture operation in SPIR-V. Otherwise it shows up as an image op
23:54karolherbst: ahh, cool
23:54karolherbst: I trust spir-v more than clc here :p
23:55karolherbst: uhh, so if you read, you have a tex op, but if you write you get an image for the same thing?
23:55jenatali: If you read with a sampler, you have a tex op
23:55jenatali: If you read without a sampler, or if you write, you have an image op
23:55karolherbst: ohh.. I see
23:56airlied: karolherbst: just push tthe structrizer before doing imagse :-P
23:56karolherbst: I didn't see the overloads without samplers
23:56karolherbst: airlied: jekstrand will kill me :p
23:56karolherbst: but yeah
23:56airlied: nah I don't think he'd notice since he doesn't care about CL yet :-P
23:56karolherbst: I should get the vtn bits straight before that :p
23:56karolherbst: airlied: he will notice that I changed vtn_cfg :p
23:57karolherbst: or maybe we should just hope he doesn't?
23:57karolherbst: dunno, your call :p
23:57karolherbst: I mean, everybody is free to just merge the branch :p
23:59airlied: karolherbst: yeah if you get the vtn bits clean he might care less
23:59airlied:is scared of the vtn code