05:49 DemiMarie: Do graphics APIs expose CPU pointers to not-fully-cacheable memory?
05:49 DemiMarie: I don’t care about KMS or dumb buffers here.
05:49 DemiMarie: Just OpenGL and Vulkan.
05:52 airlied: not-full-cacheable isn't really a defined memory type
05:52 airlied: but yes you can map vram into cpu address space with vulkan
05:59 DemiMarie: So hypervisors normally force all guest memory to write back.
05:59 DemiMarie: The settings set by the guest are ignored.
06:00 DemiMarie: Will that break things?
06:00 DemiMarie: If so, there is a problem.
06:00 DemiMarie: The secure way to do this is to trap and emulate every single access, which would be hilariously slow.
06:07 airlied: making pci bars write back will probably not end well
06:07 DemiMarie: Why does userspace need access to those?
06:10 DemiMarie: airlied: Are those BARs VRAM only, or do they also include MMIO?
06:11 airlied: userspace accesses VRAM because it wants to write stuff into VRAM
06:11 airlied: I think we also expose WC mappings of RAM regions
06:12 airlied: not sure what you mean by MMIO there, you mean device registers or something?
06:12 airlied: those normally aren't exposed to userspace, but they are just another PCI BAR, and they generally are uncached
06:18 DemiMarie: MMIO = anything that doesn’t act like RAM, like device registers.
06:23 airlied: yeah we don't tend to map MMIO into guests
06:24 DemiMarie: Because it causes problems?
06:25 airlied: just don't need to usually
06:25 airlied: unless you are doing full device passthrough
06:25 airlied: actually maybe SRIOV does some of that
06:25 DemiMarie: I see
06:26 DemiMarie: Anyway, good night!
06:48 zzoon[m]: airlied: just out of curiosity, th av1 branch for anv works with p frames on DG2?
06:48 zzoon[m]: I mean it passes only i frame cts test. want to be sure if there's something wrong on my side.
06:49 zzoon[m]: Mine is alderlake.
06:51 airlied: zzoon[m]: nope, it only decodes one I frame
06:52 airlied: couldn't get P frames properly, I suspected something cdf related
06:52 zzoon[m]: yup. that's what im working on. thanks.
08:23 MrCooper: airlied DemiMarie: indeed, GPU drivers also use write-combined mappings of system RAM for performance; if the hypervisor forces those to be cacheable, but the GPU doesn't snoop the CPU cache, that probably won't end well either
08:54 pq: grillo_0, jfalempe, tzimmermann, I wonder if it would be possible to combine VKMS and DRM core pixel conversion machinery into a single thing? Core does conversions, VKMS does conversions and blending. Does core need direct format-to-format functions, or could it use format-to-common + common-to-format pair acting line by line?
08:55 tzimmermann: pq, maybe
08:56 tzimmermann: but the panic-handler discussion shows that it's not so easy.
08:56 tzimmermann: we're basically discussing a full drawing API
08:56 tzimmermann: there's also older code in fbdev, which does similar tasks
08:57 pq: I'd think a drawing API would be built on top.
08:57 emersion: core needs format conversion for XRGB8888 → format supported by hw, in some cases
08:58 pq: essentially, pixman architecture, but without the hand-written arch/extension specific asm.
08:58 tzimmermann: what else would be there? with the conversion and blending in place, the rest of the drawing api feels like bells-and-whistles to me
08:59 pq: I don't know if a drawing API is needed, I just assumed it was.
09:00 tzimmermann: maybe not a full one, but the basics
09:00 tzimmermann: the panic handler draws fonts (via blit code) and has a fill operation for rectangles
09:00 pq: ok
09:01 tzimmermann: the fbdv code also has a copy operation
09:01 tzimmermann: i guess those are the necessary primitives
09:01 pq: that doesn't sound bad, what else was suggested?
09:01 tzimmermann: we don't have blending so far
09:02 pq: VKMS needs blending
09:02 tzimmermann: i guess that complicates matters
09:02 pq: well, it already has it
09:03 pq: VKMS also has format-to/from-common pixel conversion routines, that make feel they should be used elsewhere too.
09:03 tzimmermann: for some time, i've wondered if we should attempt to build something subsystem neutral. so that we don't reinvent the wheel each time (as we do now)
09:03 pq: but, because VKMS needs to do blending, the pixel format conversion routines need to convert to/from a high depth common format
09:04 tzimmermann: pq, can it handle pixels with less than 8 bits?
09:04 pq: yes, people are writing that right now
09:04 tzimmermann: i see
09:05 tzimmermann: in the format helpers, we use per-line conversion routines. so it doesn't read the same bytes multiple times
09:06 pq: VKMS is going back to line-by-line to gain the performance it had a year ago with line-by-line
09:06 pq: it was "simplified" to work pixel-by-pixel in the mean time
09:07 pq: the work is being done by Louis Chauvet and Arthur Grillo, along with IGT performance benchmarks
09:08 tzimmermann: ok, sounds interesting
09:08 pq: patches are on dri-devel and igt lists
09:08 jfalempe: yes, I've seen the YUV support, which I might be interested in for drm_panic.
09:10 jfalempe: But it's hard to find a good compromise between performance, complexity and sharing the code between different usage.
09:10 tzimmermann: in the format helpers, it's line-by-line. the overall clip-and-copy loop is format agnostic. in some cases, the per-line helpers could be created via from_foramt() and to_format() helpers. but there's little benefit to do so ATM
09:11 pq: using the VKMS pixel coversion architecture does not exclude the possibility of having direct format-to-format functions either, if performance demands, maybe per-pixel inlined helper functions could still be shared
09:12 pq: all I can say is, please have a look, maybe there could be something to share
09:13 tzimmermann: sure. as i said, i think we should eventually try to build something subsystem agnostic (drivers/video/) to that we don't have to reinvent the wheel each time
16:44 zmike: DavidHeidelberg: did you see my ping on the piglit uprev
18:26 demarchi: is it possible to use the container igt is using to reproduce build failures?
18:26 demarchi: I can't reproduce this locally: https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/pipelines/1119462
19:31 demarchi: nvm, found it
19:47 DavidHeidelberg: zmike: no, but the pain invoked on your side regarding to not having latest piglit reached me telepathically :D the piglit is upreved