00:03jekstrand: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6435
00:03jekstrand: karolherbst: I also fixed the other two nir_lower_bool_to_* passes
00:03jekstrand: Both of which were copy+paste from bool_to_int
00:03karolherbst: yeah.. that's more nice
00:03karolherbst: r-by, I hope that works :D
00:04karolherbst: but I shouldn't put bool lowering into an opt loop I guess...
00:04jekstrand: heh, no.
00:04karolherbst: but should I call it before or after? mhh
00:04karolherbst: shouldn't matter I guess?
00:04jekstrand: You should call it basically as the last thing before going into codegen
00:05karolherbst: okay.. then I'll move it back where it was :p
00:06karolherbst: at some point I'll call the proper optimizations :p
00:06karolherbst: oh well
00:08jekstrand: I wonder if clover just predates the implementation of texture_view in gallium. That doesn't really sound right....
00:08jekstrand: texture view should be pretty old
00:09karolherbst: I am sure clover existed before we had compute shaders
00:09karolherbst: jekstrand: if you don't want nightmares, don't look into those early compute TGSI tests :D
00:10karolherbst: I think that explains a lot
00:10karolherbst: "DCL RES, BUFFER, RAW, WR" :O
00:10jekstrand: Oh... gallium treats pipe_image_view as an ephemeral object
00:11imirkin: there's no refcount on it, just a struct to pass info around
00:12karolherbst: back at "Pass 106 Fails 0 Crashes 0 Timeouts 0"
00:13imirkin: karolherbst: afaik nothing supports those "RAW" buffer resources. nouveau had some handling for it, but i mostly commented it out while adding support for the GL stuff.
00:13jekstrand: Ugh... pipe_surface even for images? Am I reading this right? I hope not.
00:13karolherbst: jekstrand: you do
00:13imirkin: although that was my original proposal :)
00:14jekstrand: imirkin: ?
00:14imirkin: oh. in clover. yes.
00:14karolherbst: jekstrand: it also uses pipe_surface for constant buffers :p
00:14imirkin: my original proposal for images in gallium was to do that for graphics as well.
00:14jekstrand: imirkin: I'm still not connecting the dots. Do what?
00:14imirkin: use pipe_surface for images.
00:16imirkin: fwiw the history of clover is fairly long, and originally there were hopes of a tgsi llvm backend
00:16imirkin: so a lot of stuff got hooked up with the expectation of that coming to pass at some point, well ahead of GL having compute/etc support
00:16karolherbst: I am kind of glad that never worked out
00:16imirkin: (by many years)
00:16jekstrand: Why do both pipe_surface and pipe_image_view exist?
00:16jekstrand: They look roughly the same to me
00:16imirkin: pipe_surface was used by clover for all surfaces
00:17imirkin: pipe_surface is ref-counted, while pipe_image_view is not
00:17imirkin: when adding images to gallium, mareko opted to create pipe_image_view
00:17jekstrand: But they're otherwise basically the same?
00:17imirkin: although my proposal was to use pipe_surface at the time. we had a long conversation about it, and i couldn't come up with any strong arguments against pipe_image_view iirc.
00:17imirkin: they are rather similar
00:17jekstrand: Other than having two things
00:18imirkin: i think there are some slight differences that don't matter for images.
00:18jenatali: jekstrand: The direction of these questions makes me think you're trying to hook up CL images
00:18jekstrand: jenatali: I'm looking at it
00:18jekstrand: jenatali: And getting horrified
00:18karolherbst: jekstrand: guess why I am procrastinating it
00:18jekstrand: There's a lot of dust in this corner.
00:18imirkin: jekstrand: the counterargument to "two things" is "refcounting", so they kinda balance out
00:18jenatali: I think aside from the address space shenanigans (which I haven't had enough time to look at in-depth today) the nir bits shouldn't be *too* bad
00:18karolherbst: yeah.. nir isn't the issue
00:18karolherbst: clover is
00:18karolherbst: it's not _that_ bad
00:19jekstrand: imirkin: Sure but what is being refcounted? The descriptor?
00:19karolherbst: I got it mostly working at some point
00:19jekstrand: imirkin: The actual memory is already refcounted by pipe_resources
00:20jekstrand: imirkin: I'd argue that the refcounting might be an argument in favor of switching to pipe_surface. It's not really an argument for two things.
00:20jekstrand: Unless it's reference coungint something useful.
00:21imirkin: jekstrand: yes. hence the argument to add a pipe_image_view which is not refcounted.
00:21jekstrand: imirkin: ?
00:21imirkin: pipe_resource is already refcounted, like you said
00:21imirkin: having persistent "surface" objects isn't extremely useful
00:22imirkin: and adds unnecessary overhead
00:22jekstrand: A driver with persistent descriptors (like iris) could possibly gain a little from it.
00:22imirkin: well, that's not amd's thing
00:22imirkin: i got tired of the conversation.
00:23jekstrand: I don't have an opinion.
00:23jekstrand: I'm just trying to understand what's going on
00:23imirkin: and since he (or nha? i forget actually) were working out the details, i figured they get to pick given that it's unclear.
00:24jekstrand: I'm just hoping that we can move away from clover being a special snowflake and acting more like st/mesa
00:25jekstrand: That's my only axe to grind here
00:26karolherbst: and I guess that's fine to port clovers way of doing over to st/mesa way
00:26karolherbst: CL images are just...
00:26karolherbst: especially the sampler part
00:27imirkin: jekstrand: that'd be nice. i think there are some slightly different requirements from CL which can make that tricky
00:27imirkin: not in the surface vs image_view thing
00:27imirkin: but for other stuff
00:27karolherbst: so worst case we end up binding 6 sampler views per texture
00:27karolherbst: or so
00:27jekstrand: imirkin: Totally. I don't expect that we can make clover "just work" for any driver which supports compute.
00:27karolherbst: imirkin: so you can switch the filter inside the kernel
00:27jekstrand: imirkin: But we can reduce the unnecessary impedence mismatch.[
00:28jekstrand: Like surface vs. image_view or grid::inputs vs. cbuf0
00:28karolherbst: also coord normalizations but that shouldn't matter for the sampler view?
00:28karolherbst: we kind of have make this to work even if the kernel declares those samplers inside the kernel and mix and amtches images + samplers: https://www.khronos.org/registry/OpenCL/sdk/2.2/docs/man/html/samplers.html
00:28imirkin: jekstrand: well, kernel inputs are a special feature of CL, and supported at least on nv50
00:29jekstrand: karolherbst: That should all be in pipe_sampler_state
00:29karolherbst: imirkin: we don't know the reason why we use shared on nv50, right?
00:29jekstrand: imirkin: Sure. And we can map them to push if we really care
00:29karolherbst: jekstrand: samplers can be created inside the kernel
00:29imirkin: if you want to pass them in via cbuf0, then you can
00:29jekstrand: karolherbst: Yeah, we have to pull them out and make states.
00:29imirkin: karolherbst: because it's there?
00:30karolherbst: imirkin: shouldn't cb be faster?
00:30imirkin: presumably not?
00:30karolherbst: maybe nv50 is just weird then
00:32karolherbst: jekstrand: the one issue is that for nouveau we kind of can't really split things up as easily I think...
00:32karolherbst: at least not for newer hardware?
00:32karolherbst: except I miss something?
00:32karolherbst: imirkin: we can't runtime select the sampler for a texture, right?
00:32imirkin: sure we can
00:33imirkin: via texture op args? not sure what you mean
00:33karolherbst: I mean, the handle we hand in points to the const buffer pointing into the tic table
00:34karolherbst: tic/tsc table
00:34jenatali: For what it's worth, we end up recompiling the kernel based on sampler parameters
00:34imirkin: karolherbst: for kepler+ yes.
00:34karolherbst: I guess we could build the handle at runtime...
00:34jenatali: In practice I don't think it's going to be a big deal, apps aren't going to dynamically use different sampler properties in the same kernel
00:34imirkin: karolherbst: and each handle is still a tic/tsc entry combination.
00:34karolherbst: and go bindless
00:35karolherbst: let's see...
00:35imirkin: and on nv50/fermi you can explicitly select a texture and sampler id
00:35imirkin: (unless you're in linked tsc mode, which we don't enable)
00:36karolherbst: I am not worried about those, just kepler+
00:36imirkin: on kepler+, yeah, you have to use the .B variant. boo-hoo.
00:36karolherbst: soo.. the texture unit fetches the sampler and the texture ptr from the constant buffer
00:36karolherbst: in non bindless mode
00:36karolherbst: in bindless we just hand in the same data directly, right?
00:37karolherbst: and those are still just handles
00:37imirkin: yes, just saves on the const buffer fetch
00:37imirkin: (and presumably allows hw to do some manner of optimization)
00:37karolherbst: yeah.. so we could have all combinations CL asks for
00:37karolherbst: and just runtime select the sampler
00:38karolherbst: cls sampler is a bitmask anyway
00:38karolherbst: and we might be able to map it directly to samplers
00:38karolherbst: or is there some data we have to set depending on the texture?
00:39karolherbst: I don't really know what we encode inside the sampler
00:39karolherbst: maybe I should just try to implement it and see how that goes
00:41pmoreau: Oh great, glibc 2.32 removed sys/sysctl.h which had been deprecated since 2.30, so now the OpenCL-CTS no longer compiles. :-|
00:41karolherbst: I am sure that's not hard to fix :p
00:41pmoreau: Revert back to using glibc 2.31 :-D
00:42karolherbst: pmoreau: use my cl_wip branch btw ;p
00:43pmoreau: Will do, sometimes during the weekend after I got some sleep and managed to go through finishing to update the labs before students start the course.
00:43karolherbst: that's fine :p
00:44karolherbst: what a rebase "f840914f...e3e45e24 - 3782 commits from branch mesa:master"
00:46karolherbst: anyway.. time for bed
00:53pmoreau: Yeah, I should go to bed too…
00:57pmoreau: I am not even sure the CTS used sys/sysctl.h on Linux: I can remove those includes without any issues.
08:49mareko: jenatali: pipe_surface vs pipe_image_view is more complicated; surfaces are only used as a framebuffer state, while image views are used as a shader resource state; the only reason surfaces were used for writable shader resources in the past was that old hardware (r600) had to use the render target hardware for writable shader buffers and images, which was a pretty ugly design (back then all shader
08:49mareko: resources were read-only and the only write data path was through render targets)
08:50mareko: jekstrand: ^^
09:03mareko: jekstrand: another reason for not using pipe_surface was that it precomputes render target state, which is different from image state
09:10mareko: and also pipe_surface is malloc'd, while pipe_image_view isn't, so binding the latter has lower overhead for GL
10:14MrCooper: mattst88: surely Marge should have a Marge Simpson avatar :) (gstreamer's marge-bot account already does)
11:02Yuti: How to filter modes in atomic check if previously link is not trained?
12:40emersion: Yuti: the idea is that you don't filter them, and after link training if the link doesn't support the mode you use link-status to signal to user-space that the modes list is reduced
12:42imirkin: but you can and should filter based on the overall theoretical capabilities
12:42imirkin: you know how many lanes you have and what speed they support, and you can get the sink's capabilities as well via dpcd
12:42emersion: right -- filter them with all the info you have without link training
12:59emersion: Yuti: the core idea is that atomic test-only commits must remain fast -- user-space will potentially do a lot of test commits
12:59emersion: a lot can be hundreds or more
13:00emersion: because the only way for user-space to find a configuration that works is to brute-force all potential configurations
14:45jekstrand: mareko: IVB also used the render hardware for image writes but that didn't affect surface states.
14:49hanetzer: agd5f_: hey question. I'm writing a blog post about my display hardware and would like to mention you as being the guy who provided the fix for the kernel driver. What should I refer to you as?
16:59mattst88: MrCooper: haha, that would be awesome. I can support that :)
19:26Venemo: who is in charge of softpipe these days?
21:18airlied: Venemo: nobody/everybidy
21:20airlied: sroland, brianp, me, anholt probably last few ppl to poke at it
21:48karolherbst: jekstrand: btw, I've got the locking stuff nearly working on nouveau as well :D
21:53karolherbst: I forgot to set the result :D
21:56karolherbst: and now I overwrite stuff mhhh
22:04Venemo: airlied: do you think this would be a good approach to fix the warnings in it? https://gitlab.freedesktop.org/Venemo/mesa/-/commits/softpipe-warnings
22:09kisak: Venemo: there was a bit of a push to turn on -Werror where it could in CI. Cleaning up more subcomponents to the point that some more CI can run with -Werror can't hurt.
22:11kisak: ^about a month ago (!5185 !5730 !5799)