01:13 soreau: zmike: !25415
01:31 soreau: can anyone take a look at this MR when they have time? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25358 it makes it so vblank_mode and eglSwapInterval() works on zink
01:32 soreau: (on wayland)
01:34 soreau: it might need !24700 to make things work to test it though
02:16 zzoon: anholt: is there any way to get lava rootfs or create it myself? I guess it might be easy to setup since it's x86_64..
02:55 anholt: zzoon: open a job log, go to the "lava boot" section and expand it, and you'll find a URL where it downloads the rootfs
02:56 anholt: I took that, mounted proc,sys, and devtmpfs, copied my mesa build in, and chooted in to reproduce.
03:06 zzoon: Thanks! I'll try
05:09 _DOOM_: What does the link status value in drmModeConnector mean?
05:10 youresuicidal: Why they got all evicted from freenode was, that on #osdev and here you were very arrogant while being always wrong, and you violated with mental illness talks on top, and terrorising eastern people, osdev had aussie trash who laughed with their garbage while i was searching for 1bit alus, any productive comments were not made, but any bit width alus can be propagated with adder procedures, now the phase is that you can not stop
05:10 youresuicidal: the abuse against me on my own territory physical territory not IRC, and next obvious thing to do is take you to fields and execute you, not that you stalk me with mental illness talks, rob cash from me, and talk how a whore is my wife, you do not have such permissions. All together you are obnoxious trash.
05:15 _DOOM_: Did I interrupt something?
06:29 orowith2os[m]: _DOOM_: probably just a bot
06:30 orowith2os[m]: happens sometimes in other places too
06:50 _DOOM_: oh
06:52 soreau: _DOOM_: https://drmdb.emersion.fr/properties/3233857728/link-status
06:53 _DOOM_: thanks
10:48 harrystain: We know where to go, there is a public toilet called Big Easy on koh rong sanloem, which owner was the hero to assault me, similar to sara resort employer charl they disturbed the tourism on the island and claimed that i did it, and assaulted me and lied about me, similar to their estonian anchestors, owner is a british jew named jack who we pick up when we go there, and give him to treatment inside my team, physical
10:48 harrystain: assault behind back , there is no complication that guy is done.
10:48 harrystain: i am not putting up to your assaults alike at all anymore
10:48 harrystain: you get abused back
10:49 harrystain: 1week later the orderers were captured and treated, i am not sure who assaulted in case they lied about it, i must make a request
10:50 harrystain: to confirm that it really was the owner of Big Easy
11:10 alyssa: mattst88: what happened to the agreement? :p
11:16 ccr: :D
11:27 pinchartl: alyssa: what was the agreement ? :-)
11:46 linkmauve: pinchartl, if mattst88 agreed to stop being a suicidal terrorist, the spammer would stop spamming.
11:47 pinchartl: I've clearly missed most of the drama
11:47 pinchartl:likes missing drama
11:49 pinchartl: but it's scary to think that we now have computers that pass the Turing tests, and humans who don't :-S
12:39 alyssa: pinchartl: https://xkcd.com/329/
12:52 karolherbst: zmike: btw, a similar crash to the sampler one from yesterday still lurks in the code somewhere. hit by `test_api kernel_arg_changes`, but I think this time it has to do with having no samplers, but a sampler view
12:55 zmike: karolherbst: what driver
12:55 karolherbst: lvp
12:56 karolherbst: the shader only uses txs, so that kinda makes sense
12:56 zmike: got it
12:59 zmike: hm there's still a sampler
13:00 karolherbst: maybe there was one before?
13:00 karolherbst: mhh, though that doesn't make snese
13:01 karolherbst: zmike: you mean a sampler or a sampler view
13:01 zmike: sampler
13:03 karolherbst: that's odd.. here I see zink_bind_sampler_states being called with num_samplers = 0
13:03 zmike: the shader is detecting a sampler
13:03 karolherbst: ohh
13:03 zmike: decl_var uniform INTERP_MODE_NONE readonly usampler2D #0 (0, 0, 0)
13:03 zmike: probably a factor
13:03 karolherbst: huh?
13:04 karolherbst: ohh.. that's probably something zink does when handling vtexture
13:04 zmike: I'm investigating
13:04 karolherbst: this is what rusticl passes to zink: "decl_var uniform INTERP_MODE_NONE readonly vtexture2D #0 (0, 0, 0)"
13:06 zmike: yes I'm past that
13:06 zmike: trying to multitask but it's hard today
13:07 zmike: hm
13:07 zmike: 🤔
13:12 zmike: I think this is a rusticl problem
13:12 zmike: you need to give me a sampler
13:12 karolherbst: why?
13:12 zmike: because it's a texop
13:12 zmike: so I need a sampler
13:12 karolherbst: it's txs, it doesn't need a sampler
13:12 karolherbst: it doesn't even reference one
13:13 karolherbst: `(uint32)txs %1 (0x0) (lod), 0 (texture)` it's literally this
13:13 zmike: yeah I see it
13:15 zmike: I wonder if I can do this...
13:35 zmike: karolherbst: try zmike/test HEAD
13:37 karolherbst: seems to work.. however I have a weirdo crash with enabled vvl
13:37 karolherbst: test_api: ../src/vulkan/runtime/vk_command_pool.c:164: vk_command_buffer_recycle_or_destroy: Assertion `pool == cmd_buffer->pool' failed.
13:37 karolherbst: no idea what's up with that
13:37 karolherbst: might also be something locally here
13:37 zmike: works fine here
13:38 karolherbst: yeah.. maybe me having an outdated loader or something
13:38 karolherbst: I didn't update everything
13:42 karolherbst: let's see what the CTS is saying
14:28 karolherbst: zmike: that patch seems to break txf
14:29 zmike: 🤕
14:29 karolherbst: though I think the solution here is simple...
14:30 karolherbst: yeah.. I can write a patch for that, looks trivial
14:31 zmike: I guess it probably needs the same casing in ntv as I did for txs
14:32 zmike: as do all the similar conditionals
14:32 karolherbst: yeah. something like that
14:39 karolherbst: it's the `spirv_builder_emit_image` when dealing with txf, because the image type is already without the sample part
14:40 zmike: yes, that's why I said changing the conditional to match the others would fix this
14:40 karolherbst: yep, doing that
14:48 karolherbst: mhhh.. now it's running into return type mismatches :'(
14:52 cheako: Is harrystain in #intel-3d a bot?
14:56 pq: cheako, probably just that person with mental illness that has been doing just that for a decade or more
14:57 pq: and now I'm getting PM from them because I said so
14:58 pq: time to update the ignore lists
15:35 austriancoder: What should I know about mediump in NIR? What do I need do use it correctly?
15:36 austriancoder: @alyssa: @gfxstrand: ^
15:40 alyssa: austriancoder: mediump doesn't really exist in NIR
15:41 alyssa: that's a GLSL concept handled almost entirely in the GLSL compiler (except one detail of conversions you can ignore)
15:42 alyssa: by the time your driver gets NIR, it's just a 32-bit op or a 16-bit op or whatever, just respect exactly the bit sizes in NIR and it'll work out
15:43 austriancoder: alyssa: thx
15:43 HdkR: and then eventually learn to ignore fp16 and operate everything as fp32 because of broken applications? :)
15:43 HdkR: Thus the circle of fp16 problems continues
15:43 alyssa: HdkR: the 5 stages of mediump grief
15:44 alyssa: "everything is 32-bit in my IR"
15:44 alyssa: "fuuuuuuuck i can't bolt on fp16 fuck"
15:44 alyssa: "maybe i can half ass it, and can still get some perf back, and it'll work out even tho it's a mess"
15:45 alyssa: "i spent 100s of hours on fp16 and despite shaderdb wins, zero apps improved their fps"
15:46 alyssa: "Hey, desktop apps are all fp32 anyway, and ALU is pretty cheap. It's all good!"
15:49 HdkR: :D
15:50 DavidHeidelberg: What about our lord and saviour LLM? There is lot of fp16
15:51 HdkR: Maybe we should drop FP16 entirely and switch to bfloat16 only. Paradigm shift everyone to avoid problems :P
15:51 alyssa: i dont know what i dislike more, fp16 or LLMs
15:51 karolherbst: mood
15:51 alyssa: LLMs cause far more harm but fp16 have caused so much harm to me personally :P
15:51 DavidHeidelberg: alyssa: just wait, maybe LLM catch up
15:52 alyssa: yeah I give it a year
15:52 karolherbst: I wonder if the solution to fp16 in rusticl will be: f2f16(clc_builtin(f2f32(clc_builting_srcs....))
15:53 karolherbst: so uhhhm... I'm very sorry about it, I got GPT-2 running on my M2 🙃
15:53 karolherbst: *but
15:55 alyssa: karolherbst: asahicl?
15:55 karolherbst: yeah
15:55 alyssa: cursed
15:55 karolherbst: very
15:55 karolherbst: it's faster than on iris tho
15:55 karolherbst: (which isn't hard tbh)
15:56 karolherbst: I asked it who Asahi Lina is, it answered: Asahi Lina is Asahi Lina. so I guess it's not as stupid afterall
16:09 karolherbst: zmike: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/f8e67aa67c312e5202c8d643681dcf6691ae434f
16:09 karolherbst: ehh
16:10 karolherbst: no, it's the right one
16:11 karolherbst: actually this: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/57fa9644432111ecb9bdb04bf213e1b7a15d2f2e
16:11 karolherbst: so the problem was just that the texture got typed through the txs in the shader, but never updated for the txf following that
16:11 karolherbst: txf expected float result, where with txs we got uint
16:12 zmike: 🤕
16:12 zmike: there are other cases of the first conditional that probably still need to be updated tho?
16:13 karolherbst: tbd, I'll run the CTS and see where remaining problems are
16:13 karolherbst: but it looks fine so far
16:14 zmike: for consistency it should be updated
16:14 karolherbst: fair enough
16:15 karolherbst: mhhh nir_texop_query_levels ... mhhh yeah, I guess I should update those as well as we'll run into them with more gl_sharing related extensions
16:16 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/480a91f34ee76340f607209de45d5d6c853bcf32
16:16 zmike: sgtm
16:28 cheako: For updating the drm, how essential is it to compile the whole kernel?
16:28 karolherbst: 40 -> 32 crashes, nice... let's see what the others are all about
16:30 karolherbst: ahh a crash within JIT code ...
16:31 karolherbst: might be a lvp only problem
16:31 karolherbst: anv and radv are more or less the same now
16:44 karolherbst: let's see if I can finally run stuff with radv
16:47 karolherbst: mhh.. still crashes the GPU
16:51 karolherbst: no validation errors at least..
16:53 APic: l
16:53 APic: Sorry
17:00 soreau: zmike: I was thinking I could run piglit without and with the patches applied but of course xwayland crashes without or no window shows up, so.. is there any way you can try it with your setup? or do you use piglit at all? (on xwayland?)
17:02 zmike: I use piglit, but I also use hardware with radv modifier support and an xserver with glamor
17:02 soreau: but I suppose it wouldn't show anything where there is EXT_image_drm_format_modifier because it's basically the same without the patch in that case..
17:02 soreau: zmike: I am using glamor
17:02 soreau: if this was without glamor, it would be basically meaningless
17:03 zmike: oh okay then you're just hitting the implicit modifier case anyway
17:03 zmike: which https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25299 will blow up unconditionally
17:03 zmike: so don't bother
17:03 soreau: don't bother with what?
17:03 zmike: trying to do what you're doing
17:03 soreau: :/
17:03 zmike: I told you this already
17:03 zmike: radv doesn't support modifiers on your hardware gen
17:04 zmike: you'd have better luck resolving the problem at that end
17:04 soreau: why does this MR talk about 'broken xservers'?
17:04 soreau: in what way are they broken exactly? (and can they be fixed?)
17:05 zmike: because if you don't have modifiers and are trying to use an xserver then your xserver is broken
17:05 soreau: ...
17:06 soreau: this doesn't seem to make much sense because xservers have worked fine on hw without modifier concept for many yeats
17:06 soreau: years*
17:06 zmike: it's a zink problem, not a hardware problem
17:06 zmike: but to resolve it in zink you either need to get a new vk extension which handles implicit modifiers (which would have to go through the system integration workgroup) or implement modifiers for your hw gen
17:07 soreau: ok, thanks.. where would modifier support have to be implemented?
17:07 zmike: cc bnieuwenhuizen ^
17:08 soreau: kernel, libdrm, mesa? all of the above?
17:08 bnieuwenhuizen: kernel & mesa
17:08 soreau: ok, thanks
17:09 bnieuwenhuizen: basically an uapi chunk in drm_fourcc.h IIRC, then amdgpu DC support in the kernel, and mesa support in src/amd/common/ac_surface.c
17:10 soreau: bnieuwenhuizen: sounds like a plan, thanks again
17:11 soreau: bnieuwenhuizen: any reason why it's not already done for i.e GFX8?
17:12 bnieuwenhuizen: I got more pushback with my modifier proposal for gfx6-gfx8 at the time and ChromeOS only really needed it for GFX9+ looking at the feature matrix at the time
17:15 soreau: bnieuwenhuizen: would you mind if I maybe tried picking up where you left off somehow?
17:17 bnieuwenhuizen: nope, go for it
17:19 soreau: bnieuwenhuizen: can you link me to your kernel patch(es)?
17:26 soreau: is it https://patchwork.kernel.org/project/dri-devel/patch/20180904010033.67611-1-bas@basnieuwenhuizen.nl/ ?
17:28 bnieuwenhuizen: think so
19:42 DemiMarie: Can Mesa be told to use a GPU for rendering, but copy the resulting image back to the CPU for use with a display server that doesn’t implement any of the direct rendering APIs?
19:42 karolherbst: gbm?
19:43 karolherbst: the CTS and piglit e.g. use gbm if you don't want to have any display server running and just do headless testing
19:43 DemiMarie: not really
19:43 DemiMarie: I’m thinking of e.g. a Wayland compositor that only implements wl_shm.
19:44 karolherbst: well.. you need an API to allocate GPU memory for scanout
19:44 karolherbst: or rather you need a buffer to render into
19:44 DemiMarie: in my use-case, scanout is done by copying the memory back to the CPU, where it will likely be copied again one or two times before being finally sent back to the GPU for display
19:45 karolherbst: yeah.. use gbm for that
19:45 DemiMarie: gbm?
19:45 karolherbst: it's a mesa API
19:45 karolherbst: nvidia supports it as well recently
19:46 DemiMarie: Is there a way (perhaps via an environment variable) to tell Mesa to do that when an application uses EGL?
19:46 karolherbst: no? It's an API
19:47 karolherbst: however you can use gbm memory for EGL through `EGL_MESA_platform_gbm`
19:47 karolherbst: but anyway, this needs code
19:47 DemiMarie: Would an MR adding this to Mesa be accepted?
19:47 karolherbst: it doesn't make sense
19:47 karolherbst: it's an API for clients to allocate a surfaces
19:47 karolherbst: like you'd do with wayland or X11
19:47 karolherbst: just instead of a window or something, it's a raw buffer
19:47 DemiMarie: I mean for Mesa to use GBM internally, then do the GPU → CPU copy itself
19:48 karolherbst: gbm is an API mesa provides
19:48 karolherbst: you need to provide the GL impl some buffer to render into
19:48 karolherbst: one way or the other
19:49 karolherbst: instead of Wayland/X11 stuff, you'd use gbm
19:49 DemiMarie: The broader context is that I want to be able to test GPU acceleration in virtualized contexts without having to wait for cross-VM buffer sharing to be implemented, which will likely take longer
19:49 karolherbst: yes
19:49 karolherbst: use gbm
19:50 DemiMarie: I get that
19:50 karolherbst: but it can't magically know where to store the result
19:50 DemiMarie: And I am saying that I want to be able to test this on real-world applications, which won’t use GBM themselves
19:50 karolherbst: so it's up to the application to do it
19:50 DemiMarie: wl_shm?
19:50 DemiMarie: the display server exists, it just only supports CPU-side shared memory
19:50 DemiMarie: this isn’t a headless situation
19:50 karolherbst: ahh
19:51 karolherbst: the thing is, it doesn't work on all GPUs
19:51 DemiMarie: why?
19:51 karolherbst: CPU side memory is generally linear, and not all GPUs can render to linear memory
19:51 DemiMarie: And nobody has implemented CPU-side unswizzling?
19:52 karolherbst: e.g. nvidia GPUs can't do it if you have a depth buffer attached
19:52 DemiMarie: In my case only Intel and AMD matter
19:52 karolherbst: GPUs can't render tiled to host memory
19:52 karolherbst: afaik
19:52 DemiMarie: render to temporary GPU buffer, then copy
19:52 karolherbst: well.. then you need application changes
19:52 DemiMarie: why?
19:52 karolherbst: though I guess prime offloading also kinda works like that...
19:53 karolherbst: just more cursed
19:53 DemiMarie: “not yet implemented” is a valid answer, but I don’t see a reason it couldn’t work
19:53 karolherbst: well.. in the end you can provide any kinda of buffer which is accepted through EGL/GLX
19:53 karolherbst: and platform specific extensions
19:54 DemiMarie: would I be better off having the display server (which I control) do the copy?
19:54 karolherbst: probably, once you leave EGL/GLX/GL or whatever vulkan provides it's not really a concern of mesa anymore what happens with the rendered output
19:56 DemiMarie: The other part is that this is all blocked on virtio-GPU native context support for Intel, AMD, and Xen landing
20:07 Kayden: sounds a lot like prime
20:07 Kayden: there's code in src/loader for doing blits on the rendering GPU to a linear buffer for handing off to another device
20:12 karolherbst: right.. but I think we added that code to workaround shortcommings of GLX/EGL at that time :')
20:14 karolherbst: but yeah.. compositors should just allocate GPU memory for a specific device and do whatever they want with it afterwards
23:21 kode54: hey
23:22 kode54: would this be a DXVK failure
23:22 kode54: there's a shader that DXVK produces that has Vec2 input and Vec4 output
23:22 kode54: and validation layers complains about this
23:22 kode54: that exact frame of the render commands causes xe.ko to crash the GuC
23:37 DemiMarie: kode54: no, this is a xe.ko bug
23:38 kode54: gotcha
23:38 DemiMarie: Even malicious userspace should not be able to crash the kernel or GuC
23:38 kode54: wish the vm logging worked so I could produce logs of what is crashing it
23:38 DemiMarie: (okay, there are a few exceptions, but all of them require root privileges and none apply here)
23:39 DemiMarie: DXVK making invalid Vulkan API calls is a bug in DXVK unless the DirectX API calls also had undefined behavior. However, the kernel is not allowed to crash the GuC, and that is a potential security problem so fixing it should take priority.
23:58 soreau: what might a vulkan extension look like that zmike refers to here? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25299
23:59 soreau: it seems like this would support more cases than making modifier support for a single gen of hw and possibly be easier to implement