02:33airlied[d]: mohamexiety[d]: Start with checking all simpler demos work is usually where I go first, then try to capture a trace, then stare into the void
03:10gfxstrand[d]: With DA:TV I see it fault on the shader compilation screen.
03:11gfxstrand[d]: I was about to say there's not much going on there and then I remembered they render an entire scene and then paste the purple particle thing over the top. 🤦🏻♀️
04:43goldretriever: All the hack is in compact mode logged now, it starts from teronimozuck and MaryTrampoline and realsessioneight on dri logs, that can be searched. And continues from #nouveau primary non-searcheable logs from 2025.08.03 dragonheavyheart and below. Where as final ones were offered by me as 2025-08-16 and 2025-08-18 on #nouveau where i switched due to no-registration policy again and the
04:43goldretriever: permutations base was on #nouveau 2025-08-14 steveonfire and below, that ends in reverse order, and compilation standard before was done months earlier this touched as to how to synthesize fixed indexes like 118.
04:57goldretriever: But i am not going to build that compiler from home, because though very well doable, you would want to show me your side of intelligence and work mode to get there, and gain some momentum. The specification was only offered as of now for everything, but if you want such code your own, go build it , quite some modifications need to land to chosen wasmati code property graph wasm code.
05:00goldretriever: Here i have problems that my computer and organic implant has been chipped in to expose me, with such scam parties i do not want to implement everything for the rest of my life to get treated with abuse, i need an offer for job for national security and they need to remove the implant before i implement the needed military code.
05:31dannyhues: But i looked at german ss and such documentaries, we are on age where drones have gathered momentum, and even more modern robotized military can be built to issue a real killing machines against the invader , if factories are whirled on real throughput to produce such technology which is fairly doable, there is no human based army who could combat such tech, i.e a real killing machine. You do
05:31dannyhues: not want to do the engineering of that in the moment being under cheaters/terrorists implant.
10:10chikuwad[d]: <a:c_poke:838674078352015380>
10:10chikuwad[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31518
10:26nerdygeek83: It's that our local fuck aces and anal leaders from Estonia aka undisputed analweight champions of the areas, messed up the world with their shows, tunes and podcasts, it's a quasimodo clan of illborn leftovers from here, who get killed in the following years, most of them got beaten up, but as mentioned they were terminally ill already from birth tbh. Eesti peeruvahekepi ja nussiässad
10:26nerdygeek83: kõvernägudest intriigabortijäänuste tüütu pisigrupeering. Their annoying crime partners are being searched all around the world scheduled for kill off. Their achievements are born as leftover, claiming they invented crookface anal and vaginal and oral sex and hence are ways above military and maths engineers and sportsmen and such, totally deluded suicidal terrorists.
10:56nerdygeek83: i excersized those routines for great 10 years only that late and got injured in excess by due to their activity, they managed to vote me out of getting permission to own guns laptops and such, so i landed to situation where i made the needed specification way too late, now we might be at the fire reach soon by Russians, and i do not know how to communicate or negotiate with those last
10:56nerdygeek83: powers at all, i wasn't rusophobic like those others either.
11:17nerdygeek83: It feels like the understandings of those people in larger view of the world's peace is also cracked, as they initate a conflict then go missing and watch the killings to be resolved by parties that were not involved in intra or interconflict between them at all originally. I have actually zero clue what to do, my equipment is long since compromised, and i have no lead in front of powers
11:17nerdygeek83: coming at me, i haven't got factories or nothing, i only have code that will be shared and overtaken from me, due to series of chips implanted and the last seems to capable of those to be tricked. And neck surgery i can not perform to myself either.
11:29nerdygeek83: i just waste time everyday knowing that my life is round about halted by flamers, as small nation is where i hail from there are positive sides to live here too, but there is no one to lean on i believe which is the negatives of being a citizen of such nation.
11:29nerdygeek83: i had to be going way smarter than i did, and it never materialized, cause i got entire terror and nonsense back at every my word exchange session.
11:47nerdygeek83: so asylum or some political or military state is what is needed atm. and i do not have it, so might as well say I have nothing, since testing the compiler yes that i invented is taking another two years minimally to test the new operating system and such for all corner cases, and means working every day on it without any benefits, since all that would contribute to assaults and attacks
11:47nerdygeek83: against myself.
11:48nerdygeek83: so in this position maybe better is just to be and be and aim for the stars, stare aimlessly into the sky and be an outsider like those who ruined me once already.
11:52nerdygeek83: anyways all the logs i have if someone requests me something i can look what my pseudo code specification really was, and we can go over the specification, when i leave the channel it automatically logs archives the conversation into whatever libsqlite database, but i copy pasted all the logs to text file too.
11:52nerdygeek83: i have multiple copies yes.
11:55nerdygeek83: what is very plausible in math science though i do not practice derivative based math at all, and i failed that part in the uni
11:56nerdygeek83: that sin cos tan first and second derivative is in computers slightly longer latency operation set, i just rearranged one of those thigs into workable routines
12:07nerdygeek83: Some computer chips are specialized to treating those derivatives, and i have not really researched these, but i think the best hack is to simulate them as like i offered.
12:08nerdygeek83: that would cover all the chipsets ever produced in the world, and would leave a little small chanche for survival
12:11nerdygeek83: again, as of today ukranians are doing their war pretty much with help from europe and united states indeed, otherwise they'd be all won in the war already though they are strong people, incredibly strong, it was some fault of the strategy to go against Russia barely naked, believe me, Estonians have done a lot worse their own, and the batttle for our independence would not last long and
12:11nerdygeek83: loss is declared in days not months definitely
13:11BITCOINBOT: Hello you may want to check out https://bitcoin.foundation and the a proposal to make Bitcoin Quantum-Resistant at https://quantum-resistant-bitcoin.bitcoin.foundation
13:11BITCOINBOT: IP [[m:User:2.73.144.214]] Tiny create [[m:Translations:Wikimedia chapters/5/gn]] (+2) URL: https://meta.wikimedia.org/w/index.php?oldid=29163648&rcid=36579023 "Created page with "н""
13:17BITCOIN_BOT: Hello you may want to check out https://bitcoin.foundation and the proposal to make Bitcoin Quantum-Resistant at https://quantum-resistant-bitcoin.bitcoin.foundation
13:17BITCOIN_BOT: IP [[m:User:2.73.144.214]] Tiny create [[m:Translations:Wikimedia chapters/5/gn]] (+2) URL: https://meta.wikimedia.org/w/index.php?oldid=29163648&rcid=36579023 "Created page with "н""
13:24TheHypervisor[m]: Spam lol
13:24TheHypervisor[m]: Don't do it its a scam
13:26BITCOIN_BOT: Hello you may want to check out https://bitcoin.foundation and the proposal to make Bitcoin Quantum-Resistant at https://quantum-resistant-bitcoin.bitcoin.foundation
13:26BITCOIN_BOT: User [[s:no:User:Øystein Tvede]] Copyvio? [[s:no:Side:Mauritz Hansens Noveller og Fortællinger 1.pdf/332]] (+2095) URL: https://no.wikisource.org/w/index.php?oldid=272455&rcid=395489 "/* Korrekturlest */"
13:46BITCOIN_BOT: Hello you may want to check out https://bitcoin.foundation and the proposal to make Bitcoin Quantum-Resistant at https://quantum-resistant-bitcoin.bitcoin.foundation
13:46BITCOIN_BOT: User [[s:no:User:Øystein Tvede]] Copyvio? [[s:no:Side:Mauritz Hansens Noveller og Fortællinger 1.pdf/332]] (+2095) URL: https://no.wikisource.org/w/index.php?oldid=272455&rcid=395489 "/* Korrekturlest */"
15:30cubanismo[d]: I didn't realize IRC spam/random chatbot banter was such an issue until I joined this Discord.
15:30gfxstrand[d]: heh
15:30gfxstrand[d]: cubanismo[d]: Since you're here, is there a new version of the modifiers on the ML that I missed?
15:31cubanismo[d]: I haven't seen any responses to the one from 8/11 yet.
15:31cubanismo[d]: So maybe that one?
15:31cubanismo[d]: I was just about to ping you.
15:49gfxstrand[d]: I'm wondering if I should actually test 16-bit display with NVK just to be sure.
15:51gfxstrand[d]: cubanismo[d]: Looks good. Left one comment.
15:51gfxstrand[d]: I'm gonna refresh the NVK MR and maybe test things a bit
15:56gfxstrand[d]: If you wanted to review the NVK MR, that would help. Let me grab the latest header first, though.
15:58gfxstrand[d]: Never mind. Looks like the header I have is right already
15:59gfxstrand[d]: So, yeah, if you could review that it'd be great.
16:00gfxstrand[d]: (Assuming you're allowed to. Otherwise, I'm sure Karol or Dave can)
16:00cubanismo[d]: OK. I think the assumption in your comment that userspace values reach this code is off, but I have a meeting. Will have to verify after and will respond on list
16:00gfxstrand[d]: Okay
16:00cubanismo[d]: And yeah, I'll review the NVK MR.
16:00gfxstrand[d]: I'll try and have tested by the time you get out of your meeting. Building the kernel now.
16:01cubanismo[d]: I hope it works 🙂 I used your MR for testing the kernel changes
16:01gfxstrand[d]: 👍🏻
16:02gfxstrand[d]: The other question we need to answer is how far we want to backport all of this.
16:03gfxstrand[d]: GNOME doesn't even have an option for color depth anymore so I can't set it to 565. 😂
16:07gfxstrand[d]: I may have to test with oldschool X11. :frog_upside_down:
16:12gfxstrand[d]: gfxstrand[d]: But ugh... IDK that I have new enough X11 for modifiers.
16:12gfxstrand[d]: I had a frankenbuild that worked at one point but I'd rather not roll that out.
16:45cubanismo[d]: You mean you're not running the latest Xlibre?
16:45asdqueerfromeu[d]: gfxstrand[d]: That would be perfect for GTA 2 🧓
16:46x512[m]: I wonder why Xlibre authors decided to break drivers ABI.
16:47x512[m]: Situation with proprietary Nvidia X11 drivers looks strange.
16:53BITCOIN_BOT: Hello you may want to check out https://bitcoin.foundation and the proposal to make Bitcoin Quantum-Resistant at https://quantum-resistant-bitcoin.bitcoin.foundation
16:53BITCOIN_BOT: IP [[m:User:2.73.144.214]] Tiny create [[m:Translations:Wikimedia chapters/5/gn]] (+2) URL: https://meta.wikimedia.org/w/index.php?oldid=29163648&rcid=36579023 "Created page with "н""
16:53cubanismo[d]: Grr. Kwin crashed and took my carefully worded email with it.
16:54cubanismo[d]: Between that and all the corruption I get trying to actually use HDR in firefox, I think I need to switch it back off and admit it's just not ready yet.
17:03cubanismo[d]: OK, gfxstrand[d] responded. Let me know if that doesn't make sense, and if anything comes up in testing. FWIW, I validated 16-bit support in kmscube.
17:03cubanismo[d]: Via Zink
17:04ermine1716[d]: x512[m]: Stable ABI is woke
17:05x512[m]: How is it? Stable ABI is traditional values :)
17:06x512[m]: Anyway unstable ABI do not work well with proprietary software.
17:06cubanismo[d]: I miss the days when politics in stable ABI discussions meant closed Vs. open source drivers.
17:09cubanismo[d]: But look at me reminiscing about the past state of the world. I must have traditional values too.
17:12gfxstrand[d]: cubanismo[d]: No. I'm pretty sure NVK and Xlibre are fundamentally incompatible. There's too much woke in NVK. It probably won't even load.
17:13ermine1716[d]: x512[m]: You have a point, but they reject stable abis, and I don't believe they are competent enough to hve technical reasons
17:13gfxstrand[d]: Someone should convince the Xlibre guy that glamor is woke and that he needs to roll back to only supporting dedicated hardware drivers.
17:14karolherbst[d]: make use of nvidia's 2D engine, no 3D shader bloat
17:14chikuwad[d]: glamor is woke because queer folks are glamorous
17:14chikuwad[d]: :ha:
17:15karolherbst[d]: I don't know how competent the 2D engine is in terms of performance, but for basic 2D operations (and the xorg server prolly only need blit at this point) it might actually have lower CPU overhead? 🙃
17:15x512[m]: I still honestly believe that DDX driver architecture is better than kernel DRM/KMS drivers because it is more portable and safe.
17:15gfxstrand[d]: ermine1716[d]: Really, X11 has never had stable ABIs and that's half the problem. It's stable within a version but every version breaks random shit and everyone has to rebase on it.
17:15karolherbst[d]: x512[m]: DDX do command submission just like the modesetting DDX does through GL
17:15x512[m]: DRM drivers are basically Linux vendor lock, but X11 is very portable.
17:16karolherbst[d]: they even run shaders
17:16x512[m]: Kernel KMS is not needed at all if use DDX drivers.
17:16karolherbst[d]: x512[m]: yeah, just that the interesting DDX are also not portable
17:16karolherbst[d]: it is
17:17gfxstrand[d]: Eh, you always get locked into *something*. Turns out being locked into X11 kinda sucks.
17:17karolherbst[d]: like sure, you could use some weirdo old DDX who bash your PCIe bars somewhere and talk to the hw directly, but...
17:17gfxstrand[d]: And the BSDs have demonstrated that DRM isn't necessarily Linux lock-in.
17:18ermine1716[d]: Like, there's a bunch of merge request where metux "cleaned up" something, and they have a comment from some Nvidia guy: "we use it, please don't remove it"
17:18karolherbst[d]: I think it's more of a "kernelspace" vs "userspace" thing, where the latter is always better 😛
17:18x512[m]: At least much easier portable. Linux kernel is just another world with non-standard C, homegrown reinvent the wheel utilities instead of libc.
17:18karolherbst[d]: because libc sucks
17:18karolherbst[d]: it only comes with a single hash table even
17:18x512[m]: gfxstrand[d]: It is doable, but it is much much much harder to port and maintain.
17:18karolherbst[d]: like I wished nobody would use libc because the interfaces are ... bad
17:19gfxstrand[d]: With more stuff moving to firmware submission, doing a kernel driver in userspace could be an interesting exercise.
17:20karolherbst[d]: if we do userspace command submission...
17:20ermine1716[d]: Managarm somehow has wayland, doesn't it?
17:21x512[m]: I started to think that running whole Linux kernel in hypervisor or userland process for DRM drivers on non-Linux OS is most optimal idea in terms of maintenance work.
17:21gfxstrand[d]: But also, "OMG! We did all this in userspace." is a great argument until you remember that back then no one had per-process page tables so nothing was remotely secure. Security came from one application holding onto the GPU and managing everything. Once you have per-process page tables and actual process isolation, now it has to be managed by something central and trusted like the kernel.
17:21x512[m]: ermine1716[d]: Managarm implement its own GPU drivers. It provides DTM ioctl's, but implementation is completely different.
17:22x512[m]: gfxstrand[d]: IOMMU exists.
17:23karolherbst[d]: does every consumer system have an IOMMU the GPU could use?
17:23x512[m]: Also userland code is more portable in general. And vendor lock is bad and against open source philosophy.
17:23gfxstrand[d]: Meh. Some people's open-source philosophy
17:24karolherbst[d]: portability is a non goal these days
17:24gfxstrand[d]: "Everything should work everywhere all the time" sounds great but ends up being a lot of work for not a lot of benefit 90% of the time.
17:24karolherbst[d]: like sure... we _could_ be portable
17:24karolherbst[d]: but the portable cross platform APIs are annoying to use
17:24ermine1716[d]: x512[m]: So they have kms, at least in interface
17:24karolherbst[d]: so you spend more time using them than just interfacing with each platform directly
17:24gfxstrand[d]: Linux is already niche. "All the things" is a niche of a niche of a niche. It's really hard to justify the software cost once you get too far down that rabbit-hole.
17:25x512[m]: Managarm implements KMS ioctls in userland service.
17:25karolherbst[d]: we should have made KMS part of POSIX
17:25gfxstrand[d]: lol
17:25x512[m]: Implementation has zero common code with Linux.
17:25gfxstrand[d]: Doing KMS in a daemon actually wouldn't be a terrible idea.
17:25gfxstrand[d]: Assuming the page tables work okay.
17:25karolherbst[d]: mhhh
17:25karolherbst[d]: that's gonna be a mess on multi device systems
17:26karolherbst[d]: but...
17:26karolherbst[d]: if the buffer sharing stuff remains in the kernel, maybe it won't matter
17:26ermine1716[d]: x512[m]: Re iommu: I had to manually enable one on my work laptop, because kernel decided it's not safe to enable it automatically
17:26karolherbst[d]: yeah.. IOMMU's don't exist if you care about users
17:26ermine1716[d]: gfxstrand[d]: That's what I would do if I was working on a microkernel OS
17:26karolherbst[d]: like..
17:27karolherbst[d]: sure NVLink also exists, and we could say "yeah, we only support nvlink"
17:27gfxstrand[d]: Like, I'm all for page table management staying in the kernel and maybe some stuff around command submission if it needs to interlace between processes. But there's no reason why we couldn't have a userspace driver that drives the display. It's one thing that would get started by systemd at boot and then you have display. If it crashes, restart it.
17:27karolherbst[d]: there has been work for page table isolation within the kernel
17:27x512[m]: Yes, UMS should be fine.
17:27karolherbst[d]: like that certain parts use their own page tables
17:28karolherbst[d]: if you care about security that much
17:28x512[m]: Portability is my first priority because I am interested in Haiku.
17:29x512[m]: OpenRM is real blessing in that aspect.
17:29ermine1716[d]: I enabled that iommu so `fwupd security` could show HSI-3 platform security level
17:29karolherbst[d]: heh
17:30x512[m]: NVLink is incompatible with IOMMU?
17:31gfxstrand[d]: Just being able to map pages isn't sufficient. You need to be able to migrate them with a live GPU or else perf will suck.
17:33karolherbst[d]: not really sure it helps much.. like it's not like windows where all the shader compiler was in the kernel...
17:33x512[m]: I suppose advanced microkernel OS allow to handle page faults and do remapping in userland service.
17:34karolherbst[d]: what's the benefit?
17:34karolherbst[d]: and are they important enough to offset the performance loses
17:35karolherbst[d]: like it's all nice on paper and in theory, but in the end what matters are benchmark numbers and usually microkernels aren't great unless you compare IPC, which only matters on microkernels and nowhere else
17:35ermine1716[d]: x512[m]: Here's a problem: portability requires effort. So stating that portability is integral to open source philosophy means putting additional effort who develop graphics stack (in context of the discussion). And that's not sustainable, and that's not a Nash equilibrium
17:36x512[m]: About Windows: they even have whole display server as kernel module (win32k.sys). So you can crash kernel with bad font or event palette.
17:37ermine1716[d]: So, I'd love if this stuff was more portable and it wasn't too hard to port KMS and stuff to other systems, but that's utopian, unfortunately
17:38ermine1716[d]: Otoh amdgpu's display core is portable probably
17:38x512[m]: ermine1716[d]: I think that Linux kernel development process is fundamentally hostile to open source philosophy. Instead of maintaining stable module ABI and allowing independent kernel module developers, Linux is monolithic vendor-locked thing that effectively do not allow code reuse and out-of-tree modules.
17:39karolherbst[d]: ?
17:39x512[m]: Even Windows kernel driver development model is more open.
17:39karolherbst[d]: you can use out of tree modules just fine and you can reuse code
17:39karolherbst[d]: just needs to be GPL compatible
17:39karolherbst[d]: also
17:39karolherbst[d]: this is purely a "I'm morally superior, therefore you suck" argument
17:40x512[m]: You can't is "stable ABI nonsense".
17:40x512[m]: s/is/if/
17:40karolherbst[d]: well you can have your linux kernel with a stable ABI just fine
17:40karolherbst[d]: google does it
17:40karolherbst[d]: Red Hat does it
17:40karolherbst[d]: others do it as well
17:40karolherbst[d]: it's big in the automotive area or literally anywhere else in the industry where it matters
17:41x512[m]: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst
17:41karolherbst[d]: sure
17:41karolherbst[d]: and yet google and red hat ship kernels with stable ABIs
17:41x512[m]: You mean sticking with some old kernel version?
17:41karolherbst[d]: nope
17:42karolherbst[d]: "kernel version" is just a meaningless string
17:42ermine1716[d]: Again: stable abi = linux devs would have to maintain legacy stuff, and linux is far too big enough
17:42cubanismo[d]: In theory it'd be cool if there were e.g., APIs to compete with DRM on e.g., BSD.
17:43karolherbst[d]: you are free to provide the ABI from 5.14, but pick all the drivers and subsystems from 6.16
17:43cubanismo[d]: And someone got the POSIX band back together, and came up with some standard version
17:43cubanismo[d]: But you know
17:43cubanismo[d]: Reality
17:43karolherbst[d]: that's what Red HAt is doing basically
17:43karolherbst[d]: pick the new code and make sure the ABI guarantees still hold
17:43karolherbst[d]: it's a lot of engineering effort tho
17:43ermine1716[d]: Microsoft puts enormous amount of resources into stability of Windows
17:43x512[m]: How? I see many API breaks workarounds in OpenRM code?
17:43cubanismo[d]: It's hard enough to get enough people together to make one DRM work right and keep up with the various HW using it.
17:43karolherbst[d]: but if you think a "5.14 rhel kernel" is 5.14 you are gravely mistaken 🙃
17:44ermine1716[d]: Even so it's not 100%
17:44x512[m]: s/?/./
17:45x512[m]: karolherbst[d]: They reverting and rewriting API-breaking changes?
17:45karolherbst[d]: backporting
17:45karolherbst[d]: like almost all of DRM gets backported
17:46cubanismo[d]: But I do think for a unprivileged<->privileged daemon and/or monolothic kernel, modulo userspace submission stuff, the current DRM API is in roughly the right place.
17:46karolherbst[d]: though not every symbol is part of the stable ABI guarantee
17:46karolherbst[d]: and because GPU drivers are shipped in RHEL, DRM isn't ABI stable
17:46cubanismo[d]: E.g., our X11 DDX is built on a similar level kernel API.
17:46karolherbst[d]: but other parts are because of external drivers
17:47cubanismo[d]: The WDDM APIs have a similar level of functionality
17:47karolherbst[d]: but the point is.. nothing stops you from taking Linux and shipping it with stable ABI guarantees, it's just that upstream won't
17:47cubanismo[d]: Most operating systems with active graphics development seem to have converged here.
17:48karolherbst[d]: cubanismo[d]: yeah.... we already do almost everything in userspace
17:48ermine1716[d]: ~~what about vxd apis~~
17:48karolherbst[d]: well...
17:48karolherbst[d]: some 2D acceleration remains in the kernel
17:48karolherbst[d]: for things like prime
17:48x512[m]: DRM design is kind of obsolete with memory bound to submissions, guaranteed fence completion, no semaphore futex support etc..
17:48karolherbst[d]: or the system framebuffer sometimes
17:48cubanismo[d]: There are people that want to move the framebuffer/console out
17:48cubanismo[d]: And that seems like a fine plan to me.
17:48x512[m]: WDDM looks more modern.
17:49karolherbst[d]: yeah.. torch all the framebuffer stuff 😄
17:49karolherbst[d]: still need DMA acceleration
17:49karolherbst[d]: but that's not a lot of code
17:49cubanismo[d]: Yeah, I don't think there needs to be some rule that the kernel can't do DMA
17:49x512[m]: cubanismo[d]: This thing? https://github.com/dvdhrm/kmscon
17:50cubanismo[d]: Yeah, I think kmscon is the last concrete proposal I saw.
17:50gfxstrand[d]: Hey, look at that beautifully 16-bit cube!
17:50cubanismo[d]: I don't know if it still has traction or not.
17:50karolherbst[d]: isn't agetty already drawing in userspace?
17:51cubanismo[d]: I was hoping NV would make it through to something like kmscon getting adopted without needing to implement fbcon.
17:51cubanismo[d]: But then simpledrm happened.
17:51karolherbst[d]: heh
17:52gfxstrand[d]: cubanismo[d]: Okay, I've independently verified that NVK+kernel is using modifiers for 565. I'm not gonna bother verifying 80bit.
17:53cubanismo[d]: Yeah, I didn't either.
17:53karolherbst[d]: 565 brings back bad memories
17:53gfxstrand[d]: I wonder if kmscube can draw in 8-bit color
17:53cubanismo[d]: If you really want the cube to look nasty, run the ARGB1555 mode.
17:53karolherbst[d]: I was the one digging into why VNC on s390x has weird collors on 16 bits 🙃
17:53gfxstrand[d]: or even just 8-bit greyscale
17:53karolherbst[d]: *colors
17:53gfxstrand[d]: Oh, 1555
17:53cubanismo[d]: I couldn't get it to.
17:53gfxstrand[d]: That's a great idea
17:53cubanismo[d]: No EGLConfigs or something.
17:54gfxstrand[d]: get it to do 8-bit? That's plausible
17:54gfxstrand[d]: I wonder if 332 works
17:54cubanismo[d]: For the original format modifier stuff I wrote up a custom test program that SW-rendered all the block linear stuff.
17:54cubanismo[d]: And could do all the formats.
17:54cubanismo[d]: But I don't know where it is, and I don't want to dump time into modifying the block linear logic to handle these new layouts.
17:55gfxstrand[d]: Yeah, I don't think Vulkan has 223
17:55gfxstrand[d]: Let's call it good with 16-bit and deal with the bug reports if neever.
17:55cubanismo[d]: This is the way
17:56cubanismo[d]: I verified the right modifiers get advertised for 8-bit by listing the format+modifier pairings
17:57cubanismo[d]: That was good enough for me.
17:57gfxstrand[d]: Yeah, I'm fine with that.
17:57gfxstrand[d]: As long as NVK<->NVK works, that's honestly good enough. That way an app that uses 565 gets composited correctly. No one is actually using 565 for display these days anyway.
17:58gfxstrand[d]: But it's good that 565 display works, too.
17:58gfxstrand[d]: Gotta be able to run ancient Android on Thor!
17:58cubanismo[d]: Did you ever get your Tegra system booting?
17:58x512[m]: About modifiers, is it documented somewhere exhaustive list of parameters that need to be passed when use Vulkan opaque FD method of sharing GPU bitmaps?
17:59gfxstrand[d]: And apparently my reviews landed in airlied[d]'s gmail spam folder. 😂
17:59gfxstrand[d]: cubanismo[d]: Sort of. It boots but nouveau usually takes it down. steel01[d] has been working on it. Nouveau comes up about 1 in every 20 boots right now.
18:00cubanismo[d]: Uhg. "Works sometimes" is the worst bug.
18:00gfxstrand[d]: x512[m]: For opaque FD, you need to have the `VkImageCreateInfo` match. So... everything. That's the rule.
18:00cubanismo[d]: Yeah, and all the pNext too
18:01gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1408511288492953660/rn_image_picker_lib_temp_2fcb0e76-fe3c-46b3-95fb-8f48385440e9.jpg?ex=68aa01dc&is=68a8b05c&hm=a0c07d07aaf5b94a82cd48584ae27506a271c63937cde2e2c3628ee7e58efe05&
18:01steel01[d]: gfxstrand[d]: It's kinda on pause right now. I'm waiting on what I've pushed to #linux-tegra to get reviewed before I go making more changes on top. And... stuff isn't getting reviewed, so...
18:01gfxstrand[d]: Once it's up and running it sits there and runs pretty stable. It's just that it usually doesn't come up.
18:01gfxstrand[d]: But one boot in 20 isn't reliable enough for me to use it for development.
18:02steel01[d]: Yeah, no joke.
18:02karolherbst[d]: cubanismo[d]: how does that worka cross APIs tho 😛
18:02gfxstrand[d]: Like, if I plug it in before I leave on Friday, it'll probably have successfully booted by Monday. Probably.
18:02gfxstrand[d]: karolherbst[d]: All the relevant stuff has to match.
18:02gfxstrand[d]: What does that mean? Anybody's guess!
18:02gfxstrand[d]: Make it as matchy as you can and pray
18:02karolherbst[d]: yeah..
18:02karolherbst[d]: well..
18:03karolherbst[d]: the vulkan CL CTS stuff works fine on my impl, so yolo
18:03karolherbst[d]: though...
18:03karolherbst[d]: it's still kinda wonky with zink
18:03x512[m]: gfxstrand[d]: But OpenGL has EGL extension to import Vulkan opaque FD. And it do not directly use VkImageCreateInfo. It use separate EGL fields.
18:05x512[m]: https://registry.khronos.org/OpenGL/extensions/EXT/EXT_external_objects.txt
18:07gfxstrand[d]: Yes. Everything has to be as matchy as you can
18:09x512[m]: Why no opaque FD with opaque format descriptor buffer (up to 256 bytes) extension was not made...
18:12karolherbst[d]: because then you have hardware where 256 bytes aren't enough
18:13x512[m]: On Linux DRM modifier is 64 bits max.
18:13karolherbst[d]: yeah, but modifiers are also limited
18:13karolherbst[d]: there are image objects you'd need more info than the modifier to safely share
18:14x512[m]: What Mesa developers will do if texture format description do not fit to 64 bit DRM modifier? Kernel FD attribute?
18:14karolherbst[d]: the APIs are restrictive enough that you won't run into this issue really
18:15karolherbst[d]: or the sharing simply fails
18:15karolherbst[d]: the modifier is really just tiling information and maybe a bit more
18:16karolherbst[d]: and it works good enough for sharing 2D surfaces across applications
18:18x512[m]: So you can't share GPU textures it its description to not fit to 64 bit DRM modifier. There are a chance that if texture is allocated as shareable, its format will be restricted and not optimal. Am I understanding right?
18:19karolherbst[d]: drivers do hit different paths if they know the object is shareable yes. But it usually also doesn't matter much
18:19karolherbst[d]: there are weird formats that are really hard to share
18:19karolherbst[d]: like mipmapped images
18:20karolherbst[d]: still have to figure it out for intel...
18:21karolherbst[d]: intel has the concept of an auxiliary buffer that needs to be attached and normally you don't have a great way to share all those details through the APIs
18:22karolherbst[d]: but maybe that's better with vulkan? dunno
18:44gfxstrand[d]: for simple 2D images, a 64-bit modifier plus a stride is more than enough information.
18:45gfxstrand[d]: Where it gets more complicated is when you need arrays or mipmapping 3D or whatever.
18:46x512[m]: Mipmapping 2D is fine?
18:46gfxstrand[d]: No, even mipmapped 2D can get complicated
18:47gfxstrand[d]: I mean, depending on the hardware, maybe you could do more. Like NVIDIA is pretty locked down so all you really need beyond the modifier is an array stride and you have pretty much everything covered.
18:47gfxstrand[d]: But Intel is more configurable
18:47gfxstrand[d]: And Arm is crazy configurable
18:56x512[m]: Sharing mipmaps can be useful for drawing scaled bitmap by compositor.
18:57x512[m]: Do NVK currently support mipmaps with opaque FD sharing?
18:59karolherbst[d]: I need to figure out sharing mipmaps 🥲
18:59karolherbst[d]: like...
18:59karolherbst[d]: there is this CL extension to support mitmaps, however if you also support gl_sharing (rusticl does), you also need to support importing mipmapped gl textures
18:59karolherbst[d]: it's pain
18:59karolherbst[d]: and you can like import one level or the entire thing
18:59karolherbst[d]: it's just pure madness
18:59cubanismo[d]: karolherbst[d]: Please help the WSI TSG close e.g., https://github.com/KhronosGroup/Vulkan-Docs/issues/1436 and then we'll all know the answer.
18:59x512[m]: For Haiku it is planned to use GPU bitmap sharing a lot. Client will register GPU bitmap as BBitmap object on display server side and then draw it using int32 ID.
18:59gfxstrand[d]: x512[m]: Yeah, you can do anything with opaque fd
19:00x512[m]: Display server can even use image atlas etc for read only bitmaps.
19:00x512[m]: In theory.
19:00cubanismo[d]: cubanismo[d]: But for OpenGL at least, it's ostensibly defined in the OpenGL external memory/texture/buffer extensions.
19:00karolherbst[d]: I'm a big fan of secret side-channels
19:01cubanismo[d]: Our implementation uses zero secret side channels
19:01karolherbst[d]: sounds like pain, but different kind of pain
19:02cubanismo[d]: FWIW, the D3D engineers here yelled at me when they found out how this worked (No, I didn't get proper review of the design from them at hte time), because they said it was unimplementable, but I started asking questions about why, and it turned out it was actually due to a huge bug in the D3D driver. That guy won't respond to my emails anymore.
19:03karolherbst[d]: heh
19:03karolherbst[d]: all the sharing stuff is just great
19:03cubanismo[d]: It's not that nasty to implement on NV hardware, but I've heard of terrible cases on other HW.
19:03karolherbst[d]: yeah.. nvidia is straight forward enough
19:04x512[m]: I think that secret side channels is actually a good idea because of extensibility and no need to maintain compatibility.
19:04karolherbst[d]: for cl_gl_sharing we have a private mesa extension
19:04karolherbst[d]: and that transports a lot of meta data
19:04karolherbst[d]: *metadata
19:04cubanismo[d]: As I mentioned before, I tried to warn people it probably would be, but someone raised strange concerns with my preferred approach (Something more like modifiers), and we didn't have time to convince them they were wrong.
19:04x512[m]: Stable API, unstable protocols and syscalls is Haiku design concept.
19:04karolherbst[d]: so the CL runtime pokes at the GL runtime and fetches a lot more metadata than the client provides
19:05cubanismo[d]: Yeah, that's roughly what I wanted to do, except make that side channel not secret.
19:07cubanismo[d]: Maybe some day we'll get a version 2.0. I keep trying to convince people to adopt e.g., format modifiers on windows w/opaque_win32_handle but no one's taken me up on it yet. Windows guys get pretty scared when you tell them to just \#include <some-file-from-the-linux-kernel.h>
19:07karolherbst[d]: I'm all for have proper extensions there, the thing is just, that the more we need it, the more things get added 🙃
19:07karolherbst[d]: heh
19:08karolherbst[d]: but yeah.. still need to figure out sharing mipmaps and that's gonna be a disaster
19:09x512[m]: cubanismo[d]: How Windows currently handle texture formats?
19:09x512[m]: Kernel handle private data?
19:09cubanismo[d]: Like for a VkImage mapped onto external memory?
19:12x512[m]: > Windows guys get pretty scared when you tell them to just \#include <some-file-from-the-linux-kernel.h>
19:12x512[m]: Windows protects world from Linux vendor-lock :)
19:13x512[m]: But Windows have their own vendor-lock.
19:32ermine1716[d]: Hm. Maybe i should play with my old tegra-based tablet
19:36TheHypervisor[m]: ermine1716[d]: Or a Nintendo Switch. Tegra X1 based and with a mod chip (or an older model and sw mod) you can boot into L4T and Android
19:37TheHypervisor[m]: Crazy what people did with that device
19:41HdkR: At some point that 11 year old SoC needs to be let go.
19:43ermine1716[d]: TheHypervisor[m]: I don't have one. But i have tf101
19:57airlied[d]: gfxstrand[d]: The secret is all my gmall is a spam folder 🙂
19:58gfxstrand[d]: cubanismo[d]: Yeah, NV is easy
20:01airlied[d]: Which review did I lose? 🙂
20:02airlied[d]: Also RH is pushing userspace console work again at the moment
20:02airlied[d]: But it still doesn't fully absolve you, DRM panic and log are still needed
20:03airlied[d]: So if you want to crash nicely you still need modesetting in the kernel
20:04airlied[d]: Apparently diagnostics for when your display server process dies is a requirement, also suspend/resume is a lot nicer if you can restore modes in kernel
20:06airlied[d]: As for portable drivers, uggh it's like the kernel provides all these nice cool features and fast implementations, but you can't use them sucks
20:06airlied[d]: Remember when xfree86 pretty much reimplemented libc
20:07x512[m]: VESA or UEFI GOP should be enough for kernel modesetting.
20:07airlied[d]: Like rcu and things like maple tree and writing kernel drivers in rust are way more valuable than portability
20:07airlied[d]: Spot the person who never used vesa or uefi for modesetting
20:08airlied[d]: You can set uefi gop modes after exit boot services?
20:08x512[m]: I used UEFI GOP with Nvidia 3D acceleration and it worked fine.
20:09airlied[d]: Not even sure you can reliably get two monitors to turn on
20:09x512[m]: airlied[d]: No you can't. But you are allowed to continue using already configured framebuffer.
20:09x512[m]: You need to reboot to change video mode with UEFI GOP.
20:10airlied[d]: So when would I use it post boot?
20:10airlied[d]: Pretty sure resume doesn't even go through gop
20:10gfxstrand[d]: airlied[d]: Oh, I reviewed the new modifier patches. Just waiting for James to RB the NVK ones and then I think we can land.
20:10x512[m]: UEFI GOP can be used for kernel boot splash and kernel panic.
20:11gfxstrand[d]: djdeath3483: The only two of my new WSI patches tat are missing your RB are the sync wait/signal unwrap patches
20:12airlied[d]: I remember when the xfree86 Intel driver has to use vesa modesetting instead of programming hw because Intel wouldn't find Tungsten to write native modesetting code because it was all in the bios already
20:13airlied[d]: I think reverse engineering that was years of my life I ain't getting back, so excuse me if I don't buy vesa or uefi gop line
20:14x512[m]: UEFI GOP is still probably used for Windows boot splash.
20:15airlied[d]: We use for simpledrm
20:15airlied[d]: But you can't change modes outside grub and it hardly ever does the right thing on laptops with multiple GPUs or with external monitors
20:16airlied[d]: You certainly don't want to open or close the lid
20:16airlied[d]: And it doesn't survive suspend resume at all
20:16airlied[d]: Or any GPU power mgmt
20:16airlied[d]: Which you know kinda important
20:18x512[m]: As Haiku user I know that I can live without that. Closing laptop lid usually doesn't break UEFI GOP.
20:18cubanismo[d]: airlied[d]: Yeah, mode setting in kernel seems right. Something has to arbitrate access at the very least. I think the only contentious part is how much "graphics" you want the kernel doing to e.g., draw the console. panic and log, you can pretty much assert even the slowest CPU mapping + SW rendering path is good enough.
20:18airlied[d]: As real OS with millions of users I don't get to make decisions like that
20:20airlied[d]: cubanismo[d]: yeah which is why we dropped a lot of fbcon accel, though it sucks, I think having a Vulkan/GL rendered userspace console is superior for so many other reasons, like internationalisation
20:20x512[m]: Power management is still quite broken thing even on Windows. Sometimes laptop or tablet do not wakeup at all on Windows. Or suddenly reboot if suspended with WiFi on.
20:21x512[m]: So if you want robust experience, it is better not to use it.
20:21HdkR: Windows still does slow CPU rendering for its UAC window. if you have multiple monitors at high resolution it becomes /painfully/ slow. They at least have an option to stop blanking out the monitors to improve perf a bit...
20:21airlied[d]: Having the decrypt your password prompt be in a native language is very long asked for feature 🙂
20:22airlied[d]: 4k kinda screw sw rendering of anything 🙂
20:22cubanismo[d]: Yeah, also, ~15 years ago I used to care about how fast my gentoo builds could scroll at the console. It's been a long time since I purposely did any work at the kernel console terminal. Probably since whenever X's autoconfig stuff worked 99% of the time.
20:23HdkR: airlied[d]: Dual 8k displays makes it even worse :blobsweat:
20:23airlied[d]: Now it's mostly dmesg scrolling that irk ppl
20:24airlied[d]: My desk awaits the dual 8k experience, having Linus get a 5k is already making my life harder 🙂
20:24mohamexiety[d]: actually cant wait for hidpi displays
20:25cubanismo[d]: Nothing worse than your boss/benevolent dictator actually relying on your code.
20:26cubanismo[d]: As they say, development would be a fun job if it weren't for users.
20:26airlied[d]: I can always tell the people with no users or users with no expectations, they seem to be having more fun 🙂
20:27airlied[d]: I'm tempted constantly to write a GPU stack for a rust OS :-p
20:30anholt: airlied[d]: it's finding a worthwhile rust os that's the trick.
20:31airlied[d]: Indeed too many microkernels :-p
20:31x512[m]: There are 2 types of users: users with high expectations for whom even Linux distros are unusable and only Windows or MacOS is acceptable and users with low expectations for whom Linux is too heavy/mainstream and they interested with alternative OSes.
20:32airlied[d]: I have millions of users in between 🙂
20:32gfxstrand[d]: Nah, there are a hell of a lot of users in the middle
20:32gfxstrand[d]: and a tiny number who think Linux is too mainstream
20:32gfxstrand[d]: Every kid in elementary school with a chromebook is a Linux user
20:32x512[m]: Most people I meet are in first group and see desktop Linux as a joke.
20:33gfxstrand[d]: Do they complain about it on their Android phone?
20:33x512[m]: That is not desktop Linux.
20:34gfxstrand[d]: And then drive their Tesla to the airport so they can get on a plane and watch a movie on the back of the seat.
20:34gfxstrand[d]: People don't like desktop Linux because people don't know they're using desktop Linux.
20:34airlied[d]: The driver stack is the same
20:34gfxstrand[d]: And no, android isn't Desktop linux but it still uses DRM
20:34airlied[d]: Like I think even android can use KMS
20:34airlied[d]: And Vulkan drivers are in lots of things also
20:35ermine1716[d]: Isn't android one of the reasons why linux got atomic kms?
20:35x512[m]: Android use completely different userland stack. It use separate GPU infrastructure in userland like AHardwareBuffer, separate buffer allocator instead of GBM.
20:35gfxstrand[d]: People only know about 3 things: Apple and Windows, and Android. Android is running the Linux graphics stack and everything else they buy is just a XXX device they bought and they never think about it. They're all running Linux.
20:36gfxstrand[d]: Go to a coffee shop and order a latte and a scone? That POS machine is running linux.
20:36chikuwad[d]: different userland stack doesn't mean the kernel is suddenly different too
20:36ermine1716[d]: gfxstrand[d]: Not neccessarily btw
20:36gfxstrand[d]: Might be running Android
20:36x512[m]: Android vendors use forked kernel with proprietary modules.
20:36HdkR: Some use Square with iPads these day, which is kind of nutty.
20:36airlied[d]: At least IKEA uses RHEL 🙂
20:36ermine1716[d]: Some of this stuff runs... Windows
20:37chikuwad[d]: the ones I've seen run windows with a webapp
20:37chikuwad[d]: with the browser in kiosk mode
20:37chikuwad[d]: I've set up a few myself 😅
20:37x512[m]: Many ATM and POS use Windows here.
20:37airlied[d]: Yeah square is taking over POS lately until people realise they get ripped off 🙂
20:37cubanismo[d]: OK, airlied[d], gfxstrand[d], Reviewed the NVK blackwell2 format modifier changes.
20:38airlied[d]: I originally wrote KMS for a poker machine
20:38cubanismo[d]: Should be good to go.
20:38gfxstrand[d]: Most POS I see these days are the stand-alone Square units. I'm pretty sure those are running Android.
20:38x512[m]: I see Windows 7 cursor on restaurant ticket machine.
20:38gfxstrand[d]: cubanismo[d]: airlied[d] Who do we get to merge it?
20:38ermine1716[d]: gfxstrand[d]: Rockchip loves to ship Android with their socs
20:38airlied[d]: Probably dakr will pick it up, but might be worth cc'ing him
20:38gfxstrand[d]: Okay
20:39gfxstrand[d]: But point being (re POS machines) that a billion people interact with Linux every day and never even realize it.
20:39gfxstrand[d]: So "linux graphics has no users" is bullshit
20:39cubanismo[d]: airlied[d]: He's CC'd
20:39ermine1716[d]: So $dayjob_company shipped some vending machines with terribly outdated kernel and android
20:40gfxstrand[d]: Of course they did!
20:40gfxstrand[d]: Are Android kernels ever not outdated?
20:40cubanismo[d]: cubanismo[d]: Wasn't sure if he our you would pick it up given it touches drm_fourcc.h. I don't know what the policy is there.
20:41ermine1716[d]: gfxstrand[d]: Depends on the vendor. Pixels are hopefully fine
20:41ermine1716[d]: I'm typing this from 4.19 though 😄
20:42ermine1716[d]: But the top kek imo is seeing big ad screens in metro which run X11 so they have tearing
20:42airlied[d]: my aircon controller is ancient android
20:43ermine1716[d]: Our home router has 3.x kernel
20:44x512[m]: Some POS terminals in Japan still run on national OS called B-TRON.
20:44x512[m]: But it is fading out :(
20:45gfxstrand[d]: There were a LOT of ATMs built on Windows CE back in the day
20:45gfxstrand[d]: And Windows 98 and XP and...
20:45airlied[d]: my kids tutoring is still on vista, I really hope those machines aren't networked
20:46ermine1716[d]: My local bank was running Win9x ATMs until recently
20:46gfxstrand[d]: In University we had some physics lab experiments that required us to use Windows 3.0. Not 3.1, 3.0. And Microsoft Excel for Windows 3.0.
20:47ermine1716[d]: gfxstrand[d]: Using XP is bad, not that bad actually. They still shipped updates in 2019 for POSReady
20:48steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1408553385346732113/Screenshot_20250822_154259.png?ex=68aa2910&is=68a8d790&hm=0000be0f06c1d156ec5adbff4af6617ef2abae1124454a7bcabd4f2d4a077a33&
20:48steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1408553386059632822/Screenshot_20250822_154327.png?ex=68aa2910&is=68a8d790&hm=cb38f67a823f4056d3caa379a1aeff720cc35cdf04319774ab5a1af39403e882&
20:48steel01[d]: So, I'm playing with gp10b reclocking. At higher clocks, max clock being the default state before I changed anything, I get weird scanline like brokenness. See first picture. If I clock all the way to min, it mostly goes away, though not entirely. See second picture for the expected output which I got after setting min clock. Does anyone know what might contribute to this type of broken output?
20:48x512[m]: I was involved a bit to development of special tablet for controlling industrial AC. It used Linux, Weston and Firefox-derived browser to display GUI.
20:49airlied[d]: steel01[d]: might be display pipe underruns
20:49ermine1716[d]: HPE has built RAID controller configuration utility, running on SUSE and Firefox. And it *sucks*
20:49airlied[d]: though making it slower would normally fix those not cause them
20:50airlied[d]: sorry vice versa
20:50steel01[d]: Slower is less bad. Faster makes it happen more often and worse.
20:50gfxstrand[d]: Maybe the GPU is clocking up but the memory isn't?
20:51steel01[d]: Or at least, it's 'supposed' to be faster. I'm setting gpcclk and bpmp is doing most of the magic. Which matches what nvgpu is doing.
20:51steel01[d]: gfxstrand[d]: This was one of my thoughts. Emc not right. But bpmp debugfs reports that that emc is at max rate. Given that bpmp is a black box, I just have to hope that it's telling the truth.
20:54steel01[d]: I've not tried cranking kernel drm debug to see if that complains about anything. Default levels aren't. If there were underruns, would any part of the stack report that?
20:55gfxstrand[d]: Not sure. I know Intel does but not sure about nouveau
21:21cubanismo[d]: My favorite old OS use was the inventory system at Fry's Electronics, a chain of stores where folks in Silicon Valley would go to pick up a hard drive, motherboard, RAM, etc. It ran on DOS, and they used it until they went out of business during COVID. It had some form of networking and was hooked up to some ancient printers. IIRC, towards the end, I noticed it was running either in dosbox or some
21:21cubanismo[d]: other form of emulation. The employees could jam through that thing with some ridiculous set of key combos since it didn't have any mouse support or anything. It was entirely text based.
21:23cubanismo[d]: That was the last physical store I'm aware of where you could still buy things like soldering irons and individual components like resistors/capacitors/etc. around here. Now if I need one resistor, I have to wait a week and pay $5 shipping for a $0.10 part from Digikey.
21:23HdkR: The Pizza Hut I worked at did something similar. Was entirely a custom text-based POS system running on an ancient CentOS release. The various terminals around the store just telnet in to the main "server" to put in orders. Completely keyboard based, it would just fly when putting in orders.
21:25HdkR: Some sort of Curses UI, could have multiple orders going at a time, was really good for customers that just screamed their order out as fast as possible :D
21:26cubanismo[d]: Yeah, I used to love watching the employees work through the Fry's one. I feel for the waiters pounding away at the modern super-laggy touch-screen POS machines now trying to print separate checks for everyone at a 10-person table during the dinner rush.
21:27HdkR: Feels like a nightmare working with those slow AF interfaces.
21:27cubanismo[d]: Progress.
21:29x512[m]: Business love to make GUI for this things using web technologies, so it become laggy.
21:33airlied[d]: x3270 terminals into the mainframe is the one true way
21:34HdkR: It's what made me love curses GUIs, so I agree :D
22:27gfxstrand[d]: Okay, so Talos seems fine on Blackwell. Nice 300 FPS in the benchmark with no faults.
22:37mohamexiety[d]: I should try the remaster :thonk:
22:38mohamexiety[d]: But yeah my observation today was that certain things trigger it. It’s deterministic
22:38mohamexiety[d]: It always MMU faulted in the games I tried in the exact same place
22:39mohamexiety[d]: For avatar it was the menus, for HZDR it was like 2 seconds before the benchmark ends, for Cyberpunk it was halfway through the benchmark (right before they exit the bar)
22:40HdkR: Gotta get that Cyberpunk benchmark going so I can directly compare Radxa to Thor :D
22:40mohamexiety[d]: :nervous:
22:44HdkR: Probably sometime next year since I'm not rushing to get one and can't even buy one right now anyway.
22:46gfxstrand[d]: mohamexiety[d]: For DA:TV, it faults in the shader compilation screen
22:49gfxstrand[d]: I'm installing Witcher III right now to see if that triggers
22:52mohamexiety[d]: I wonder if there’s some way to capture all the nvk calls till the fault. Then we could work backwards from there by seeing what triggers the inevitable DEVICE_LOST
22:54mhenning[d]: try with NVK_DEBUG=push_sync
22:54mhenning[d]: It's supposed to print the failing push
22:56mohamexiety[d]: Ohhh I forgot that envvar
22:56mohamexiety[d]: Could try that tomorrow. Thanks!