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