01:43luc: Hi, I found the GL api glGetInternalformativ is not always in libGL.so.1.y.0, where y equals 2, 5 or 7
01:45luc: I could found the symbol only in libGL.so.1.7.0 which is exactly my ubuntu 20.04 system shipped GL library. http://ix.io/4vQJ
01:49kurufu: Are there working vulkan video sample apps out yet? I could only find https://github.com/nvpro-samples/vk_video_samples which throws a screen full of validation errors and crashes...
01:50luc: i am confused how this comes? I've grepped in mesa code base, it appears impossible to build libGL.so.1.7.0 from the original mesa code base.
01:52linkmauve: kurufu, Lynne has a ffmpeg branch somewhere.
02:47kurufu: I guess its even worse when the validation layer is the one segfaulting...
05:45orowith2os: Test?
05:46orowith2os: Hey it works!
05:47orowith2os: Just gonna watch from over here to keep an eye on what's goin on :p
06:53hakzsam: cwabbott: turnip has the same bug https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23009
08:58mlankhorst: mripard: derp, wanted to wait for rc2. :-)
11:51javierm: sima, rodrigovivi: I found a bug in dim but not sure how to fix it. Problem is `git show --pretty=email` respects .mailmap and so checkpatch complains that author != S-o-B even when that's not the case
11:52javierm: that is, the author and S-o-B does match in the commit but git show doesn't show the real email address as author and instead shows that's in .mailmap
11:53javierm: sima, rodrigovivi: I'm reading the git-show man page but I don't see how to make --pretty=email to ignore .mailmap. One option is to use our own --pretty=tformat:<format> with %ae instead of %aE
11:54javierm: another option is just to ask the author to re-send the patch. But this is a problem if you want to land old patches if the author added an entry to .mailmap in the meantime, so worth to fix I believe
12:04javierm: hmm, it seems that I can still push the branch so I'll just ignore the warning, the commit is correct anyways
12:27rodrigovivi: javierm: but I don't believe anyone would have a mailmap entry that's not for the person-self... right?! anyway, it might be worth if we have a more reliable way to get that, a patch to dim shouldn't hurt
12:29javierm: rodrigovivi: yeah, the case here was a patch that was in the ML for some time, the author asked for it to be merged and when I tried their author email was overriden by a mail map entry so dim got confused
12:30javierm: rodrigovivi: and yes, I'll try to type a patch for dim later to ignore mailmap in the git show output since we want to compare the actual patch, not some overriden fields
12:31rodrigovivi: why do you have a mailmap entry that's not yourself?
12:33javierm: rodrigovivi: not sure I understand the question. People also use mailmap to prevent get_maintainer.pl --git-fallback to list email address that no longer exist
12:33tursulin: sometimes it is just old-vs-new email address
12:33javierm: yeah, what tursulin said
12:34tursulin: we hit this a few times already over the years
12:35tursulin: I *think* jani was the last person who brain stormed how to "fix" this but I can't remember the conclusion.. sorry for the ping jani if I am misremembering things here
12:49jfalempe: I switched mgag200 driver to use DRM_GEM_DMA_DRIVER_OPS, so that I can use DMA to directly send the framebuffer to the VRAM.
12:49jfalempe: But there is a limitation on x86_64, if the framebuffer is > 4MB, the dma allocation fails, and it breaks the driver.
12:50jfalempe: his limits the resolution to 1024x768 (3MB) because 1280x1024 (5MB) fails.
12:50jfalempe: Is there a way to workaround this ?
12:53DemiMarie: <kisak> "to do what now? A cpu based..." <- OpenH264 should have hardware acceleration.
13:04karolherbst: even on the cpu is kinda hardware accelerated because without SIMD ops it's also slow :P
13:06alyssa: gerddie: Will you have time to convert r600/sfn to unified atomics this week or should I go ahead and write the patch?
13:08alyssa:writes it I guess
13:10robmur01: jfalempe: check if CONFIG_CMA and CONFIG_DMA_CMA are enabled - sounds like they probably aren't
13:10robmur01: (or turn the IOMMU on if you have one)
13:11jfalempe: I do have CONFIG_CMA=y and CONFIG_DMA_CMA=y
13:11robmur01: hmm, 4MB sounds suspiciously like the limit of a regular MAX_ORDER page allocation
13:12robmur01: CMA should be allowing you to go bigger
13:13jfalempe: for iommu, it looks like it's not enabled.
13:14jani: javierm: rodrigovivi: tursulin: https://paste.debian.net/1280272/ should do the trick
13:14robmur01: can you see what path it takes from dma_alloc_attrs()?
13:16jfalempe: robmur01, I can add printk to see what happens there.
13:17javierm: jani: oh! that option isn't mentioned in neither the git-show(1) nor git show --help
13:17javierm: an easter egg :P
13:28alyssa: gerddie: yeah, if you could test + review + merge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23026 I would be very appreciative :~)
13:28alyssa: thank you!
13:28jani: javierm: found it in git-config man page :)
13:28jfalempe: robmur01, even with intel_immu=on, the allocation fails. Will add printk in dma_alloc_attrs() to see where it fails
13:34alyssa: jenatali: failing that, I suppose you would review !23026 too :P
13:52jfalempe: robmur01, it fails in dma_direct_alloc() https://elixir.bootlin.com/linux/v6.3/source/kernel/dma/mapping.c#L516
13:57robmur01: jfalempe: hmm, weird, in that case it should be going dma_direct_alloc() -> __dma_direct_alloc_pages() -> dma_alloc_contiguous() and hitting CMA
14:02jenatali: alyssa: I'm pretty impressed at how fast you've managed to convert the whole tree
14:02jenatali: Feel free to ping me for frontend reviews when you get there
14:03jenatali: alyssa: Btw any more comments on !22879?
14:04alyssa: jenatali: thanks, it turns out being out of school and giving me free reign to make mesa better has consequences :P
14:05alyssa: jenatali: certainly ack.. IDK if I'm confident in giving an r-b here
14:08zamundaaa[m]: How is Colorspace and HDR metadata handled with eDP displays?
14:11zamundaaa[m]: With a integrated display that supports HDR on an Intel laptop (at least the EDID says so), the HDR_OUTPUT_METADATA property is missing entirely
14:11pq: wish I knew - I'd assume they're not :-)
14:12pq: hwentlan_ or vsyrjala might have a clue?
14:12zamundaaa[m]: That is what I assume too. Setting the Colorspace property doesn't seem to do anything; sending data encoded as BT.2020 just makes everything horrible
14:13pq: does the backlight go up to ouch brightness?
14:16jfalempe: robmur01, actually __dma_direct_alloc_pages() returns NULL.
14:21jenatali: alyssa: Fair enough. Honestly an ack is probably fine for me to land it, if there's problems after the fact we can just fix 'em. I don't want to just let it languish forever
14:21zamundaaa[m]: pq: wdym?
14:29robmur01: jfalempe: right, which implies that either dma_alloc_contiguous() or the subsequent dma_coherent_ok() check failed unexpectedly
14:30alyssa: jenatali: I'm ok with that
14:30alyssa: 17 files changed, 17 insertions(+), 1014 deletions(-)
14:30alyssa:flexes
14:36javierm: jani: ah! nice found
15:06jenatali: alyssa: O.o what's that?
15:07jfalempe: robmur01, dma_alloc_contiguous() returns NULL, and alloc_pages_node() returns NULL too. https://elixir.bootlin.com/linux/v6.3/source/kernel/dma/direct.c#L141
15:07pq: zamundaaa[m], I mean does the screen brightness go up enough to facilitate HDR display, or is something keeping it low?
15:11robmur01: jfalempe: OK, alloc_pages() failing for >4MB is expected behaviour (for typical default values of MAX_ORDER), so the question to dig into is why CMA isn't working
15:12zamundaaa[m]: pq: the display is limited to 400 nits
15:12zamundaaa[m]: That's the maximum according to the EDID
15:12jfalempe: robmur01, what should be the path in dma_alloc_attrs() when CMA is working ?
15:13robmur01: dma_alloc_contiguous() would return your buffer
15:14jfalempe: robmur01, thanks, I will add more printk to see why it fails.
15:15alyssa: jenatali: Removing legacy atomics from core
15:15alyssa: actually doesnt compile yet, still deleting
15:19DavidHeidelberg[m]: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/41741800 21977 build
15:19DavidHeidelberg[m]: sorry, wrong chat
15:20vsyrjala: zamundaaa[m]: icl+ should have it. older likely not
15:22zamundaaa[m]: drm_info says it's a CometLake GPU
15:22zamundaaa[m]: CometLake-U GT2
15:22vsyrjala: that's too old
15:28zamundaaa[m]: The driver exposes the Colorspace property though
15:28zamundaaa[m]: That should probably be removed if the hardware can't support it
15:28vsyrjala: it can support that
15:30zamundaaa[m]: okay, then there's some bug with that. If I set Colorspace to BT2020_RGB and send BT.2020 content, everything's super desaturated. I assume it's ignoring the property
15:33vsyrjala: does i915.enable_psr=0 make a difference?
15:35alyssa: jenatali: Running through CI now, but
15:35alyssa: 67 files changed, 419 insertions(+), 2187 deletions(-)
15:35alyssa: so that should fulfill my code deletion quota for the week
15:37jenatali: Very nice
16:49karolherbst: do we have code in place to check what extensions a spir-v declares so we can validate against a list of supported ones?
16:49karolherbst: or is it all yolo atm?
16:50karolherbst: jenatali: you don't support accepting random spir-v in CL yet, right?
16:52jenatali: karolherbst: I implemented it forever ago but never really hooked it up
16:53jenatali: karolherbst: vtn_handle_extension?
16:55jenatali: karolherbst: You might know something I was just looking at - does CL have 64-bit atomics?
16:55karolherbst: it does
16:56karolherbst: as an extension I think
16:56karolherbst: somewhere...
16:56karolherbst: `cl_khr_int64_base_atomics` and `cl_khr_int64_extended_atomics`
16:56jenatali: I was thinking through extensions that I should be implementing for VK and 64-bit atomics was on my list, and I realized that the way we do shared vars can't handle that right now so I need to rework it, but the reworked way of doing it wouldn't be able to handle CL
16:57karolherbst: yeah.. it's messy because there is enough hardware not doing it on all address spaces either
16:57karolherbst: especially local/shared
16:57karolherbst: anwyay
16:57karolherbst: what I kinda want to do is to reject spir-vs declaring extensions we don't support
16:58jenatali: Isn't that already going to happen?
16:58karolherbst: it doesn't
16:59karolherbst: we can tell the translator what we support, but that doesn't help for application provided spir-vs
16:59jenatali: Did you look at vtn_handle_extension?
16:59karolherbst: I did
16:59jenatali: Or are you talking about capabilities that aren't extensions?
16:59jenatali: Or rather, that don't have extended opcodes
16:59karolherbst: I don't see where it handles general spirv extensions
17:00karolherbst: things like "SPV_EXT_shader_atomic_float_add"
17:01jenatali: Oh 'cause it only adds a capability and modifies validation rules, it doesn't add new instructions...
17:01karolherbst: it's defined through cl_ext_float_atomics, but if you don't support that extension you are free to reject spir-vs using the spirv ext
17:01karolherbst: yeah..
17:01karolherbst: atm we only handle those ext instruction things
17:01karolherbst: and that's kinda fine
17:01karolherbst: but I kinda want to validate all extensions declared
17:01jenatali: Wait no it does have new instructions, but they're not "extension instructions" they're just... instructions. Wtf
17:01karolherbst: yeah
17:01karolherbst: it's not uncommon
17:01karolherbst: anyway
17:02karolherbst: now that I look into supporting SyCL/HIP I kinda want to bail when seeing unknown extensions
17:02karolherbst: especially DPCPP is in yolo mode and just doesn't care what the runtime supports
17:03jenatali: I'd add handling of SpvOpExtension similar to what we do with SpvOpCapability, have a nice table of known/implemented extensions that the caller can provide
17:03karolherbst: yeah.. maybe
17:04karolherbst: or just a list of strings.. dunno
17:04karolherbst: I think we have something for vulkan already actually...
17:04karolherbst: gfxstrand: is there any kind of spir-v extension validation going on for vulkan?
17:05jenatali: Generally the extensions add a capability. We already have a list of valid/known capabilities. Maybe we don't need to do anything for OpExtension then
17:05karolherbst: mhh yeah.. maybe it would be fine to just fail in `spirv_to_nir`
20:22lumag: rodrigovivi, excuse me, yet another ping for the DSC series
20:56alyssa: total instructions in shared programs: 1537964 -> 1571328 (2.17%)
20:56alyssa: big ouch
20:58alyssa:giving up on mediump
21:28rodrigovivi: lumag: only patch 6 missing review now, right? I put and internal email here to find out the best one to give the final review on that so we can merge...
21:28lumag: rodrigovivi, thank you!
21:28lumag: Please excuse me for being PITA about it :-)