00:32 fdobridge: <r​edsheep> @asdqueerfromeu Conservative raster and reconvergence can be checked on the vkd3d tracker https://gitlab.freedesktop.org/mesa/mesa/-/issues/9479
00:33 fdobridge: <r​edsheep> Sources: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28388
00:33 fdobridge: <r​edsheep> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28937
00:33 fdobridge: <r​edsheep> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/features.txt?ref_type=heads#L540
00:33 fdobridge: <r​edsheep> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/features.txt?ref_type=heads#L564
00:36 fdobridge: <z​mike.> I saved https://gitlab.freedesktop.org/mesa/mesa/-/issues/11094 for an easy starter task for someone
00:43 fdobridge: <g​fxstrand> That should just be a matter of turning it on and running the tests
00:58 fdobridge: <z​mike.> yes
00:58 fdobridge: <z​mike.> like I said, easy starter task
03:44 fdobridge: <M​isyl with Max-Q Design> Done
03:46 fdobridge: <M​isyl with Max-Q Design> @gfxstrand Looks like your branch failed with rustfmt crap
03:47 fdobridge: <M​isyl with Max-Q Design> https://cdn.discordapp.com/attachments/1034184951790305330/1239786014206197760/image.png?ex=66443033&is=6642deb3&hm=b0a853790c6468f686f6bac589d0f712fc3ae4bf434516ca159d3dc1e9d557ef&
03:47 fdobridge: <g​fxstrand> Yeah, I fixed it
03:47 fdobridge: <M​isyl with Max-Q Design> oh, sorry, I didn't see marge was back on it
03:47 fdobridge: <M​isyl with Max-Q Design> I didn't get email for that... 🐸
03:48 fdobridge: <g​fxstrand> Yeah, I've not been getting all the emails either. 🤷🏻‍♀️
06:32 fdobridge: <p​avlo_kozlenko> @gfxstrand do you have a plan to realization HDR?
06:34 OftenTimeConsuming: Hmm, the 780 Ti maxes out at 2550x1440@131 - what a shame, but that seems to match the 540 Mpx/s nvidia set (but I wonder if that's an actual hardware limitation or something the VBIOS sets as punishment for not buying a "high end" card).
06:36 fdobridge: <S​id> wasn't the 780Ti the highest end card you could buy back then .-.
06:36 OftenTimeConsuming: I believe nvidia also sold "Tesla" versions which were slightly better, but triple the price.
06:39 fdobridge: <S​id> can't find anything about that, though did find Titan cards which were higher specced
06:40 fdobridge: <S​id> still don't think it's a VBIOS thing and that it's an actual bandwidth limitation
06:40 OftenTimeConsuming: I must have misremembered Titan as Tesla
06:42 fdobridge: <S​id> the only Titan card with a higher bandwidth appears to be the TITAN Z, which released a full year after the 780Ti ^^'
06:42 fdobridge: <S​id> TITAN has lower bandwidth than 780Ti, TITAN Black is equal
06:43 fdobridge: <m​agic_rb.> What bandwidth are we talking about? PCIe? Memory bus?
06:44 OftenTimeConsuming: Pixel clock
06:44 fdobridge: <m​agic_rb.> Whats that?
06:44 fdobridge: <S​id> how many pixels the GPU can push per second
06:44 fdobridge: <m​agic_rb.> Onto a screen?
06:44 fdobridge: <S​id> mhm
06:45 fdobridge: <S​id> pixel clock includes blanking btw
06:45 fdobridge: <m​agic_rb.> Blanking is? (Sorry im a but rusty on my gpu knowledge)
06:47 OftenTimeConsuming: Maybe via VBIOS modding you could set a higher pixel clock and watch the display artefact due to the hardware being pushed past specifications.
06:48 fdobridge: <S​id> pixel clock, as the name suggests, is a frequency, most commonly denoted as your display's refresh rate. blanking intervals are periods during the clock cycle during which the display is not actively drawing visible pixels but instead is preparing for the next frame
06:49 fdobridge: <S​id> two kinds of blanking too, hblank and vblank
06:49 fdobridge: <m​agic_rb.> I know vblank and hblank from CRT terminology, why is it necessary for modern displays?
06:50 fdobridge: <m​agic_rb.> And why does the gpu have to concern itself with it at all, shouldny it be internal to the display
06:51 fdobridge: <m​agic_rb.> Oh but in crt times that was the physical overscan space
06:51 fdobridge: <S​id> the display still has to get frames from the GPU, i.e. the GPU still has to be ready with the next frame withing the pixel clock
06:52 fdobridge: <S​id> s\/withing/within
06:52 fdobridge: <m​agic_rb.> So essentially were talking about the GPUs minimum frame time
06:52 fdobridge: <m​agic_rb.> (Display frame time)
06:52 fdobridge: <S​id> as for modern displays
06:52 fdobridge: <S​id> during the blanking intervals the display hardware can reset, update internal buffers, and prepare for the next frame without interfering with the visible content
06:53 OftenTimeConsuming: If this reddit poster is telling the truth, it seems like some monitors use non-standard timings that allow 2560x1440@144 or some 3rd party card VBIOS's set a higher limit; https://libreddit.strongthany.cc/r/nvidia/comments/94e4hk/pixel_clock_limits_on_kepler_maxwell_and_pascal/
06:54 fdobridge: <m​agic_rb.> Why are you trying to get 3k 144hz working on a 750ti again? Just for fun?
06:55 fdobridge: <S​id> well, like any other hardware specs, the stuff defined in the VBIOS is more of a "hey this is maximum we officially support"
06:55 fdobridge: <S​id> and OEMs are free to mess with that, afaik
06:55 fdobridge: <S​id> or at least were
06:55 fdobridge: <S​id> so, I believe there being third party vBIOS' that set a higher limit
06:55 OftenTimeConsuming: Free VBIOS for nvidia cards when?
06:56 fdobridge: <p​avlo_kozlenko> when the cancer on the mountain whistles
06:57 OftenTimeConsuming: magic_rb; I have a 2560x1440@165 monitor and I may as well have GNU Emacs run at the maximum framerate.
07:04 fdobridge: <m​agic_rb.> Good reason, emacs deserves all the frames it can get
07:05 fdobridge: <m​agic_rb.> I run mine at 240hz on my laptop screen lmao
07:05 fdobridge: <m​agic_rb.> Huh, maybe thats why it feels slightly laggy lmao
07:07 OftenTimeConsuming: Well that's nice, speed-dreams-2 no longer crashes unlike on on 770.
08:41 fdobridge: <v​alentineburley> Which tests exactly? There are no Vulkan tests that I can see so I assume it's some GL ones through Zink.
08:41 fdobridge: <v​alentineburley> And I also have another potential fix for @zmike. that I just noticed might be missing: https://gitlab.freedesktop.org/Valentine/mesa/-/commit/59642eab5a83517ccfcaca4e145b0dddfc8e2bfa
08:41 fdobridge: <v​alentineburley> Let me know if it's needed!
08:46 fdobridge: <v​alentineburley> Actually I think I should have used `;` there and `map_memory_placed` is wrong too 🤔
12:14 fdobridge: <g​fxstrand> The display bits for HDR are probably on Lyude to figure out if they aren't already in place. The Mesa stuff should be there already. IDK what the current status is with plumbing it through compositors.
12:17 fdobridge: <g​fxstrand> I was pretty sure there were legacy vertex attributes CTS tests. They might not be merged up public yet, though.
12:18 fdobridge: <v​alentineburley> I couldn't find any in either the CTS or Crucible, but I might have missed something
12:19 fdobridge: <g​fxstrand> Like I said, they might still be stuck in Khronos internal Gerrit. 😫
12:19 fdobridge: <v​alentineburley> I have a commit ready for it 😛
12:19 fdobridge: <v​alentineburley> https://gitlab.freedesktop.org/Valentine/mesa/-/commit/ebc75073a90d44fe878e16849bad10d792ee35b6
12:19 fdobridge: <g​fxstrand> They'll make their way to the public GitHub eventually.
12:26 fdobridge: <z​mike.> huh does seem like I missed that
12:26 fdobridge: <z​mike.> somehow
12:27 fdobridge: <z​mike.> 🤔
12:27 fdobridge: <z​mike.> but then how did the tests pass...
12:43 fdobridge: <v​alentineburley> I can open up an MR in a couple of hours
13:04 fdobridge: <p​homes_> I have been busy for a while but finally found some time to play with nvk again. I spent some time today looking at post_depth_coverage
13:04 fdobridge: <p​homes_> I have a patch that passes the tests but might not be the right fix. Could be a starting point to debug the issue though
13:05 fdobridge: <p​homes_> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29194
13:17 fdobridge: <m​arysaka> does all tests passes? I used to try getting that working and had some failures
13:19 fdobridge: <m​arysaka> Faith was faster than me 😄
13:29 fdobridge: <g​fxstrand> Yeah, I'm pretty sure that's still wrong.
13:29 fdobridge: <g​fxstrand> 😢
13:30 fdobridge: <g​fxstrand> There's a `SET_POST_PS_INITIAL_COVERAGE` which we're not doing anything with
13:31 fdobridge: <p​homes_> 🙂 I just found that it worked by experimenting with a few things that I guessed could be related
13:32 fdobridge: <g​fxstrand> I suspect if we set that to false it'll let us run the PS per-sample for realz
13:32 fdobridge: <g​fxstrand> But I'm not sure
13:33 fdobridge: <p​homes_> I will give it a try
13:35 fdobridge: <g​fxstrand> I actually wonder what NV does here. Do they run the fragments for uncovered things?
13:36 fdobridge: <g​fxstrand> They'd have to, right?
13:36 fdobridge: <g​fxstrand> The GL spec says:
13:37 fdobridge: <g​fxstrand> > If the fragment shader specifies the "early_fragment_tests" and "post_depth_coverage" layout qualifiers, then the sample is considered covered if and only if the sample is covered by the primitive and the sample passes the early fragment tests (as described in Section 15.2.4).
13:38 fdobridge: <g​fxstrand> I think that implies that the fragment tests happen first, incuding depth (early_fragment_tests is required for post_depth_coverage) and then the depth coverage is applied again at the end so the new coverage is a strict subset of the early coverage.
13:39 fdobridge: <g​fxstrand> Ah!
13:39 fdobridge: <g​fxstrand> ```
13:39 fdobridge: <g​fxstrand>
13:39 fdobridge: <g​fxstrand> (2) What happens if you write gl_FragDepth? What about side-effects?
13:39 fdobridge: <g​fxstrand>
13:39 fdobridge: <g​fxstrand> RESOLVED: Because the post_depth_coverage option implies
13:39 fdobridge: <g​fxstrand> early_fragment_tests, the behavior for these cases is inhereted from the
13:39 fdobridge: <g​fxstrand> basic early_fragment_tests behavior, so writes to gl_FragDepth are ignored
13:39 fdobridge: <g​fxstrand> and side effects are only executed on shaders that are executed which have
13:39 fdobridge: <g​fxstrand> already passed the early fragment operations.
13:39 fdobridge: <g​fxstrand> ```
13:40 fdobridge: <g​fxstrand> The spec was written by NV folks so the hardware can't be too funky for it
13:41 fdobridge: <g​fxstrand> Looks like `SET_POST_PS_INITIAL_COVERAGE` was also added on Maxwell B so they probably go together.
14:13 fdobridge: <t​riang3l> Oh wait oh hmmm, so OpenGL is less strict than D3D10 when it comes to vertex attributes? Is that essentially supported in (almost) all GL-compatible hardware natively, or does Gallium move vertex data somewhere for some hardware?
14:14 fdobridge: <t​riang3l> well, I think Adreno 2xx requires an alignment of 4
14:24 fdobridge: <t​riang3l> oh, PIPE_CAP_VERTEX_BUFFER_OFFSET/STRIDE_4BYTE_ALIGNED_ONLY stuff
14:24 fdobridge: <t​riang3l> 1 in R600g, 0 in RadeonSI 🤔
16:15 OftenTimeConsuming: Ultimate stunts 20-40fps, minetest 8-20fps normal 70fps underground, supertuxkart >60fps usually, supertux2 40-60fps, extreme tux racer 20-110fps, xmoto 14-120fps depending on level (it's strange as on the slow levels, turning on ugly mode doesn't seem to help much despite the lack of textures or many vertexes) and Hedgewars 120fps. I wonder why performance varies so much
16:27 fdobridge: <r​edsheep> I've spent some time trying to decipher where things are sometimes slowing down so much, but unfortunately the data from renderdoc and vkprofiler isn't as helpful as I had hoped.
16:29 fdobridge: <r​edsheep> At the end of the day though it sounds like Faith already has a pretty good idea of where things need to improve most, so I won't bother to keep digging too hard until she's got some of that future performance work implemented
16:38 OftenTimeConsuming: Hmm, I'm trying to run renderdoc but it's telling me that only OpenGL 3.2+ contexts are supported. A shame.
16:39 fdobridge: <r​edsheep> Are you running with zink? Is this on an NVK capable card, turing and up?
16:40 OftenTimeConsuming: Nope, I'm using mesa native OpenGL. It's a NVK capable card but I don't have that as NVK requires rust and Gentoo hasn't figured out how to get mesa to compile with rust yet.
16:40 karolherbst: all the GPUs supported by NVK should be at OpenGL 4.3 or something
16:42 OftenTimeConsuming: Old games don't exactly use the latest OpenGL versions. Minetest does, but captures are disabled as unsupported functions are used.
16:43 karolherbst: ahh...
16:44 OftenTimeConsuming: gltron runs at 300fps - at least the important one performs well
16:44 fdobridge: <r​edsheep> Hopefully Gentoo sorts that out soon, more often than not zink+NVK is quite a lot faster for me than the nouveau GL driver
16:45 fdobridge: <k​arolherbst🐧🦀> @redsheep https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28641 _might_ help with that in some games
16:45 OftenTimeConsuming: Can gcc rust compile NVK?
16:45 karolherbst: no
16:45 karolherbst: or probably not
16:46 OftenTimeConsuming: Compiling LLVM would max out my 128GB of RAM, so ehh.
16:46 karolherbst: why though?
16:46 OftenTimeConsuming: 32 cores and it tends to use 4GB per core somehow.
16:46 karolherbst: building it in release mode shouldn't use all that much
16:46 karolherbst: ahh 32 cores...
16:47 OftenTimeConsuming: Meanwhile gcc is pleasant to compile.
16:47 karolherbst: are you using ninja for cmake stuff?
16:47 karolherbst: because afaik it's a make limitation that you run into out of memory issues there
16:47 karolherbst: something something parallel linking
16:48 OftenTimeConsuming: It seems the ebuild uses ninja now.
16:48 karolherbst: ah
16:50 karolherbst: OftenTimeConsuming: try setting LLVM_PARALLEL_LINK_JOBS to 1
16:51 karolherbst: OftenTimeConsuming: llvm recommends 1 job per 15GB system RAM
16:51 karolherbst: I'm actually surprised that gentoo doesn't handle that part
16:52 karolherbst: maybe set it to 4 then or so
16:52 karolherbst: but anyway, that option only works with ninja
16:53 karolherbst: and if there is no cheap way to add custom cmake flags, you might have to modify your ebuild
16:53 fdobridge: <r​edsheep> Is it 32 cores, or threads? If it's 16 physical cores you could just boot with hyperthreading/SMT off if there isn't a good option to keep the ram usage down otherwise
16:54 karolherbst: gentoo allows you to restrict build jobs, but the link job flag is actually the useful way of keeping compilation speed intact
16:54 OftenTimeConsuming: I can change MAKEOPTS down, but ehh I'll just wait another 2 years for gcc rust I reckon - I don't like mystery meat binaries (rustc cannot be bootstrapped last time I checked).
16:55 OftenTimeConsuming: 32 cores, as the Opteron 6282 SE doesn't have hyperthreading.
16:55 fdobridge: <r​edsheep> Oh opteron, didn't expect that
16:56 OftenTimeConsuming: Fastest CPU that's easy to get that doesn't have signature restrictions that forbid GNUboot.
20:26 fdobridge: <g​fxstrand> @airlied Is there a good bug tracker to talk about Fedora 40 updating to Mesa 24.1?
20:28 fdobridge: <a​irlied> not really, is there a discussion needed?
20:29 fdobridge: <a​irlied> I'll probably just make it happen after a while in rawhide and see if it breaks a lot of stuff
20:29 fdobridge: <a​irlied> I think I might wait for f41 to do zink by default though
20:44 fdobridge: <k​arolherbst🐧🦀> that's going to be fun
20:44 fdobridge: <r​edsheep> Zink by default seems like it's pretty close to working well. Depending if my flicker and failed Wayland session are the same issue it's either one or two more serious bugs
20:45 fdobridge: <k​arolherbst🐧🦀> if that works well enough in fedora 41, we should just do it by default in upstream mesa
20:48 fdobridge: <r​edsheep> I've ran about 10 hours of normal usage on plasma x11 just ignoring the flicker and it was mostly fine. I did also randomly crash chromium, I think some of the mmu fault xid13 stuff is hitting in normal applications when on a zink session
20:48 fdobridge: <g​fxstrand> Mostly to make sure Mutter is fixed first.
20:48 fdobridge: <g​fxstrand> But also, Fedora 40 is shipping NVK from Mesa 24.0 which is still pretty broken.
20:49 fdobridge: <r​edsheep> I was really surprised to see that, I thought it was discussed here that it would only make sense once it was 24.1
20:49 fdobridge: <g​fxstrand> I'm less concerned with switching to Zink as I am with distros building Mesa with `nouveau-experimental`. That `-experimental` was there for a reason. 😅
20:50 fdobridge: <k​arolherbst🐧🦀> yeah...
20:51 fdobridge: <k​arolherbst🐧🦀> why was that enabled anyway?
20:54 fdobridge: <k​arolherbst🐧🦀> also the more important question is: should it be disabled?
20:54 fdobridge: <m​arysaka> https://pagure.io/mesa/c/ae25160064635a44d58bfe6027c3bc7add7c7289
20:54 fdobridge: <k​arolherbst🐧🦀> yeah, I'm not in the mood of arguing here :ferrisUpsideDown:
20:55 fdobridge: <k​arolherbst🐧🦀> if Faith says it should be disabled, then it should be disabled imho
20:55 fdobridge: <m​arysaka> I think it can be disabled, there is an option around :aki_thonk:
20:55 fdobridge: <k​arolherbst🐧🦀> I mean, we can just ask @airlied to revert that
20:55 fdobridge: <a​irlied> @karolherbst I plan on submitting a PR to do it by default in upstream mesa first
20:56 fdobridge: <a​irlied> it relies on a kernel exposing the new interface though
20:56 fdobridge: <k​arolherbst🐧🦀> mhhh
20:56 fdobridge: <k​arolherbst🐧🦀> yeah...
20:56 fdobridge: <k​arolherbst🐧🦀> that's ugly to check
20:56 fdobridge: <k​arolherbst🐧🦀> or maybe it isn't...
20:56 fdobridge: <k​arolherbst🐧🦀> depends on how it's done 😄
20:57 fdobridge: <k​arolherbst🐧🦀> but anyway... should fedora disable nvk when shipping 24.0?
20:57 fdobridge: <k​arolherbst🐧🦀> I'm kinda not in the mood telling users to disabled/uninstall it once it's shipped and users file random bug reports
20:58 fdobridge: <a​irlied> really nvk on f40 isn't doing any real heavy lifting, it's just installed and nothing in the OS really relies on it
20:58 fdobridge: <a​irlied> installing steam games sucks on nouveau anyways, I doubt anyone has expectations on nvk
20:58 fdobridge: <k​arolherbst🐧🦀> that's kinda besides the point though
20:59 fdobridge: <a​irlied> but once 24.1 lands it'll get rolled out to fedora, not sure what mutter needs fixes for though?
20:59 fdobridge: <k​arolherbst🐧🦀> if it's broken and we will tell users "don't use it" then why enabling it in the first place?
20:59 fdobridge: <a​irlied> is it just that one fix, I'll check with mutter team before rolling it out
21:00 fdobridge: <k​arolherbst🐧🦀> but if 24.1 will hit fedora40 before the release it probably doesn't matter
21:00 fdobridge: <a​irlied> enabled it to line up all the rust packaging requirements in a nice line
21:00 fdobridge: <a​irlied> f40 is like next week
21:00 fdobridge: <k​arolherbst🐧🦀> yeah.. then I don't see the point enabling nvk honestly
21:01 fdobridge: <k​arolherbst🐧🦀> users will run into issues and they will file bug reports
21:01 fdobridge: <k​arolherbst🐧🦀> there is no doubt about any of that
21:01 fdobridge: <a​irlied> feel free to MR disabling it 🙂
21:02 fdobridge: <k​arolherbst🐧🦀> *sigh*
21:02 fdobridge: <a​irlied> like they do with nvc0 🙂
21:02 fdobridge: <k​arolherbst🐧🦀> I'm not in the mood for this
21:02 fdobridge: <g​fxstrand> The mutter issue is that they have a bug with explicit sync that means NVK+modifers+nouveauGL is busted.
21:03 fdobridge: <g​fxstrand> The mutter issue is that they have a bug with explicit sync that means GNOME+NVK+modifers+nouveauGL is busted. (edited)
21:03 fdobridge: <g​fxstrand> So we just need to make sure the Mutter fix gets back-ported and someone cuts a point release before Fedora updates Mesa.
21:03 fdobridge: <a​irlied> or we just include the fix in mutter in f40 directly
21:03 fdobridge: <g​fxstrand> Sure
21:04 fdobridge: <g​fxstrand> It's only a couple lines. People are just arguing about what 3 lines to type.
21:06 airlied: uggh
21:11 fdobridge: <a​irlied> okay pushing an f40 disable
21:18 kwizart: airlied, talking about fedora mesa package, can we have this conditional (not enabled by default) https://src.fedoraproject.org/rpms/mesa/pull-request/41 ?
21:26 fdobridge: <m​agic_rb.> it still requires testing, but my usbc port was dirty which may have been causing all my recent problems, it seems to be way more stable, ethernet, usb and display out. Interestingly nouveau would report gsp faults before, now it doesnt
21:37 fdobridge: <g​fxstrand> I hate the Fermi MME...
21:48 fdobridge: <k​arolherbst🐧🦀> pat pat
21:50 fdobridge: <g​fxstrand> It tries so hard...
21:51 fdobridge: <k​arolherbst🐧🦀> which limitation are you hitting this time?
21:51 fdobridge: <g​fxstrand> 7 registers as usual
21:51 fdobridge: <g​fxstrand> That thing badly wants an RA and a spiller.
21:51 fdobridge: <k​arolherbst🐧🦀> oof
21:51 fdobridge: <k​arolherbst🐧🦀> yeah.....
21:53 fdobridge: <k​arolherbst🐧🦀> ~~just write that nir to mme compiler already~~
21:56 fdobridge: <g​fxstrand> https://tenor.com/view/hobbit-tempt-gandalf-dont-tempt-me-gif-5609024
21:56 fdobridge: <k​arolherbst🐧🦀> hey, it was your idea
21:57 fdobridge: <k​arolherbst🐧🦀> I wonder if nvidia has a LLVM based mme compiler
22:03 fdobridge: <g​fxstrand> https://tenor.com/view/mad-argh-angry-rage-smeagol-gif-11349295287195719896
22:10 fdobridge: <r​edsheep> What has you messing with Fermi?
22:11 fdobridge: <k​arolherbst🐧🦀> it's used pre Turing
22:11 fdobridge: <r​edsheep> Oh... So we're actually talking about something on Maxwell and Pascal?
22:12 fdobridge: <k​arolherbst🐧🦀> yeah
22:12 fdobridge: <k​arolherbst🐧🦀> and volta
22:14 fdobridge: <m​ohamexiety> yep. the MME is effectively a little CPU that does command buffer generation and is NVIDIA's command processor. it got a massive boost with Turing if I read the code files we have correctly
22:15 fdobridge: <k​arolherbst🐧🦀> yeah.. the turing one is actually competent. It got an imul instruction as well 😄
22:15 fdobridge: <k​arolherbst🐧🦀> I think
22:15 fdobridge: <k​arolherbst🐧🦀> not 100% sure
22:15 fdobridge: <k​arolherbst🐧🦀> ahh yeah, it did
22:16 fdobridge: <g​fxstrand> And 23 registers or something like that.
22:16 fdobridge: <g​fxstrand> Enough that you can do a lot with it.
22:17 fdobridge: <g​fxstrand> pre-Turing, you get 7. It's pretty lame.
22:17 fdobridge: <r​edsheep> Oh so the command processor is like... Actually a processor. I just kind of assumed it was like a huge version of the frontend on a cpu
22:17 fdobridge: <r​edsheep> GPU architecture docs are really hard to parse without context
22:18 fdobridge: <m​ohamexiety> oh nah it's an actual CPU. AMD's newer one (used in RDNA 3) is even straight up RISC-V, no longer a custom ISA
22:18 fdobridge: <k​arolherbst🐧🦀> gpus are pretty wild
22:20 HdkR: Falcon got replaced with RISCV, time to move the MME over to the same :P
22:20 fdobridge: <g​fxstrand> The MME is very restricted, though. It's very specifically a stream processor optimized for consuming whatever and producing command streams.
22:21 fdobridge: <g​fxstrand> It may be implemented in a bit of firmware written in RISC-V for all I know
22:21 fdobridge: <g​fxstrand> But the ISA exposed to us is pretty simple.
22:33 fdobridge: <r​edsheep> I wonder why the command processor is such a good chunk of area then if it's a fairly simple processor with very few registers
22:36 fdobridge: <r​edsheep> My basic understanding of course architecture only really tells me that a couple should get so huge when it's trying to deal with really branchy code, or trying to get really wide neither of which seems like what we're talking about
22:36 fdobridge: <r​edsheep> *of CPU architecture
22:42 fdobridge: <b​utterflies> if there's one, it's certainly not used
22:42 fdobridge: <b​utterflies> not in shipping drivers at least...
22:50 fdobridge: <g​fxstrand> The MME has very few registers. If you look at the whole GPU front-end with all the methods, it's quite a lot.
22:51 fdobridge: <z​mike.> So is F41 when I should be expecting the deluge of tickets?
22:54 fdobridge: <a​irlied> Depends on how receptive f40 is to 24.1 🙂
22:56 fdobridge: <z​mike.> Oh is that actually under consideration?
22:56 fdobridge: <z​mike.> It sounded like it wasn't
23:04 fdobridge: <a​irlied> like nvc0 isn't really quality enough, so switching users to zink is likely to improve their experience, just have to do a bit of decent smoketesting to make sure basic desktop experience doesn't regress
23:20 fdobridge: <z​mike.> trust me buddy.
23:28 fdobridge: <r​edsheep> So you're talking about if/when 24.1 comes to fedora it would default zink? Would that include fedora kde?
23:30 fdobridge: <r​edsheep> If it would turn it would definitely be a regression right now, it's not subtle. I'm sure whatever the flicker or failed Wayland session is caused by can be fixed, but if it causes normal apps to randomly hit xid13 mmu faults that seems bad
23:30 fdobridge: <r​edsheep> So far that has seemed like a tough one to address, and it's not new unlike the other issues
23:34 fdobridge: <r​edsheep> Nvc0 certainly isn't perfect but I have very rarely had something just randomly crash on it
23:34 fdobridge: <r​inlovesyou> yeah i was running it a day or two ago and random things would kill my plasma session, i'm not sure it's safe to set it as default
23:34 fdobridge: <r​inlovesyou> yeah i was running it a day or two ago and random things would kill my plasma session, i'm not sure it's safe to set it as default yet (edited)
23:35 fdobridge: <r​inlovesyou> the old nouveau opengl driver is certainly fast enough with GSP on to run x11 and wayland sessions without any issues
23:36 fdobridge: <r​inlovesyou> although for opengl *games* it would be better to have zink as the default driver
23:39 fdobridge: <r​inlovesyou> it's tricky but i think we should wait until 24.2 and work out the last kinks causing these faults before setting zink as the default
23:45 fdobridge: <r​edsheep> Do we want to open issues for these things? The reason I haven't before now is that it seemed silly to open issues for brand new code running in a non-default configuration, but if defaulting zink might happen sooner than later that logic might be wrong.
23:49 fdobridge: <r​edsheep> If we want issues for zink defaulted sessions I can think of 5 different ones I would open right now
23:53 fdobridge: <r​edsheep> @zmike. ^ Let me know if you want those issues to get opened up yet, or if I should leave it alone for now
23:56 fdobridge: <z​mike.> I don't know what the issues are
23:58 fdobridge: <z​mike.> Is a kernel with modifiers support available in fedora packaging somewhere yet?