06:42 benjaminl: does vulkan spirv specify the behavior of out-of-range int->float conversions?
06:43 benjaminl: my reading of the spec is that it should be inf with RTNE and the max finite value with RTZ, but it's weird that there's no CTS tests for this case
06:45 HdkR: More tests for the tests gods
06:49 benjaminl: hahaha yeah
06:49 benjaminl: unless I'm missing something here :)
06:55 benjaminl: ah, GL_EXT_shader_explicit_arithmetic_types explicitly says that out-of-range int->float is undefined
06:56 benjaminl: I was second-guessing because panfrost currently does int32->float16 by truncating to int16 first, but I think that behavior is legal in opengl and illegal in vulkan
08:07 glehmann: benjaminl: yes it's illegal in VK. I don't think it's legal in GL either if you have a highp int to mediump float conversion?
08:11 glehmann: at least for i32 -> fp16 it has to be illegal because FLT16_MAX is larger than INT16_MAX, even without overflow you will get incorrect results
08:35 benjaminl: yeah, sorry, meant illegal for u16->fp16. i16 is always illegal. I'm not sure about mediump, but I'm replace this with i/u16->f32->f16 regardless
08:36 benjaminl: *replacing
10:01 sima: mripard, I guess another case of "atomic is hard"
10:02 sima: might be better we chat here to figure out what to do
10:02 mripard: the plus side is you never stop learning I guess :D
10:02 sima: it's great
10:06 mripard: so let's ignore my series for now, and focus on what the problem is. For his work on error recovery, Herve needs to access and power-cycle the CRTC onwards. So you need to get access to the current CRTC that feeds that bridge.
10:06 mripard: for now, he's been following the drm_encoder->crtc pointer, which isn't great.
10:06 mripard: https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next/drivers/gpu/drm/bridge/ti-sn65dsi83.c#L371
10:07 mripard: I guess the issue I'm trying to solve is how a bridge can access the CRTC outside of the modesetting code path
10:07 mripard: (and without relying on !atomic, legacy, pointers)
11:51 lesliearrowdeed: My own tests based of shorter sequences to make data accesses, have all failed in fact, but they have not followed sensible logic either.
11:52 lesliearrowdeed: so the depchain i posted was the only stable way, there is one more, but it has huge compile delay, as well as storage inefficiency
12:04 sima: mripard, ok that's a different thing, and I guess for that we should push the locking into a bridge specific helper
12:04 sima: LOCK_ALL works, but it's also overkill
12:05 sima: essentially you need mode_config.connection_mutex, which stabilizes the connector states enough that you can walk them
12:06 sima: that gives you the crtc, and then you can just use the existing helper (or at least is in-flight, I put an ack on it)
12:06 sima: so you do not need LOCK_ALL at all
12:06 sima: but it's tricky enough that we should have a bridge helper for this
12:07 sima: also if you make the bridge routing more flexible, you need to walk bridge states and that means grabbing the locks for those as you walk them
12:07 sima: until you hit the encoder, which is stable, then you grab mode_config.connection_mutex so you can read-only walk connector states (without adding them to your drm_atomic_state ideally, so this is a bit tricky and defo should not be done in drivers)
12:08 sima: and that gives you the crtc you want to call drm_atomic_helper_reset_crtc
12:08 sima: unless I missed something
12:09 sima: I guess the read-only walking of connnector states to find the crtc or connector for an encoder is something we should perhaps extract from atomic helpers
12:09 sima: so that relevant other helpers can use it
12:09 sima: but maybe not export it to drivers or something like that, if doable
12:11 sima: mripard, hm I redid all the loops in atomic helpers to just walk connectors, so we don't yet have the code to go from encoder to its connector I think
12:11 sima: ah no, I think steal_encoder() has what you want
12:24 sima: mripard, also to your fundamental question of how can a bridge access the crtc outside of the modesetting path: not, but you can do a full modeset if your in a threaded context
12:24 sima: which is what your reset example ends up doing
12:25 sima: this is also why legacy cursor hack and to a lesser extent, the async flip stuff is such a mess: it tries to bypass the modeset machinery
12:35 lesliearrowdeed: Lot's of the code has just aged a bit for modern usage APIs and ABIs too. Once i showed boyi slides about every opencl method. Such terms as locking memory did not serve already then, but it serves even fewer with compression enabled, but i am hopefully landing the last tests and maybe get my hands on developing something. There is bit hysteria about war getting close to areas here, i
12:35 lesliearrowdeed: do not have enough experience on detecting or destroying attack drones, i know there isn't any more powerful method known on the web than is antimatter controlled annihilation, and cameras also i know nothing about, i know there just cubious amounts of energies released in neutrino energy field particle collisions, Europe deals with such technologies, i am not worth scientist in those
12:35 lesliearrowdeed: subjects. if the underlying compute system works fast, the energy can form light too.
12:37 mripard: sima: except you don't have access to the global state after swap_state, so you can't make that walk, even with all the right locks?
12:38 sima: mripard, you do a full atomic commit
12:38 mripard: right, but you need to identify the CRTC to do the commit on using the existing state
12:38 sima: nope
12:39 mripard: how can you go from drm_bridge to drm_crtc then without drm_atomic_state?
12:47 sima: mripard, https://paste.debian.net/hidden/aeb3c608/ in-place edit of the reset_crtc helper, but for bridges
12:48 sima: https://paste.debian.net/hidden/8b1981e9/
12:48 sima: I thought you could reuse the code from steal_encoder, but that relies on add_affected_connectors having been called already
12:49 sima: which we cannot rely on here since we start with the bridge
12:49 sima: which I guess is why you think we can't at all, but we still can by stealing the essential part of the add_affected_connectors logic
12:50 sima: so big flow is 1. bridge -> encoder (currently easy, but in a dynamic future only needs bridge locks to get at bridge state)
12:50 sima: 2. encoder -> connector, using a combo of the tricks add_affected_connectors and steal_encoder uses
12:50 sima: 3. connector -> crtc
12:50 sima: 4. reset crtc using an atomic commit
12:51 sima: my apologies for designing this stuff :-/
12:51 mripard: oh, yeah, that makes sense
12:51 mripard: thanks :)
12:52 sima: I thought you could extract the magic encoder -> connector trip, but for existing users it's split up so unfortuantely we need a new one
12:52 sima: but I think a drm_atomic_connector_for_encoder() core function would be good, even just to document this trick
12:52 mripard: ack, I'll work on it
12:53 sima: and then maybe also a drm_bridge_find_encoder, to handle the legacy/fixed bridge chain vs dynamic case using atomic states and modeset_lock correctly
12:53 sima: they both need at least a drm_modeset_acquire_ctx, I think you can avoid the drm_atomic_state for both
12:54 sima: so maybe just drm_connector_for_encoder(struct drm_modeset_acquire_ctx *ctx, encoder)
12:54 sima: and similar prototype for the bridge part
12:55 sima: I think with that approach you could even directly reuse the existing drm_atomic_helper_reset_crtc
12:55 sima: since you don't need the atomic state yet to walk the pointers, it's all read-only
12:55 sima: if you do it right at least
12:55 sima: you only need the right locks, for which acquire_ctx is enough
12:56 sima: and then a nice drm_atomic_helper_reset_bridge that ties it neatly together
12:56 sima: oh also please kerneldoc links between the variants and maybe even some DOC overview comment about how to link reset different stuff?
12:58 lesliearrowdeed: last time i hear germans talking about atoms sequences or nucleotides in case of monomers and such, but isotopes definition more related to extra energy rich methods is still nuclear , it's the particles inside the atom, proton and electron, and phosphor though having equal amounts of those, it forms anion as told in web in reaction terms it is used in battery as negative contact. but
12:58 lesliearrowdeed: plus alklalines we have too a lot. Really it's all that i can comment there, i know cern and austrial mainstream science already tests in real products some of the most efficient nuclear technologies, for me such things ain't gonna happen locally fast enough.
12:58 lesliearrowdeed: allotropes are named for atomic sequences.
13:00 mripard: sima: I'll do my best :)
13:01 sima: mripard, ping me if you're stuck
13:03 mripard: sima: the code is fine, but I'm sure the locking and doc is going to suck :)
14:15 stinkstobeme: so all that is getting very complex 69+69 was 138 so if that was first bank and first index presumably you call the 256-230=26 and 256-115=141, next base on every index has to be smaller or bigger? 141-138=3 and run the procedure, i'd go for starting with preallocated bigger bases to encourage every one to be careful or think upfront. But the calculations are just so annoying.
14:15 stinkstobeme: 256-57-57-57=85 128-85+26+3=72 etc etc , so do we allocate 256digits worth storage for every 138 alike and leave it possibly to half the occupancy cause everything depends on what the max values are so 120 it was 70-66 pair for 115 72-69 naturally or do we account the maximum like 141 and 136 etc. i'd go for the last but instead of increasing indexes i'd choose decreasing ones similar to
14:15 stinkstobeme: bases, i think that helps to account with the future by will?
14:47 thinblueline: filesystem at child's shoes. I could still make the testing go fast enough, but whatever I do not know what standing in thin blue line means except that i am a known color blue guy. I assume none wants to work, first operation on this type of storage facility is to write a loop that accounts the real format for execution capable things. and take notes of 32 and 64 bit storage capability,
14:47 thinblueline: i am nobody in mathematics world, i can not calculate so big numbers in the head. Though the first thing before that is a set of people willing to allow modern features to be allowed in then the technical implementation to follow.
15:27 stsquad: is there a minimum version of the vulkan api required for venus to work?
15:49 digetx: venus only requires presence of certain vk extensions, otherwise it doesn't have min vk version, afaik
16:31 stsquad: digetx: but failure of those extensions causes virglrenderer to return with a fail?
16:31 stsquad: or should QEMU probe itself?
16:32 stsquad: digetx: see CAFEAcA_TJhgrcfZ-9JY74OvkiGXPuYHJF16=_3Y+=r6+JfXMGA@mail.gmail.com (nvidia prop driver crashes)
16:32 stsquad: we could just blacklist nVidia
16:51 austriancoder: alyssa: is asahi's gallium driver the best when looking for a transform feedback implementation for hw/sw that does not support it natively? panfrost has one too..
16:51 alyssa: sigh
16:51 alyssa: if you're just trying to pass gles3.1 cts, use panfrost's
16:52 alyssa: panfrost's is not valid for desktop gl or gles3.2, but you do not want to go there.
16:52 alyssa: adult-level transform feedback is just a special case of geometry shaders
16:53 alyssa: at some point I expect panfrost to switch over to the adult-level version, but that will come with emulated geometry shaders
16:54 alyssa: which is... not what you want if you're asking me this right now ;)
16:55 alyssa: (writing common code for "geom/tess/XFB/pipeline-stats/primitive-restart/indirect-draws emulation" is .. happening, very slowly. but yeah.)
16:56 alyssa: you can't pick off just one of those problems and emulate it correctly without considering the interactions with the other 5
16:56 alyssa: I /think/ this is finally all correct (though not always efficient) in honeykrisp
16:56 alyssa: and that ate up, like, over a year of my time lol
16:57 nylonbeatfan: yep, actually to do anything related to superior performance than fixed at strategy of vendors, many things have to be emulated. interactions are known.
16:59 nylonbeatfan: it is possible, but indeed that is known, but i have not even started , especially what is unknown is the reactions as well as allowance to do anything among the lines i had queued up.
17:10 mlankhorst: sima, airlied: Do you think this can still hit -fixes this cycle? https://patchwork.freedesktop.org/patch/638548/?series=145178&rev=1
17:10 sima: mlankhorst, why not?
17:10 mlankhorst: I mean drm-misc-fixes was sent out earlier today :)
17:11 sima: oh
17:11 sima: does it need to be this fast?
17:11 mlankhorst: nah
17:11 mlankhorst: otherwise it'll be ready for next, that's fine too
17:11 sima: I guess I could smash it into drm-fixes directly, but doesn't feel like that's needed
17:12 sima: mlankhorst, btw 2x add in your commit message
17:12 sima: s/add add/add/
17:17 mlankhorst: Ah right
17:17 mlankhorst: Will push it to drm-misc-fixes and fixup before I forget. :-)
17:18 digetx: stsquad: nv driver is known to not work with venus, don't use it for testing
17:21 stsquad: digetx: this was someone else running into the bug when running QEMU's functional tests. So we need to defend users against using it on their systems
17:24 stsquad: digetx: btw I got vulkaninfo on the working image and confirmed it doesn't have VK_KHR_display either - so I think the easiest approach will be to patch vkmark not to *require* it
17:25 digetx: heard nv fixed some of issues in their beta driver, in general don't think it's our problem
17:36 austriancoder: alyssa: good to know - not sure if I need/want the adult-level one for zink.
17:43 daniels: austriancoder: etnavk?
17:45 austriancoder: daniels: there might be a branch named that way in my mesa repo, but atm I am dealing with a closed vulkan driver
17:45 DemiMarie: austriancoder: which one?
17:46 austriancoder: DemiMarie: can't tell
17:46 DemiMarie: austriancoder: is this on some sort of embedded system where you don't know the driver?
17:47 austriancoder: DemiMarie: can't tell
17:50 alyssa: austriancoder: ...wait, this is for zink?
17:50 alyssa: dear lord
17:50 alyssa: well, uh
17:50 alyssa: good luck
17:52 alyssa: (in general it seems to be easier to do these sorts of heroics efficiently in a hw driver where you have extra knobs to play with, versus in a pure layered impl)
17:52 zmike: at that point might be easier to just implement in mesa/st
17:52 alyssa: (although that might just be my "I work on hw drivers and get lost whenever I touch zink" bias)
17:53 alyssa: (any common code I write for emulation intends to support layered impls, so it's not impossible obviously.)
17:53 alyssa: s/it's not/I don't think it's/
17:54 austriancoder: I can't touch the driver at all - my current workaround: MESA_GLES_VERSION_OVERRIDE
17:55 alyssa: this is the prop vivante vk?
17:55 austriancoder: no
17:56 alyssa: ..care to share with the class then?
17:56 daniels: alyssa: just keep guessing
17:56 alyssa: well, I think Arm caved and did xfb in their prop vk driver
17:56 austriancoder: NDAs .. sorry
17:56 alyssa: hm why am i guessing let me check gpuinfo
17:57 zmike: it could be a secret driver that has never been reported
17:57 austriancoder: lets change topic before I get into troubles
17:58 alyssa: zmike: Apple??????
17:58 zmike: !
17:58 austriancoder: how's your weather today?
17:58 zmike: apple-y
17:58 Kayden: magical
17:59 DemiMarie: austriancoder: Companies like Collabora might be willing to do consulting under an NDA.
18:00 alyssa: based on gpuinfo i guess it's IMG or something, it's just, we have open src vk drivers for all vendors except Viv (and, like, Huawei and Samsung I guess...?) in tree now
18:01 alyssa: and i assume all of the mobile things are ANGLE-y and not Zink-y anyway
18:03 daniels: austriancoder: sales@collabora.com if you need help :)
18:04 austriancoder: daniels: :)
18:06 alyssa: ...at any rate, if the underlying vk driver does geometry or tessellation shaders, but not XFB... yeah you're screwed.
18:07 alyssa: (it *might* be possible to bolt something onto HW GS's, but you need /something/ to deal with the prefix sum requirements which like. these are all solvable problems but I don't think anyone has solved them either. And I highly don't think zink, or mesa/st, is the right place for this.)
18:08 pac85: is Huawei and Samsubg's version of mali different enough to not be able to be supported in panfrost?
18:08 alyssa: pac85: Samsung is a version of AMD afaik
18:08 alyssa: IDK what Huawei is doing
18:09 alyssa: (does Huawei even make gpu's? i know they have VK_HUAWEI extensions)
18:09 pac85: I thought it was mali for Huawei
18:11 alyssa: iirc there was also an IMG spinoff, Moores Thread maybe?
18:16 HdkR: alyssa: Exynos 2100 from 2021 was Mali, but 2200 and 2400 is Radeon. With the latest devices they may have switched entirely over to Snapdragon although.
18:16 pac85: ah so rip amd on mobile?
18:16 pac85: sad
18:17 alyssa: HdkR: entertaining
18:17 HdkR: At the very least this year's phone didn't have an Exynos variant, which has been taken by some to mean that Exynos is dead.
18:31 austriancoder: daniels: would you be really unhappy if I would assign !3418 to marge? Atm I have no idea how to proceed.
18:56 Lynne: validation layer has been lying to me all day chasing a bug that doesn't exist
18:57 Lynne: my code runs fine on lavapipe and nvidia's proprietary drivers but miscompiles on nvk, radv and anv
18:57 Lynne: glslang takes 30 seconds to compile my simple shader which just happens to do a few BDA accesses
18:57 Lynne: maybe it's time we give up on this vulkan stuff
18:59 alyssa: Lynne: what's the alternative
18:59 alyssa: opengl?
18:59 alyssa: nap time?
18:59 alyssa: i vote nap time
18:59 Lynne: let's have lisp machines for GPUs
18:59 Lynne: no one's tried it before
19:01 Lynne: maybe we can run 20000 emacs instances at once, if emacs crashes, at least some of them should continue
19:01 Lynne: (yes, my emacs crashes too, we're really good at this computer malarkey)
19:03 mlankhorst: Feed your LLM directly into 20k instances of emacs. :-)
19:05 soreau: Lynne: would it make any sense to use spir-v so the nonworking cases work?
19:06 Lynne: two wrongs to make a right? hmm, perhaps, but I think that behaviour got broken by a recent glslang version
19:09 Lynne: ah, maybe the reason why spirv has silly little foibles like not being able to run bitwise ops on non-32bit types is because it was designed for high-level interpreted languages, right, that explains it.
19:11 aligometershand: I would want to move away from all vulkan/glsl/directx but such a mess in head , can not really get over the line with data manipulation in compressed. I do not know if i see only hallucinations still.
19:29 gfxstrand: Okay, It's been too long since I've done GL.
19:38 zmike: welcome back
19:39 Lynne: oh yeah also zink segfaults here (but not under gdb, so I don't even know where)
19:45 gfxstrand: dcbaker: How do I make a piglit test show up twice with different args? It's been a loooooonnnng time
19:48 alyssa: gfxstrand: i often forget i ever stopped doing GL
19:48 alyssa: apparently my platform has vk1.4 now but idk how that happened, apparently you wrote me a vulkan driver?
19:48 alyssa: whatever, cool, thanks for the driver i guess
19:48 alyssa: =)
19:54 gfxstrand: Ya'know. Just for shits and giggles, I might rewrite the Vulkan common synchronization code again...
19:54 alyssa: Go crazy, girl :)
19:54 gfxstrand: That happened a long time ago. :-P
19:54 alyssa: so true
19:55 gfxstrand: The fact that I'm considering touching that code is proof of this.
19:57 alyssa: gfxstrand: i mean i've been sending kernel patches by choice, so I get it (((:
20:04 dcbaker: gfxstrand: put the same binary into the profile twice with different argumetns?
20:04 gfxstrand: dcbaker: Where are the profiles?
20:04 gfxstrand:feels like a total noob
20:05 dcbaker: Nah, I just way over-engineered that stuff :D
20:06 dcbaker: in $piglit/tests/ there's a bunch of .py files, that at build time get interpreted and converted to xml files
20:06 dcbaker: those are the profile sources
20:07 dcbaker: If you look through there, y'll see a bunch of with profile.test_list.group_manager(... calls, those give you a function you pass a string list to that is the binary and any arguments you want to pass to the binary
20:07 dcbaker: the very end of opengl.py has an example of adding arguments
20:29 gfxstrand: How does iris pass my new piglit test?!?
20:33 zmike: test too weak
20:33 gfxstrand: My attempt at kicking off a submit thread didn't work
20:33 zmike: does iris even do threaded submit
20:33 gfxstrand: IDK but ANV does and that's what I'm trying to force
20:34 zmike: ah
20:34 gfxstrand: Because things get a lot more annoying when the Vulkan driver has a submit thread
20:44 gfxstrand: Okay, now iris/ANV fails
20:44 gfxstrand: Zink is still good
21:05 zmike: 🤝
21:18 gfxstrand: It wrecks ANV+Iris, though. :)
21:18 jenatali: Now you've got me curious
21:19 gfxstrand: jenatali: dozen should be okay
21:19 jenatali: Yeah WDDM doesn't need submit threads, but that doesn't sate my curiosity!
21:19 gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12650
21:19 gfxstrand: Everything is linked from there
21:19 jenatali: Oh ok cool
21:20 gfxstrand: To be clear, it's also broken with Zink but I have an MR to fix it.
21:20 gfxstrand: Just need final signoff from zmike for that one
21:23 HdkR: zmike: "Mesa's generic Zink OpenGL-on-Vulkan driver" Suddenly Zink is the Dr. Thunder of video drivers :D
21:23 zmike: I what
21:24 zmike: gfxstrand: so it's done now?
21:25 gfxstrand: Yup
21:25 gfxstrand: I think the test is in good shape too
21:27 zmike: good shit
21:27 zmike: HdkR: TIL Dr. Thunder
21:28 HdkR: zmike: I love me a generic cola.
21:30 HdkR: The Mr. Pibb of mesa drivers maybe better? :P
21:33 zmike: I don't really drink soda so it's all lost on me
21:37 HdkR: Tis a shame
23:30 DemiMarie:hopes for userspace fences now that a way to implement them is known
23:36 gfxstrand: So say we all
23:36 gfxstrand: Who's claiming to know how to implement them this time?
23:44 DemiMarie: I thought you, Christian, and Sima figured out a way to do it
23:45 DemiMarie: Or at least a way to allow long-running compute and Vulkan winsys to coexist in the same context
23:47 DemiMarie: Is the consensus still that all the complexity needed for dynamic memory management is worthwhile, as opposed to "just" pinning everything?