01:20 buhman: I am trying to manipulate R500 registers/memory directly. I observed that D1GRPH_PRIMARY_SURFACE_ADDRESS is currently set to e0100000, and I also see the un-remapped pci resource 0 base address is e0000000. I assumed I could then simply write to 0x100000 relative to the ioremap'ed base address.
01:21 buhman: However, I get `vmalloc_node_range for size 268439552 failed: Address range restricted to 0xf6bfe000 - 0xfe3fe000` `BUG: unable to handle page fault for address: 00100000` when I try to do this. I'm a bit of a Radeon novice. What's the correct way to write to texture/framebuffer memory from kernel space?
03:06 buhman: (ah, I see VmallocTotal is tiny on x86-32)
09:18 mlankhorst: tzimmermann, mripard: It's time for me to do drm-misc-next again?
09:19 tzimmermann: i think so. i switch to drm-misc-fixes after -rc1
11:22 mripard: mlankhorst: yep
12:28 tzimmermann: PSA: With the merge window open, drm-misc-next-fixes is now closed again. After -rc1 has been released, relevant fixes go into drm-misc-fixes. Patches in -fixes branches should be small and have a Fixes tag. New features always go into drm-misc-next.
13:37 glehmann: we kind of need a disjointed ior in nir because llvm (and by extension dxil) likes to generate these for address calculation
13:39 glehmann: ofc dxil also completely throws away the disjoint flag, so we have to reconstruct it with some known zero/one bit analysis
13:47 anonymix007[m]: Are there any known issues with Vulkan video decoding on Intel? Memory usage seems to go from 25 MiB to ~256 MiB in 10 minutes or so and continues to grow at about the same rate for longer videos.
13:47 anonymix007[m]: I'm not seeing the same issue on AMD (well, except that resizing the window also causes memory usage to grow just like on Windows, though maybe it's SDL to blame here?), so this doesn't seem to be the application fault.
14:27 pq: OpenGL in the worst case: is there performance difference between sampling an RGB(A) texture and using only one channel value per sample vs. sampling a single-channel texture? The texture storage size is the same in both cases.
14:37 Company: pq: I would expect that to depend on the hardware
14:44 pq: I'm asking if someone actually has experience. I would expect the single-channel texture to be always better, because it only transfer one value at a time. But if the cost of texture access masks any cost of fetching and interpolating 3 unused values... nah, unlikely to be something to assume.
14:47 llyyr: anonymix007[m]: what client are you using to test that? i can't reproduce either issue on radv/anv on mpv
14:57 Company: pq: only thing I know is that RGB is worse and you should avoid it if possible
14:58 Company: RGBx is much preferred
14:59 pq: oh, my texture data is GL_FLOAT
15:03 Company: i would still expect it to hold that RGB is worse than everything else, but I don't know for float
15:06 pq: I expect all kinds of things, but I ask because it would be nice to *know*.
15:29 anonymix007[m]: llyyr: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/tests/examples/vulkan/sdl3_vulkandec.c?ref_type=heads
15:31 dwfreed: pq: speed test it in a tight loop?
16:54 ngcortes: zmike I noticed that bmg_g31 pci_ids don't seem to be recognized by the zink driver on mesa main yet. is that currently in the works?
16:55 Sachiel: zink has nothing to do with that
16:55 Sachiel: it's anv that has to recognize them
16:55 zmike: ^this
17:37 ngcortes: Sachiel zmike ack
18:30 DemiMarie: Is it safe to limit client-provided buffers to 8192x8192? I want to ensure that size calculations in drivers don't overflow.
18:31 Sachiel: vulkan supports 16384x16384
18:34 DemiMarie: Is that tested in CTS?
18:34 DemiMarie: And by the OpenGL CTS?
18:34 DemiMarie: For all possible format modifiers
18:34 Sachiel: I don't know what the limits are for opengl, but Vulkan 1.4 requires 16384x16384, yes
18:34 DemiMarie: What about 1.3 and below?
18:35 DemiMarie: The compositor I am going to be using (cosmic-comp) uses OpenGL, unfortunately.
18:35 Sachiel: before 1.4, the requirement was 8192x8192, but the driver can support larger and it's legal to do so
18:35 DemiMarie: I'll stick to 8192x8192 then
18:35 DemiMarie: In my use-case, if the driver gets it wrong it is a security vulnerability.
18:36 Sachiel: the driver does not query what the compositor says the limit is
18:36 karolherbst: yeah, but you can make that argument for many things]
18:37 DemiMarie: karolherbst: that is true, but I also have no way of validating this
18:37 Sachiel: the driver says "for this HW, the max framebuffer size is this" and the app can do whatever
18:37 karolherbst: why limit to 32 bit then? drivers can overflow 8 bit as well, so might as well restrict all limits to 8 bit just to be extra safe
18:37 DemiMarie: karolherbst: because drivers aren't likely to have that bug, and it would have been caught by testing
18:37 DemiMarie: whereas nobody is likely to use 16384x16384 images (yet)
18:37 karolherbst: the CTS does
18:38 DemiMarie: Does it check that for all possible format modifiers?
18:38 DemiMarie: And all hardware versions?
18:38 karolherbst: if that's a concern I think it would be better to add tests to the CTS rather than constrain yourself arbitrarily
18:39 DemiMarie:That's definitely a good idea, once there is time :)
18:42 HdkR: I need that 16k framebuffer size for all my 4k monitors :D
18:44 dwfreed: my 3 4k monitors side by side exceed 8192 wide as is
18:50 DemiMarie: Ack
18:51 DemiMarie: Are there any accesses by a compositor to client-provided buffers that are not SPIR-V loads or stores?
19:49 karolherbst: There is an API to map client memory into the GPU and drivers are adding page table entries on the GPU side to access that memory