06:57danvet: sravn, patches 21 and 22 are also still looking for review ...
07:14airlied: jekstrand: oh one thing that I had in my brain to tell you, for sw vulkan you can't block on queue submit
07:15airlied: since you have to be able to let event work
07:15airlied:has a cpu thread and the llvmpipe stuff executes in the "gpu" thread
07:53pepp: https://gitlab.freedesktop.org/pepp/mesa/-/jobs/2034822 ends with "ERROR: No files to upload. Job succeeded" : I don't see any other error in the log that could explain this failure
07:53pepp: (that's meson-arm64 job)
08:05tomeu: pepp: I see those occasionally, retrying always work for me
08:05pepp: tomeu: ok. I'll do that, thanks
08:20MrCooper: robclark: somebody should try to get some ASan coverage in CI :)
08:22MrCooper: karolherbst: click on the commit title on the MR Commits tab, then clock the button to the left of the line of code where you want to comment
08:52sagner: Hi, I am debugging a DRM driver issue, my display looks distorted when starting Weston with DRM backend. Framebuffer console/plymouth with DRM backend before that looks fine. This is a panel with a single mode, so Weston can actually not change much, but I now printed the complete atomic state, and the only difference I see is the layers pitch: its 3200 vs. 3328 (the resolution is 480x800). Any
08:52sagner: idea where this could come from?
08:53sagner: FWIW, this is the mxsfb DRM driver
08:54sagner: Hm, is Weston trying to cache align the pitch?
08:55MrCooper: I doubt the pitch is chosen by Weston, more likely the EGL implementation
08:55sagner: This is a non-GPU device, just a display controller...
08:56MrCooper: ah, never mind then :)
08:57sagner: 4x800 -> 3200, 4x832 -> 3328, and 832 is 64 byte aligned... But who is taking that descision, and probably more importantly, can I do something about it
08:58danvet: sagner, yeah for display-only without egl or anything the pitch should be exactly the same
08:58danvet: since everyone should allocate it as a dumb buffer
08:58danvet: could be a driver bug too
08:59danvet: console is using the fbdev emulation, plymouth might also accidentally prefer fbdev over native kms
08:59danvet: and the two paths can differ (but really shouldn't)
08:59sagner: danvet: pretty sure I use the KMS backend of plymouth though
08:59danvet: sagner, double checked which /dev node plymouth has open?
09:00danvet: sagner, either way there's definitely a kms driver bug too, since the driver is supposed to either program hw correctly, or if there's a constraint, reject the buffer
09:00sagner: danvet: doesn't allocated by = plymouth already tells us that?
09:00danvet: silent corruption isn't good
09:00pinchartl: vsyrjala: ping
09:01sagner: danvet: hm, I'll check if I can use non fb with pitch, and otherwise reject
09:01danvet: sagner, hm maybe?
09:01danvet: sagner, but yeah I think there's two things, the different pitch and the corruption itself
09:02sagner: danvet: oh stupid me: I was using EGL through Mesa emulation! Passing --use-pixman helps :-0
09:02sagner: danvet: oh stupid me: I was using EGL through Mesa emulation! Passing --use-pixman helps :-)
09:04danvet: sagner, still a kernel bug to fix I think
09:04sagner: (Sry, use too much Slack lately)
09:04sagner: danvet: yeah agreed, will check
09:09pq: sagner, is weston with Pixman-renderer or GL-renderer? Yes, you can use GL-renderer without a GPU.
09:11pq: so why does the pitch chosen by Mesa not work?
09:11pq: Why is Mesa picking a pitch that does not work?
09:11danvet: pq, bug in kernel driver
09:12pq: danvet, well, kernel driver accepting a buffer and showing garbage is a kernel driver bug, sure. But if the driver rejects it, I think Weston just wouldn't work at all.
09:13pq: so something needs to know to use the right pitch somehow, even with GL-renderer
09:13pq: with GL-renderer, the buffer allocation is inside Mesa (EGL/GBM)
09:17sagner: pq: yeah kernel driver bug I agree, it should reject that pitch. Currently checking if the IP supports such framebuffers, but from what I can tell it does not, so I guess it should just reject it.
09:19pq: sagner, right, but that also moves the failure to another place I assume. Depends on what Mesa does.
09:38sagner: Rejecting it now, it seems that Weston/Mesa does not do much in this case, Weston prints this at the end but is running wihtout anything on the display: [09:35:06.916] atomic: couldn't commit new state: Invalid argument
09:39pq: sagner, well, yes. Weston assumes that when you initialize GBM with the DRM KMS device, then Mesa will produce good fraembuffers.
09:40pq: If Mesa does not, then what could Weston do? Falling back to Pixman-renderer would be a lot of code for a corner case.
09:40pq: Mesa failing to initialize with GBM or failing to create an EGLSurface might be manageable to fall back, but still not handled in Weston today.
09:41pq: I would point the finger at Mesa for producing framebuffers that don't actually work on the device it was passed in.
09:43pq: It may also be that the pitch difference comes from llvmpipe requirements, in which case Mesa would need to fall back to softpipe or something, and I imagine that too might be quite hard to implement.
09:44pq: sagner, hm, do you by any chance have VKMS loaded in your kernel, creating a DRM device?
09:44pq: err, I mean VGEM, not VKMS
09:46pq: sagner, anyway, I think filing a Mesa issue would be nice.
09:47sagner: pq: "# CONFIG_DRM_VGEM is not set" but I can easily...
10:00sagner: pq: enabled it, but it does not make a difference.
10:10daniels: sagner: Weston doesn't try to align the pitch, but llvmpipe (the Mesa sw renderer) does
10:10daniels: so if you use EGL with no hardware GPU, tat's what'll happen
10:11sagner: Yeah I see now, that makes sense. I guess what I wonder if we can do something smart about it. I now reject in the planes atomic_check callback, similar to how tilcdc is doing this.
10:12sagner: Now I was about to report a Mesa bug, but can Mesa do something abotu this? E.g. isn't Weston actually setting up the DRM planes and all that?
10:14sagner: From what I understand, Mesa allocates the frame buffer, but Weston then tries to display it on a plane, and only then the kernel rejects this. So at allocation time we don't know about this yet, or do I understand something wrong here?
10:15daniels: there's no way the KMS can tell Weston that pitch must be equal to width * bpp
10:15daniels: for the (many) drivers which require alignment to e.g. 32 bytes, there's no way they can tell Weston that the pitch must be aligned to 32 bytes either
10:15daniels: so there's no way for Weston to tell llvmpipe about the requirements it doesn't know about
10:17sagner: daniels: So no real solution for this issue then?
10:20lynxeye: sagner: daniels: Hm, shouldn't llvmpipe do a dumb buffer allocation? In which case the DRM driver should be able to decide on pitch.
10:20sravn: danvet: I gave up reviewing 21, the code movements looked OK but I could not see the full picture. Will take a look again later today, after work sometime
10:22sagner: lynxeye: this is probably me not understanding KMS quite yet, can the driver influence buffer allocation? I guess not when using the regular gem stuff?
10:24daniels: lynxeye: it should
10:24lynxeye: sagner: With regular GPU drivers the Mesa GPU driver also needs to know about the scanout side (KMS) constraints and make sure to layout the buffer correctly. But with a dumb buffer the KMS side actually gets to decide on the pitch requirement.
10:25danvet: sravn, I might have botched something in rebasing, bisecting a bug towards that range of patches right now :-/
10:27sagner: lynxeye: I see, so maybe I should open a kernel bug then instead?
10:28lynxeye: sagner: sorry, I missed the start of the conversation. Are you talking about mxsfb?
10:28sagner: lynxeye: yes
10:29sagner: lynxeye: there is definitly a bug that it does not implement stride != width, and also not reject it (from what I understand the IP can't handle that)
10:29pinchartl: sagner: thanks for you review btw
10:29pinchartl: I'll work on a v2
10:30lynxeye: sagner: The problem (to me) seems to be that this driver uses drm_gem_cma_dumb_create without feeding in the HW pitch alignment requirements. It should use drm_gem_cma_dumb_create_internal and adjust pitch to HW requirements as needed. meson driver seems to do this correctly.
10:30sagner: pinchartl: you're welcome! Oh btw, crash I reported was most likely a power issue, I wanted to send you a email about it.
10:30pinchartl: sagner: good :-)
10:30pinchartl: I like hardware issues, that's less debugging for me
10:31sagner: Hehe, yeah me too!
10:31sagner: lynxeye: oh cool, ok will check how meson driver is doing this.
10:32sagner: pinchartl: since you worked on the IP recently, do you agree with me that the IP can't handle pitch which do not match width?
10:36pq: sagner, VGEM could have only caused confusion, not fix anything - sorry :-)
10:37sagner: pq: ok, got it, so worries
10:40pq: sagner, so yeah, I was assuming the kernel driver was already doing dumb buffer allocation correctly (it works if weston does it manually, so why does it not work from Mesa?)
10:41pq: erm, it works if weston calls dumb buffer alloc manually
10:41pq: so I jumped to the conclusion that Mesa must be doing something different from Weston
10:44pq: sagner, the KMS dumb buffer alloc works such that userspace submits DRM_IOCTL_MODE_CREATE_DUMB with width,height,bpp, and the driver returns a buffer and pitch (in bytes) which userspace must use.
10:45pq: it's hard for me to imagine how it can work for one caller (weston) but not for another (Mesa)
10:47pinchartl: sagner: I haven't looked at that, but I can :-)
10:47pinchartl: on i.MX7 specifically, or in general ?
10:50sagner: pinchartl: I use i.MX 7 so probably the first thing to look at. I also assume that if it can't do it the olders most likely cannot do it either
10:55pinchartl: sagner: indeed, I see no stride support in the datasheet for i.MX7D
10:56sagner: pinchartl: Ok, thx for checking!
10:59pinchartl: sagner: it's a pretty bad display controller :-S very limited
11:02sagner: pinchartl: yeah I know, I was surprised that they put it even in newer designs (several i.MX 8 series SoC have it)
11:02pinchartl: same for the camera side, several i.MX8 SoCs have the same IPs as i.MX7, and they're missing very basic features
11:03sagner: pq: using softpipe Gallium driver works as well, seems to use pitch which matches stride
11:04pq: sagner, ok. I wonder if Mesa just "forgets" to use the pitch returned by the DRM driver.
11:28sagner: pq: unfortunately strace cannot decode the arguments/return value of DRM_IOCTL_MODE_CREATE_DUMB, but I can see that in one case DRM_IOCTL_MODE_ATOMIC subsequently fails of course.
11:30pq: sagner, you want to make sure the driver returns the pitch you expect?
11:31pq: nothing comes to mind really, not sure even drm.debug would print it
11:31sagner: pq: Yes. Ok, will try that.
11:32sagner: pq: I guess after making sure DRM behaves as we expect I should then create a bug report with mesa..
11:37pq: yeah, if the driver returns the right pitch, but then the DRM FB is created with a wrong pitch, that's a userspace fumble.
11:42pq: sagner, Mesa GBM hands out a gbm_bo, weston queries the gbm_bo and creates a DRM FB, then uses that in KMS. drm_fb_get_from_bo() is the relevant Weston function, fwiw.
12:34sagner: pq: hm, I added some printk in drm_mode_create_dumb and it seems width is 832
12:41danvet: tzimmermann, uh ... I need this or fireworks https://paste.debian.net/1136325/
12:41danvet: and the fireworks happens on the kfree_const
12:41danvet: tzimmermann, since you suggested this, any idea where the bug is?
12:41danvet: or is this just not working
12:46pq: sagner, I presume that's not what you expect? Maybe check the size in weston to see if it's Mesa or Weston?
12:51sagner: pq: yeah not sure what I was expecting, probably a with of 800. But when I think more about it, I guess its the only way user space can allocate a buffer with a larger pitch than width...
12:52sagner: pq: but that would mean that Mesa would just assume that the display controller can handle width < pitch..
13:05sagner: lynxeye: from what I can tell meson used to have the oposite problem: user space chosed a pitch which was not aligned by 64 bytes. Hence the new .dumb_create forces DRM_IOCTL_MODE_CREATE_DUMB to create a framebuffer with a higher pitch than with.
13:06sagner: But with mxsfb we have the opposite problem.
13:10sagner: Anyways, created a Mesa issue and will leave it at that for the moment. Thanks everyone for your help getting to the bottom of this!
13:15sagner: FWIW: https://gitlab.freedesktop.org/mesa/mesa/issues/2677
13:15gitbot: Mesa issue 2677 in mesa "llvmpipe backend fails on device with pitch/width restrictions" [Opened]
13:38tzimmermann: danvet, is the 'name' field of type const char*? the string "kmalloc" has to be in the kernel's read-only data section. maybe it's considered writeable if you assign directly to 'name'. otherwise, no idea
13:38danvet: tzimmermann, yeah the name field in the struct is const char *
13:45tzimmermann: danvet, idk i don't know why. i'd first check if "kmalloc" is in the rodata section. and then see if that changes w/o kstrdup_const. maybe the compipler expects the const to be cast away and puts it into writeable memory.
13:46tzimmermann: if it get's too complicated to use, i'd leave out the whole _const stuff
13:48emersion: dunno if that helps, but you need to define strings with `const char str = "…"` rather than `const char *str = "…"` to get it in .rodata
13:51tzimmermann: emersion, yeah, that's the better solution. but not really possible here
13:53pq: sagner, userspace has no way to allocate a dumb buffer with a pitch different from what the kernel driver determines. If userspace attempts to, e.g. by hacking the width, the driver can no longer guarantee the pitch will be right for the *actual* width.
13:53pq: sagner, Mesa might well assume that - and it would be wrong I suppose.
13:53emersion: you might want to try `char *const str`
13:57danvet: emersion, most of our const char * strings are random arguments to functions
13:58danvet: so these are all outside of .rodata?
13:59emersion: err, i mixed it up again
14:00pq: I think writable string constants is a compiler option.
14:00emersion: const char * is a mutable pointer to a constant char
14:00emersion: char *const is the other way around
14:01pq: I mean literal string constants
14:02emersion: i don't think it's ever legal to write to a string literal?
14:03pq: yeah, you'd think ;-)
14:03pq: and probably usually is
14:06linkmauve: emersion, it actually is. :x
14:06linkmauve: Just like it is legal to modify another static array somewhere.
14:11emersion: linkmauve: this segfaults for me
14:11emersion: char *str = "abc"; str = 'b';
14:12emersion: and it's stored in .rodata
14:30linkmauve: Indeed, I was wrong.
14:31jekstrand: airlied: Uh.... :-(
14:34pq: linkmauve, emersion, sounds like UB: https://stackoverflow.com/questions/56743877/can-a-string-literal-in-c-be-modified
14:35emersion: makes sense
14:41danvet: emersion, so the const story, if I pass it to kstrdup_const("kmalloc", GFP_KERNEL)
14:41danvet: then it's in .rodata
14:41danvet: but if I assign the pointer directly then it's not in .rodata
14:41danvet: or at least everything blows up
14:42danvet: so yeah magic
14:42danvet:still doesn't know how C works
14:43pq: danvet, do you mean that is what happens, or that is how you understand what emersion said?
14:44danvet: that is what seems to happen
14:44danvet: i.e. ptr = "kmalloc"; -> somehow the string isn't .rodata
14:44danvet: but as a parameter to the funcion is is in .rodata
14:44danvet: it's C so I'm not surprised, but yes
14:45pq: I don't understand that either.
14:45danvet: anyway intel-gfx-ci says there's also something else still broken, oh well
14:45ickle: note also that the _const() only recognise char in the builtin .rodata and not modules
14:46danvet: oh disappoint
14:47danvet: maybe it should check the pte flags
14:47danvet: or something like that
14:51pq: sagner, I don't understand "Invalid pitch: fb and crtc widths must be the same" - which one is wrong, pitch or width?
14:53sagner: pq: pitch is wrong (Invalid pitch)...
14:53sagner: pq: FWIW, the message is from drivers/gpu/drm/tilcdc/tilcdc_plane.c
14:53pq: misleading error message then, talking about width
14:54sagner: pq: hm I see, probably should be Invalid pitch: fb's pitch and crtc's width must be the same
14:55pq: also, always be careful with pitch/stride units, you can never assume pixels vs. bytes ;-)
14:56pq: maybe "Invalid pitch: padding not allowed"?
14:56vsyrjala: pinchartl: yes?
14:57arora: Hey jekstrand, here's the deliverables part as of now: http://vpaste.net/ysCxe
14:57arora: What should be the second milestone accordingly?
14:57sagner: pq: hm not sure if that is accurate, as smaller pitch would also not be allowd
14:57sagner: pq: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_plane.c#L57
14:57pinchartl: vsyrjala: I had a question for you regarding pixel formats
14:58pq: sagner, a smaller pitch does not make sense anyway, at least to me
14:58pinchartl: do I understand correctly, from the descriptions in drm_fourcc.h that define pixel formats as "[n-1:0] X:Y:Z:... little endian" that the layout on memory, as seen in a u8, is the same for both little-endian and big-endian platforms ?
14:59pq: but yeah, I see
15:00vsyrjala: pinchartl: yes, that was the idea
15:03pinchartl: I was trying to map DRM formats to Qt formats (https://doc.qt.io/qt-5/qimage.html#Format-enum), it seems that most of them have a different memory layout depending on the endianness of the underlying platform
15:03pinchartl: a bit of a mess
15:04vsyrjala: there was some cool tool someone wrote to map pixel formats of different systems to each other
15:04vsyrjala: on github somewhere
15:05vsyrjala: https://github.com/afrantzis/pixel-format-guide i guess
15:07vsyrjala: seems to know about qt as well
15:54jekstrand: kusma: Getting tired of working on Linux are we?
15:56daniels: jekstrand: PowerShell is actually _really_ nice
15:56daniels: the secret is setting up OpenSSH so you can just SSH in and execute on PowerShell, plus VS Code's SSH-remote support, so you can still use your Linux machine to do everything, and it just happens to execute on something with DX :)
15:57jekstrand: daniels: Yeah, I've heard really good things about VS Code via SSH
15:58dj-death: you really need ot throw in wine in there to do vulkan over dx over vulkan
15:58daniels: i've been really happy with it, and can't say enough good about PowerShell. the naming is a bit verbose, but apart from that it's really what every shell should be - sort of like the good bits of shell (easy piping/chaining, DWIM by default) and Python (rich objects) together.
15:58imirkin: fwiw when nouveau allocates framebuffers, they're all aligned to 256 (which is what the hw requires to scan out for like 99% of the cases)
15:59imirkin: sagner: --^
15:59jekstrand: daniels: Yeah, I've heard good things. I just don't have reason to spend time in a Windows environment so I've not bothered to really learn much about it.
16:00imirkin: i think if the driver produces correctly-sized fb's, things should be fine? dunno. maybe those driver-allocated ones only get used in certain situations but not with DRI3...
16:03kusma: jekstrand: too much kernel-recompiling :(
16:03kusma: See, with windows that's not even an option!
16:04jekstrand: kusma: Ah! Yeah, we can't have people compiling their own code. That's just not a good plan.
16:06kusma: jekstrand: Maybe we can port to ReactOS?
16:06kusma: I mean, kernel recompiling is *really* a use-case that I want to support.
16:06bnieuwenhuizen: jekstrand: wrt workarounds for syncing with "bindless" stuff, you talked earlier about adding and removing a WSI buffer from a global buffer list based on AcquireNextImage and QueuePresent. However, can an application still read from an image that is currently being presented?
16:07jekstrand: bnieuwenhuizen: I'm not sure. There is some image ownership language in the WSI extensions that I've never fully understood.
16:07kusma: jekstrand: To be a bit more serious, I hope to get some more time for Zink again in the not too distant future. My passion for Vulkan is bigger than my passion for D3D12 ;)
16:08jekstrand: kusma: Yeah, I get that. But someone's got to pay the bills...
16:09kusma: jekstrand: Something like that. And it's not like these two projects can't share a bunch of code, lots of details are exactly the same ;)
16:09jekstrand: Yeah, they're really very similar
16:09jekstrand: The presentable images of a swapchain are owned by the presentation engine. An application can acquire use of a presentable image from the presentation engine. Use of a presentable image must occur only after the image is returned by vkAcquireNextImageKHR, and before it is presented by vkQueuePresentKHR. This includes transitioning the image layout and rendering commands.
16:10ccr: sooon .. <kusma @ 2022> meh .. this modern multimedia sux, going to OCS Amiga now
16:10bnieuwenhuizen: jekstrand: ok, that is helpful
16:10kusma: ccr: A copper-list NIR-backend would be awesome.
16:11jekstrand: bnieuwenhuizen: So I think you can just hook acquire/present and set/unset a flag.
16:11jekstrand: bnieuwenhuizen: If you want a hook for that, feel free to add one; otherwise you can do it internally.
16:13bnieuwenhuizen: thanks, I'll work with that
16:18arora: Hey jekstrand, here's the deliverables part as of now: http://vpaste.net/ysCxe
16:18arora: What should be the second milestone accordingly?
16:19jekstrand: Right, I think the first milestone is basically to take ownership of the current MR and land it.
16:20jekstrand: Or maybe that's milestone 0?
16:20jekstrand: For the second one, I think having a basic config file system which is able to detect a app by name and apply a policy.
16:21jekstrand: We don't need to have all of the details of exactly how the policy system works finalized but we should at least have a POC which is able to detect an app using a few different mechanisms (engineName, appName, and executable name) and apply some different policies such as re-order, or force a specific GPU.
16:22jekstrand: Once we have all of the mechanics in place (this likely won't be landed yet), we can finalize what we want the config file format to look like when it comes to specifying the policies to apply.
16:24jekstrand: arora: We could also go the other way around and try to specify the policy format first but, in my experience, we're likely to come across "fun" issues in the implemenation which will need to impact the policy file format so it's probably better to get an implementation at least half working first.
16:27arora: jekstrand: Right, the implementation will come with some quirkiness, but isn't the config file system the final milestone?
16:27jekstrand: arora: Yes
16:27jekstrand: arora: The final config file system is the final milestone
16:28jekstrand: arora: There are going to be a lot of decisions to make between prototype and final
16:28arora: So the implementation would be the second milestone?
16:29jekstrand: arora: Yeah, roughly.
16:30jekstrand: arora: What I'm thinking is bsically three steps: 1. land what we have now, 2. Get a more complex policy prototype mostly working, 3. polish the policy system until we're happy with it.
16:31arora: Yes, this sounds like a good plan.
18:05kusma: what happened to the mesa CI? I keep getting lot of container-conflicts...
18:06karolherbst:wished we would see less marketing/PR driven emails on technical MLs
18:06kusma: for example: https://gitlab.freedesktop.org/kusma/mesa/-/jobs/2044650
18:16krh: karolherbst: seems pretty relevant and on topic for mesa-dev
18:16krh: in particular now that we have most technical discussion happening in MRs
18:16karolherbst: krh: I am not against the topic, I am against the wording/phrasing
18:16karolherbst: this comes out of marketing, not engineering
18:18krh: maybe it's just great news and it's hard to describe without sounding like marketing?
18:18karolherbst: I am also not gainst discussing non technical stuff, but if I feel like the emails sounds like marketing bs, I get annoyed
18:19karolherbst: krh: I highly doubt this
18:19karolherbst: even the good news part
18:19Venemo: kusma: I just read about the opengl/cl on dx12 announcement, congrats
18:19karolherbst: the actual interesting bits they don't even want to add to mesa, like the CL runtime
18:20kusma: Venemo: thanks :)
18:20ajax: one of the less marketese-y announcements i've seen tbh
18:20karolherbst: so.. this sounds like the annoying bits (keeping up with nir changes) are left to us
18:20karolherbst: and the juice bits thei keep for themselves
18:20karolherbst: soo.. waht's the deal here?
18:20Venemo: I'm wondering how much code is shared with zink, and would it be possible to also use the same infrastructure to run opencl on vulkan
18:20kusma: karolherbst: the OpenCL runtime will be open sourced.
18:20karolherbst: kusma: doesn't matter
18:21karolherbst: I'd like this runtime to be a gallium state tracker everybody could benefit from
18:21karolherbst: so why should only MS benefit from it?
18:21kusma: karolherbst: Well, that makes your comment about the juicy bits being kept to ourselves just... wrong?
18:21karolherbst: who will control the repo?
18:22karolherbst: us or MS?
18:22karolherbst: also, why isn't it a new state tracker targeting a d3d12 driver like zink
18:22kusma: karolherbst: I don't know. I don't even know if it will be upstreamed in mesa or not yet. But in either case, code can be forked.
18:22karolherbst: yeah... but then we have a forked situation
18:22karolherbst: I'd just rather see it inside mesa directly
18:22kusma: karolherbst: we *are* making that also.
18:23karolherbst: what bothers me a little is that inside MS announcement they speak about "Make it easier for developers to port their apps to D3D12."
18:23karolherbst: and I don't want to support this either
18:23karolherbst: I mean, don't get me wrong, it's good to see MS showing interest and such
18:24ajax: supporting it suggests you think it will, in fact, accomplish that goal
18:24karolherbst: I just see that a lot of educating needs to be done here
18:24karolherbst: and to push it in a form it actually benefits us as well
18:24ajax: that gl apps would somehow be more likely to want to port to dx12 just because mesa exists atop dx12/
18:24karolherbst: and not just MS
18:24ajax: which to me seems like it runs counter to how software works, which is that APIs never die
18:25ajax: so if anything having gl on d3d12 _ensures_ that app will not get ported to the lower layer, because why, it works already
18:25ajax: so... *shrug*
18:25kusma: karolherbst: by the way, I don't think anything will prevent people from using the d3d12 gallium driver with clover. All of the OpenCL-supporting bits go into the shared compiler + vtn.
18:25Venemo: kusma: I'm wondering how much code is shared with zink, and would it be possible to also use the same infrastructure to run opencl on vulkan?
18:25karolherbst: kusma: that's beside by point entirely
18:26kusma: Venemo: not much apart from general gallium/mesa code at the moment, but we hope to improve that.
18:27Venemo: if we could run opencl on vulkan, that'd mean we could actually drop clover eventually
18:27kusma: Venemo: Yeeeah, so CL on Vulkan is about the same complexity as CL on DX12, which means... surprisingly hard :-P
18:27krh: lol, src/microsoft
18:27kusma: Venemo: It should be possible, but it might take a lot of work.
18:28kusma: krh: that's where you find the shared compiler
18:28Venemo: kusma: I'm not familiar enough with CL so I can't judge that. I'm just curious about the possibility, because there are lots of people complaining about half-baked opencl implementations on amd cards
18:28kusma: Venemo: I sadly suspect that CL on Vulkan would also end up kinda half-baked unless a lot of time was invested in it :-?
18:28karolherbst: I doubt that CL can be implemented on VK
18:29karolherbst: google tried and there is still a ton of bs CL requires
18:29karolherbst: CL 1.2 maybe, CL 2.0 no way
18:29kusma: Yeah, but CL 2.0 is, uh. Not a thing.
18:29krh: kusma: yeah, I had a quick look... the path maybe do a double-take though
18:30krh: s/maybe/made me/
18:30karolherbst: kusma: because nvidia is the only one not implementing it?
18:30Venemo: kusma: hehe, yeah
18:30kusma: karolherbst: Because it's something nobody wanted.
18:31karolherbst: yeah.. maybe
18:31kusma: Well, apart from Apple.
18:31karolherbst: now do you mean CL 2.0 or CL in general?
18:31kusma: karolherbst: Well, CL up to 1.2 was somewhat defensible, but you're not wrong.
18:32kusma: People *did* want an industry-standard compute-API, but the way CL was made was not the right way.
18:32karolherbst: anyway, I am not against anything technical here, just that I dislike the way how things are done
18:32karolherbst: and yes, I agree in regards to CL being not the best thing
18:33karolherbst: and I know that educating companies on how to be a good upstream citizen and doing things the proper and good way can be tiring and exhausting
18:33karolherbst: nonetheless I don't see why MS should be treated differently
18:33karolherbst: if it looks like something only benefiting MS in the end, I am completly against it
18:33karolherbst: they can keep their fork in sync themselves
18:34kusma: karolherbst: I still fail to see what your big worry is.
18:34karolherbst: that we do work for them without getting anything out of it
18:34karolherbst: like porting their code to nir changes
18:35kusma: You don't like it because Microsoft might benefit from it? One could for sure say that about any other corporate contributors to Mesa?
18:35kusma: karolherbst: Uhm, what are you talking about now?
18:35karolherbst: well, if we do changes in nir, we have to update code making use of it, so that's just more work for us
18:36kusma: karolherbst: But that goes for all drivers, not just this one?
18:36karolherbst: also, for the other drivers there are usually users actually benefiting from them or are interested in contributing etc...
18:36kusma: karolherbst: are you saying people won't benefit from this?
18:37karolherbst: well, here is the difference: for the drivers we have, we also see a lot of contributions to core parts of mesa, etc...
18:37karolherbst: with MS I don't see it
18:37karolherbst: juicy bits are already left out like the CL runtime
18:37karolherbst: it should be a proper state tracker
18:37karolherbst: so why is that not the case?
18:38kusma: karolherbst: sounds to me like you're making a lot of assumptions without much data.
18:38karolherbst: again, why is the CL runtime not a state tracker?
18:39karolherbst: if that would have been a state tracker, we all benefit from it
18:39kusma: karolherbst: because it predates microsoft's interest in mesa.
18:39karolherbst: okay, do you think they would be willing to port it over to be one?
18:39kusma: or even knowledge about mesa and opencl support
18:39kusma: karolherbst: might be, yes.
18:40karolherbst: okay, if it turns out that way, I'd say they showed enough evidence to try to be a good citizen so to speak
18:40kusma: also, that runtime is a lot less code than you' assume, it's *very* d3d12-centric
18:40karolherbst: I can imagine
18:40kusma: "you'" -> "you'd"
18:41karolherbst: anyway, if I continue with my CL work I will be probably affected by all of that as well and will probably also either see how that helps with clover or not
18:41kusma: TBH, I would kinda love it if clover + the d3d12 driver became viable also
18:41karolherbst: it seems like missing CL stuff was also rather implemented in their compiler
18:41karolherbst: and not vtn
18:41karolherbst: or at least it sounds like it from the email
18:41kusma: karolherbst: No, it's in vtn
18:42karolherbst: okay, then it's a mistake in the email
18:42karolherbst: or I can't read
18:42karolherbst: either way
18:42karolherbst: ahh yeah, this is my mistake
18:45karolherbst: anyway, I am not a big fan of clover myself, so a nice replacement would be a big help
18:46kusma: karolherbst: I agree.
18:47kusma: karolherbst: I'll start upstreaming some vtn-patches tomorrow, hopefully that'll put things in a bit of a better light.
18:47karolherbst: yeah, probably
18:48karolherbst: this will take quite some time anyway, so let's see how it turns out in the end
18:48karolherbst: kusma: do you know when the code got branched out of mesa?
18:49kusma: karolherbst: a while ago, but we rebased last week, so it's pretty up to date.
18:50karolherbst: kusma: another thing as this is probably super required here as well: how to deal with unstructured spirv?
18:50kusma: (but the rebase is a bit nasty, so we could keep merging a cross... looks like a lot of patches, but it's not too bad.
18:51kusma: karolherbst: yeah, we're using the patches from Julian Winkler
18:51karolherbst: ahh, okay
18:51kusma: (on top of yours)
18:51kusma: They seem to work really well for us.
18:51karolherbst: here as well
18:52kusma: So we definately want to try to help getting these upstream :)
18:52karolherbst: I guess you ignored this issue for a long time as well :p
18:52kusma: karolherbst: kinda, yeah.
18:53karolherbst: which makes me feel less bad about ignoring it as well
18:53kusma: Hehe, yeah :)
18:53karolherbst: kusma: btw, I have a patch to implement OpSwitch support
18:54kusma: karolherbst: cool! :)
18:54karolherbst: it's not the best, but it does seem to work
18:55karolherbst: didn't give it a proper testing though besides running the OCL CTS
18:55kusma: karolherbst: not the best is my kinda code! ;)
18:55airlied: OpencL 3.0 will solve all problems :-P
18:55karolherbst: anyway, it should apply cleanly on top of the patches
18:55karolherbst: so if you want to give it a shot feel free
18:55kusma: karolherbst: cool, I just might!
18:55karolherbst: I might also have random vtn stuff here: https://gitlab.freedesktop.org/karolherbst/mesa/-/commits/clover_support_hmm_wip/
18:55karolherbst: but not so much these days
18:55kusma: ooh, images :)
18:56karolherbst: that's what I am kind of focusing right now
18:56kusma: We're not doing those for now, but we might have to eventually.
18:56karolherbst: heh :D
18:56karolherbst: you are procrastinating the same things I do :p
18:56kusma: There's... real-world applications waiting for this stuff to ship.
18:57kusma: So we'll have to see a bit what those particular applications depend on.
18:57karolherbst: I see
18:57karolherbst: well.. I might get images stuff to work.. I am sure the vtn bits are done
18:57karolherbst: just some weird runtime issues
18:57karolherbst: like clover doing x*yx1 blits :7
18:57karolherbst: * :/
18:58karolherbst: wait.. the code is somewhere
18:59karolherbst: mhh.. but it's kind of like this: clover creates a transfer mapping flattened out
18:59karolherbst: so if the applications wants to upload 256x256 pixels to an image
18:59karolherbst: clover flattens it
19:00airlied: it's pretty much vulkan buffer->image transfer
19:01karolherbst: yeah.. I think it might be actually a nouveau limitation
19:02karolherbst: transfer_map but with y and z set to 1
19:03karolherbst: that code is just a bit painful to follow :/
19:04karolherbst: kusma: anyway... on llvmpipe this code worked afaik.... so I might start to create MR for some of the vtn bits there as well
19:05karolherbst: I just don't understand why clover would flatten that out
19:05karolherbst: but maybe... we can just configure our hw to deal with that
19:05karolherbst: just need to figure out how
19:05airlied: it shouldn't matter to fix it
19:05airlied: since I don't think images really work on r600 either
19:06karolherbst: but it fails different probably
19:06airlied: I suspect in fixing it you will work out why :-P
19:06karolherbst: don't have r600 hw :p
19:06karolherbst: but yeah...
19:06karolherbst: the code is just a bit annoying to fix
19:07airlied: no I mean you'll figure out why clover does it irrespective of r600
19:07airlied: there is no r600 hw reason for doing it
19:07airlied: it's more likely a CL api reason
19:07karolherbst: it's not
19:07karolherbst: clover flattens is, not the API
19:09karolherbst: I also don't see why we need to do the copy in software either
19:10karolherbst: llike.. it uses a staging buffer
19:11karolherbst: sure.. the client can provide their own row and column pitch and everything, but then the code needs to deal with it differently anyway
19:11karolherbst: kind of seems wasteful to do the copy in sw if the client just wants to update 256x256 pixels without any special pitch
19:12airlied: karolherbst: I expect the answer isn't as simple as you think it will be, but hey anything that works is good
19:12airlied: the clover API talks in terms of image/buffer transfers
19:12airlied: which to me implies the buffer has no structure
19:13karolherbst: well.. images have always a size in CL and dimensionality
19:14karolherbst: and for buffers there is no problem
19:15airlied: also earlier ppl were talking about CL on VK, yes it will forever remain a toy bridge
19:17imirkin: karolherbst: probably at some point was the idea that images would just be raw resources
19:17imirkin: look at some of the commented out code around resource handling in nv50_ir_from_tgsi.cpp
19:18imirkin: however i don't think that works out in practice, and makes for unnecessary complications for drivers
19:22karolherbst: imirkin: anywaay, with nvc0 I hit nve4_m2mf_transfer_rect here
19:23karolherbst: with a ... 1d rect being super big
19:23karolherbst: no idea if we can configure m2mf differently to dal with a linear copy
19:23karolherbst: but it sounds like something the hw could do
19:23imirkin: don't think so
19:23karolherbst: but then again.. why do the sw memcpy in the first place for a 256x256 upload of data without an explicit pitch
19:24karolherbst: and use a staging buffer
19:25imirkin: staging buffer is almost always the way to go
19:25imirkin: for non-UMA systems
19:25imirkin: you can look at how PBO's are uploaded in st/mesa for example
19:26karolherbst: well.. clover does hw copy for other things
19:26karolherbst: if the API has no way to specify a pitch it uses a hw based copy
19:27karolherbst: otherwise sw+staging buffer
19:27karolherbst: mhh.. not even always
19:27karolherbst: it does feel a bit random to be honest
19:28karolherbst: ohh, hw copy only if you have two pipe resources
19:28karolherbst: and no pitch
19:36karolherbst: mhh, actually now I have an idea on how to fix it
19:47imirkin: right, can't do hw copy if it's nto from resource to resource
19:48imirkin: hence the staging texture that you copy into (and is cpu-side)
19:48karolherbst: yeah.. I understand this part
19:48karolherbst: the point is just that we could have some checks about the pitch the API hands in and do a sw or hw copy from resource to resource if it fits
19:48karolherbst: but yeah...
19:52mareko: that microsoft - collabora partnership is great news
20:11craftyguy: mareko: the TGL failures for vk cts in your CI build can be ignored
20:12craftyguy: we're trying to figure out what is causing those intermittent failures
20:12craftyguy: but it's unrelated to your branch. sorry for the noise. the other failures there look real
20:21mareko: craftyguy: do you mean the primitive restart failures?
20:22mareko: craftyguy: I'm mainly concerned about those
20:22craftyguy: mareko: those look like real failures
20:23craftyguy: ah, your latest build hasn't made it to the result site yet
20:23craftyguy: so you don't see the TGL failures I'm talking about. it should be up shortly