04:47fdobridge_: <airlied> @gfxstrand I suppose we could have the kernel allow passing of kinds for dedicated allocations perhaps?
04:48fdobridge_: <gfxstrand> Yeah
04:48fdobridge_: <gfxstrand> I attached a probably broken patch above. There's a difference in the allocation loop in the two cases that I don't understand.
04:49fdobridge_: <gfxstrand> But, yeah, unless we intend everyone to always use modifiers and VM_BIND, we need to be able to create BOs with tiling information from within NVK.
04:49fdobridge_: <gfxstrand> I've got an NVK patch which does it but it depends on the kernel not rejecting them.
04:50fdobridge_: <gfxstrand> I still haven't figured out why nouveau GL is screwing up the linear case.
04:50airlied: well ideally we'd just make modifiers work
04:50fdobridge_: <gfxstrand> Modifiers aren't enough
04:50fdobridge_: <gfxstrand> Unless we switch GL to VM_BIND, the tiling on the BO still matters
04:50fdobridge_: <airlied> but can't the GL side use the modifiers to work out the kind?
04:51fdobridge_: <airlied> I'm pretty sure nouveau GL already has modifiers for some stuff
04:51fdobridge_: <gfxstrand> No because the kind on the buffer will linear and, without VM_BIND, GL has. no way to override the kind when it mapps it into its VM.
04:52fdobridge_: <airlied> yeah I'm thinking though if we stopped asking the kernel in import and took an explicit kind
04:52fdobridge_: <airlied> the kernel backchannel is something that needs to go away
04:52fdobridge_: <gfxstrand> So we have three options:
04:52fdobridge_: <gfxstrand> 1. Allow kind/mode on shared BOs
04:52fdobridge_: <gfxstrand> 2. Convert GL to VM_BIND
04:52fdobridge_: <gfxstrand> 3. Throw away the GL driver and just use Zink.
04:52fdobridge_: <gfxstrand> 4. Do something with allowing the GL driver to change the kind/mode
04:53fdobridge_: <gfxstrand> (but only within it's context because changing it globally creates a worse problem)
04:54fdobridge_: <airlied> yeah I was leaning towards 4, but 1 might be good enough
04:55fdobridge_: <airlied> gonna make me find a kepler aren't you 😛
04:55fdobridge_: <gfxstrand> 2 would probably be practical too, honestly. It could just always bind right away when in VM_BIND mode (sort of emulated old method) and wire it through so it binds based on the modifier.
04:55fdobridge_: <gfxstrand> But also, everything is kinda broken without modifiers anyway
04:55fdobridge_: <airlied> yeah we just don't have bo lists which might cause some odd gl behaviour changes
04:56fdobridge_: <gfxstrand> Nouveau GL re-calculates both the kind and the tile_mode and ignores whatever's set on the buffer.
04:56fdobridge_: <airlied> though I doubt nouveau GL is used in enough places where that matters
04:57fdobridge_: <gfxstrand> Honestly, I'm kinda inclined to say we should implement modifiers in Zink and throw away the GL driver. 🤡
04:58fdobridge_: <gfxstrand> Properly detangling this mess is going to be a nightmare.
04:59fdobridge_: <airlied> so what's the reproducer, just display something with nvk on a kepler?
04:59fdobridge_: <gfxstrand> Yup
04:59fdobridge_: <gfxstrand> vkmark works
05:00fdobridge_: <gfxstrand> except I need to push some patches because I blew up pre-Volta a couple weeks ago
05:00fdobridge_: <gfxstrand> So roll back to before the DMA shader upload MR
05:05fdobridge_: <airlied> in something unrelated, do you think PTX->NIR is possible without having an AST?
05:06fdobridge_: <gfxstrand> Or pull https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27565
05:06fdobridge_: <gfxstrand> I suspec it'll need as much AST as SPIR-V but I don't know for sure. It'll depend on what the bytecode format looks like.
05:07fdobridge_: <gfxstrand> The good news is that PTX is mostly scalar so it won't need all the crazy type mangling.
05:07fdobridge_: <gfxstrand> It also doesn't use variables so that part is easier, too.
05:11fdobridge_: <gfxstrand> I suspect it'll need as much AST as SPIR-V but I don't know for sure. It'll depend on what the bytecode format looks like. (edited)
05:12fdobridge_: <gfxstrand> The bigger question is how many crazy custom ops and intrinsics it'll need to communicate the detailed NV behavior without significant loss of information.
05:15fdobridge_: <airlied> cross that bridge once we can even parse it 😛
05:17fdobridge_: <airlied> okay I have a broken vkcube
05:19HdkR: cubins are fairly easy to parse. Shouldn't take too long :)
05:20HdkR: They're just ELF files with custom sections which are trivial to RE what each are for
05:22airlied: HdkR: there is a vulkan extension to just take ptx
05:22HdkR: Oh snap, even nicer
05:23airlied: though it's possible a bit underspecified :-P
05:23airlied: but it's a probably easier starting point
05:25HdkR: `pData is a pointer to CUDA code` wha
05:25HdkR: Very interesting
05:26HdkR: Probably a lot easier than creating a new CUDA ELF loader that I had to do :D
05:34fdobridge_: <gfxstrand> Yeah, I'm all for building a PTX parser, at least as a prototype. Once we know what form it'll take, we can figure out whether or not we want to ship it and how.
05:35fdobridge_: <gfxstrand> RE the extension: it's also a kernel dispatch extension which does a CL-style dispatch with arguments instead of descriptor sets. That probably makes the mapping to PTX easier. It also opens the door for a CL dispatch extension.
05:43fdobridge_: <airlied> how are we for constructing NIR from rust these days?
05:44fdobridge_: <prop_energy_ball> Having some parts of the stack not use explicit modifiers is always a disaster. See: Flatpak x Radeon SI when Marek wanted to use a better modifiet mode by default, but it broke a fuckload of assumptions elsewhere. IMO it would be wise to not make that mistake.
05:44fdobridge_: <prop_energy_ball> Having some parts of the stack not use explicit modifiers is always a disaster. See: Flatpak x Radeon SI when Marek wanted to use a better modifiet mode by default, but it broke a fuckload of assumptions elsewhere when mixing and matching. IMO it would be wise to not make that mistake. (edited)
05:45fdobridge_: <prop_energy_ball> Now is a good opportunity to not do... that and be locked into it for compat reasons e_e
05:45fdobridge_: <prop_energy_ball> Having some parts of the stack not use explicit modifiers is always a disaster. See: Flatpak x Radeon SI when Marek wanted to use a better modifier by default, but it broke a fuckload of assumptions elsewhere when mixing and matching. IMO it would be wise to not make that mistake. (edited)
05:47fdobridge_: <ishitatsuyuki> idk, but since the nir builders are done with codegen we can probably build a rust version of that?
05:48fdobridge_: <prop_energy_ball> Once NVK has modifiers hooked up I am definitely interested in trying Gamescope and SteamOS stuff there with Zink
05:49fdobridge_: <gfxstrand> Bindgen the builder and enable inlines
05:50fdobridge_: <airlied> so option 5 is have the GL driver submit kinds with each BO submission
05:51fdobridge_: <gfxstrand> Yeah, that might be easier than switching it to a whole new kernel API.
07:26fdobridge_: <airlied> uggh starts to get ugly fast in the kernel though, might have to consider just letting the vk side set kind on some bos
08:31fdobridge_: <pavlo_it_115> On the one hand, it would be more progressive to use zink. On the other hand, where to throw away so much work invested in GL... Try the Allow kind/mode on shared BOs
13:11fdobridge_: <gfxstrand> That's certainly the lazy approach.
13:13fdobridge_: <gfxstrand> Unfortunately, even with the lazy approach, we probably need to fix nouveau somewhat. It's really hard for me to read what's going on in the code on import but I'm not sure it's actually consistent in it's usage of the BO tiling information.
13:14fdobridge_: <gfxstrand> Also, with modifiers I don't think it's really valid to require any metadata.
13:32fdobridge_: <gfxstrand> I'm going to spend a bit of time digging into the mess this week to figure out how bad it is. I kinda suspect nouveau GL is well and thoroughly cursed all over.
13:33fdobridge_: <gfxstrand> And I doubt modifiers fix any of it because I don't think James knew how cursed it was when he was implementing them and I don't think anyone was thinking about all these interactions in review, either.
14:54fdobridge_: <zmike.> great news, cuz modifiers in zink already work fine
14:55fdobridge_: <karolherbst🐧🦀> the way to fix modifiers in the GL driver is to nuke the tegra driver first and use kmsro, then to fix modifiers in the gl driver....
14:55fdobridge_: <karolherbst🐧🦀> every patch touching this area regresses something somewhere
14:55fdobridge_: <karolherbst🐧🦀> it's annoying
14:56fdobridge_: <gfxstrand> Yeah
14:56fdobridge_: <gfxstrand> I was looking at that code and it scares me
14:56fdobridge_: <karolherbst🐧🦀> "make it work with kmsro" is more actionable then "balance fixing nouveau and tegra until it kinda works" because `kmsro` is a defined state
14:56fdobridge_: <karolherbst🐧🦀> well "defined"
14:56fdobridge_: <karolherbst🐧🦀> you get the idea
14:57fdobridge_: <karolherbst🐧🦀> but when I tried to delete `kmsro` uhh...
14:57fdobridge_: <karolherbst🐧🦀> I got exhausted by the discussion around that
15:00fdobridge_: <karolherbst🐧🦀> welll..... "registers" are actually array variables
15:00fdobridge_: <karolherbst🐧🦀> though not sure how that looks like in the PTX binary
15:01fdobridge_: <karolherbst🐧🦀> or do you mean variables in the "input/output" sense?
15:01fdobridge_: <karolherbst🐧🦀> because those also exist
15:01fdobridge_: <karolherbst🐧🦀> we kinda have to treat PTX as a high level language which lacks a few features, and that's the annoying part. However... the binary format might be less annoying to parse
15:02fdobridge_: <karolherbst🐧🦀> and speaking of which.. zluda got a code dump, $because reasons
15:02fdobridge_: <karolherbst🐧🦀> but it translates ptx to llvm
15:02fdobridge_: <mohamexiety> zluda was really funny tbh
15:02fdobridge_: <mohamexiety> https://cdn.discordapp.com/attachments/1034184951790305330/1206616434659041322/image.png?ex=65dca81f&is=65ca331f&hm=7d8535946eb644febf90ffb0f3afb66ebeec66891eef05dede30c451b5527aae&
15:03fdobridge_: <mohamexiety> https://github.com/vosen/ZLUDA/commit/1b9ba2b2333746c5e2b05a2bf24fa6ec3828dcdf
15:03fdobridge_: <karolherbst🐧🦀> yeah...
15:03fdobridge_: <karolherbst🐧🦀> not sure there is _anything_ useful for us besides the PTX parser
15:03fdobridge_: <mohamexiety> > Andrzej Janik spent the past two years bringing ZLUDA to Radeon GPUs and it works: many CUDA software can run on HIP/ROCm without any modifications -- or other processes... Just run the binaries as you normally would while ensuring that the ZLUDA library replacements to CUDA are loaded. For reasons unknown to me, AMD decided this year to discontinue funding the effort and not release it as any software product. But the good news was th
15:03fdobridge_: <mohamexiety> I really don't understand the logic behind them dropping it honestly
15:03fdobridge_: <mohamexiety> because they went ahead and did the same thing with HIP so they could've carried over the work
15:03fdobridge_: <karolherbst🐧🦀> and this "intel/AMD did see now business case for running native CUDA apps" also sounds like "this implementation didn't meet expectations"
15:04fdobridge_: <karolherbst🐧🦀> the thing is... CUDA is an ecosystem
15:04fdobridge_: <karolherbst🐧🦀> there is a lot more to it than to just run a handful of applications
15:07fdobridge_: <karolherbst🐧🦀> oh wow...
15:07fdobridge_: <karolherbst🐧🦀> it parses ptx as text...
15:08fdobridge_: <karolherbst🐧🦀> and the build system is a mess :ferrisUpsideDown:
15:09fdobridge_: <gfxstrand> Yeah, I mean in the input/output sense. And also the sense of having struct types and stuff like that.
15:09fdobridge_: <karolherbst🐧🦀> okay.. ptx doesn't have structs, but you can declare global variables, like for images
15:10fdobridge_: <karolherbst🐧🦀> with format/etc... information
15:10fdobridge_: <gfxstrand> Oh, well that's easy
15:10fdobridge_: <mohamexiety> it's a one person effort so it feels impressive tbh
15:10fdobridge_: <karolherbst🐧🦀> yeah sure
15:10fdobridge_: <karolherbst🐧🦀> however especially because it's a one person effort I'd go different about it
15:10fdobridge_: <gfxstrand> It's arrays and structs and that whole mess which is why like 60% of the `spirv_to_nir` "AST" exists.
15:10fdobridge_: <karolherbst🐧🦀> yeah...
15:10fdobridge_: <karolherbst🐧🦀> well..
15:11fdobridge_: <gfxstrand> And then like 30% is control-flow
15:11fdobridge_: <karolherbst🐧🦀> "registers" don't exist in ptx
15:11fdobridge_: <karolherbst🐧🦀> it's all arrays
15:11fdobridge_: <gfxstrand> arrays are easy enough
15:11fdobridge_: <karolherbst🐧🦀> at least only of primiteve types
15:11fdobridge_: <karolherbst🐧🦀> *primitives
15:11fdobridge_: <karolherbst🐧🦀> yeah..
15:11fdobridge_: <karolherbst🐧🦀> not having to deal with structs is huge
15:11fdobridge_: <gfxstrand> Yup
15:11fdobridge_: <gfxstrand> That's the big one
15:11fdobridge_: <gfxstrand> If it's "give me N registers as an array", that's trivial.
15:12fdobridge_: <karolherbst🐧🦀> PTX also has jumps, but.. we have a solution for that :ferrisUpsideDown:
15:13fdobridge_: <gfxstrand> Yup
15:15fdobridge_: <karolherbst🐧🦀> actually... it kinda looks like there is no binary form of PTX?
15:15fdobridge_: <karolherbst🐧🦀> mhhhh
15:16fdobridge_: <gfxstrand> Really? That surprises me a bit
15:16fdobridge_: <gfxstrand> Wait... there has to be. LLVM can generate it.
15:16fdobridge_: <gfxstrand> Or is LLVM generating text PTX?
15:16fdobridge_: <karolherbst🐧🦀> I wonder
15:18fdobridge_: <karolherbst🐧🦀> indeed...
15:18fdobridge_: <gfxstrand> 🤨
15:18fdobridge_: <karolherbst🐧🦀> I mean..
15:18fdobridge_: <karolherbst🐧🦀> that just makes it easier
15:19fdobridge_: <gfxstrand> Yeah
15:19fdobridge_: <gfxstrand> We could probably write a PTX parser without that much effort. Dealing with text is just annoying.
15:19fdobridge_: <karolherbst🐧🦀> yeah..
15:19fdobridge_: <karolherbst🐧🦀> I wonder if nvidia has tests for their ptx vulkan extension 😄
15:20fdobridge_: <gfxstrand> In the CTS? Probably not
15:20fdobridge_: <karolherbst🐧🦀> I mean.. even a demo app would be a good starting point
15:20fdobridge_: <karolherbst🐧🦀> I got an intern assigned to me, I wonder what they'll end up working on :ferrisUpsideDown:
15:29fdobridge_: <gfxstrand> Given that PTX is text, I think we probably need some sort of AST for it.
15:29fdobridge_: <gfxstrand> Just, ya'know... In case there is an intern... Pass that on. 😉
15:30fdobridge_: <gfxstrand> Probably doesn't need a whole giant IR but something that puts stuff in standardized data structures and maybe sorts out what's an input and what's an output before we try to go into NIR.
15:37fdobridge_: <karolherbst🐧🦀> I mean.. that's where the zluda stuff comes in. We could probably copy&paste the PTX parser and AST part
15:38fdobridge_: <gfxstrand> Yeah, possibly
15:39fdobridge_: <gfxstrand> That sounds unlikely to be a good idea from a maintenance PoV, though.
15:40fdobridge_: <karolherbst🐧🦀> right.. we probably don't want to literally copy&paste everything
15:40fdobridge_: <karolherbst🐧🦀> maybe writing it from scratch is better (and add proper documentation while at it)
15:40fdobridge_: <karolherbst🐧🦀> but probably good enough to get an idea how it's all working
15:41fdobridge_: <karolherbst🐧🦀> though not sure it's a good project for an intern anyway, kinda depends on what they know and worked on before
15:41fdobridge_: <karolherbst🐧🦀> as I have no idea about that :ferrisUpsideDown:
15:41fdobridge_: <karolherbst🐧🦀> I wonder if LLVM can compile OpenCL C to PTX...
15:42fdobridge_: <karolherbst🐧🦀> and I wonder if we want to translate PTX to SPIR-V or NIR directly...
15:42fdobridge_: <karolherbst🐧🦀> probably NIR though
15:43fdobridge_: <karolherbst🐧🦀> or maybe SPIR-V wouldn't be too bad if one assumes bda?
15:43fdobridge_: <karolherbst🐧🦀> and uhhh.. that shared memory aliasing thing
15:44fdobridge_: <karolherbst🐧🦀> the annoying part of PTX is, that you don't know if you have indirects on your "registers" until you hit them and that's going to be pain no matter hwat
15:45fdobridge_: <karolherbst🐧🦀> so first step in any translation is to split those declared register arrays anyway
16:43fdobridge_: <karolherbst🐧🦀> okay.. met with the intern, no experience in compiler or GPU stuff :ferrisUpsideDown: I guess writing a PTX parser might be too steep for now
17:12fdobridge_: <gfxstrand> It can compile Fortran to PTX.
17:13fdobridge_: <gfxstrand> Yeah, as much fun as adding PTX to SPIRV-Cross sounds, let's just parse it and dump out NIR.
18:00fdobridge_: <airlied> Zluda uses a rust parser library
18:01fdobridge_: <airlied> Lalrpop but it has deps like lots of them
18:01fdobridge_: <airlied> Like uggh mesa would not be happy deps
18:02fdobridge_: <airlied> I looked at nom and combine also, ptx parser exists using nom but I'd probably just rewrite it to create an AST
18:03fdobridge_: <airlied> And yeah there is no binary format just txt
18:03fdobridge_: <airlied> Zluda on nouveau would be the best target 🙂
18:09fdobridge_: <karolherbst🐧🦀> not sure if zluda on anything is a viable target at all
18:09fdobridge_: <karolherbst🐧🦀> given that it was apparently easier to nuke all Intel support to support HIP/ROCm
18:10fdobridge_: <karolherbst🐧🦀> so I assume there are almost no abstractions going on
18:10fdobridge_: <karolherbst🐧🦀> I wouldn't be surprised if the ptx thing compiles to amdgpu llvm directly even
18:17fdobridge_: <airlied> Well the first iteration went to spirv but no idea what the new one does
18:18fdobridge_: <karolherbst🐧🦀> directly to llvm
18:18fdobridge_: <airlied> @gfxstrand I think to fix modifiers properly for GL needs VM_BIND port
18:19fdobridge_: <gfxstrand> Yeah...
18:19fdobridge_: <airlied> So i think all in on zink 🙂
18:19fdobridge_: <gfxstrand> Honestly, that answer is starting to sound better and better.
18:19fdobridge_: <gfxstrand> The semi-fake modifiers that are there now will keep working in GL for Fermi and earlier.
18:20fdobridge_: <airlied> The metadata is set once at create and it uses modifiers but importing has now way to use them
18:20fdobridge_: <airlied> The metadata is set once at create and it uses modifiers but importing has no way to use them (edited)
18:20fdobridge_: <karolherbst🐧🦀> the thing is.. for fermi and earlier it's also entirely irrelevant :ferrisUpsideDown:
18:20fdobridge_: <airlied> Since you can't convert modifier to mind and give it to the kernel on an imported bo
18:21fdobridge_: <airlied> Since the bo kind is fixed in kernel at bo creation
18:21fdobridge_: <gfxstrand> How does this all play with KMS?
18:21fdobridge_: <gfxstrand> Or is it all linear?
18:21fdobridge_: <airlied> Since you can't convert modifier to kind and give it to the kernel on an imported bo (edited)
18:21fdobridge_: <airlied> Plays fine since the metadata carries the info
18:22fdobridge_: <airlied> And imports ignore modifiers
18:22fdobridge_: <airlied> Which is fine if you have nouveau talking to nouveau 🙂
18:24fdobridge_: <redsheep> For all the stuff I've been playing with zink already works so much better than the nouveau GL driver anyway, conformance and that weird depth issue aside. The performance is massively better.
18:24fdobridge_: <airlied> Talking to i915 is linear of course
18:24fdobridge_: <gfxstrand> Yeah, but that's not at all "fine"
18:25fdobridge_: <airlied> I want to consider adding something to loader to let a GPU specific driver say, just use zink instead
18:25fdobridge_: <gfxstrand> It's sounding like KMS has exactly the same set of issues that we have with GL running the compositor today. Throw away the modifier, trust the PTE bits, corrupt everything when NVK gives you a buffer.
18:25fdobridge_: <karolherbst🐧🦀> couldn't the driver just fail to load and zink takes over?
18:26fdobridge_: <karolherbst🐧🦀> or we just return `PIPE_SCREEN_USE_ZINK` instead of `NULL` when creating a `pipe_screen`?
18:26fdobridge_: <karolherbst🐧🦀> but yeah
18:26fdobridge_: <karolherbst🐧🦀> torch the gl driver
18:26fdobridge_: <airlied> If that works then having nouveau refuse to bind would be good
18:27fdobridge_: <gfxstrand> This is the thing that scares me. We've built a LOT of software assuming that tiling/kind bits go in the BO and it's clear that we haven't flushed it all out yet. GL is just one piece. If KMS is also doing that then we're kinda screwed again.
18:28fdobridge_: <pavlo_it_115> per pascal, zink works more slowly than native gallium GL
18:28fdobridge_: <gfxstrand> The thing that saves us today is that NVK is always doing linear for display images. Always.
18:29fdobridge_: <gfxstrand> But that's busted with Kepler because GL tries to tile the linear things. 🤡
18:29fdobridge_: <karolherbst🐧🦀> pain
18:29fdobridge_: <gfxstrand> I'm still not sure how busted. That's the next task once I get some e-mail cleared away.
18:30fdobridge_: <karolherbst🐧🦀> yeah... every time I looked at it I was like "this can't be right" but uhhh.. this is all painful
18:30fdobridge_: <airlied> I'm not sure why that is busted with Kepler and not Maxwell, I couldn't spot any obvious Kepler specific paths but I didn't look too long
18:30fdobridge_: <karolherbst🐧🦀> and again, then comes the tegra driver into place and when you change something, tegra doesn't work anymore
18:30fdobridge_: <karolherbst🐧🦀> something on the kernel side?
18:31fdobridge_: <gfxstrand> I think it's because Kepler has tiling even more tied into the PTEs. My theory is that the Maxwell+ sampler ignores the PTE bits and trust the descriptor while Kepler likes to follow the PTE bits always. Something like that.
18:32fdobridge_: <karolherbst🐧🦀> ohhh.. that might be the case
18:32fdobridge_: <gfxstrand> And on Kepler, I don't think `pte_kind=0` means linear. It's something like `0xfe`
18:32fdobridge_: <karolherbst🐧🦀> or maybe some magic bit in the tex header?
18:32fdobridge_: <gfxstrand> But, yeah, I need to dig.
18:32fdobridge_: <karolherbst🐧🦀> does it happen on maxwell 1st gen using keplers tex headers?
18:32fdobridge_: <gfxstrand> IDK. I've not tried that.
18:33fdobridge_: <gfxstrand> I've got a Maxwell A sitting here. I've got Kepler and Ampere plugged in right now.
18:33fdobridge_: <karolherbst🐧🦀> I had some code somewhere to flip it, but we never landed it 😄 but it shouldn't be too hard to code something
18:33fdobridge_: <karolherbst🐧🦀> `NVB097_SET_SELECT_MAXWELL_TEXTURE_HEADERS` is the toggle anyway
18:34fdobridge_: <karolherbst🐧🦀> and I think it only works on 1st gen maxwell?
18:34fdobridge_: <gfxstrand> If we can at least un-break the linear case, that will help.
18:34fdobridge_: <gfxstrand> It's still not ideal but gets rid of the rendering corruptions we're seeing today.
18:34fdobridge_: <karolherbst🐧🦀> or maybe it is false on 1st gen maxwell
18:34fdobridge_: <karolherbst🐧🦀> dunno
18:34fdobridge_: <karolherbst🐧🦀> something something
18:34fdobridge_: <gfxstrand> The thing that really scares me, though, is display.
18:35fdobridge_: <gfxstrand> If KMS is going to ignore modifiers and trust BO bits, we have a real problem.
18:35fdobridge_: <karolherbst🐧🦀> knowing it's something with the tex descriptor would definitely help
18:35fdobridge_: <karolherbst🐧🦀> yeah...
19:27fdobridge_: <airlied> @gfxstrand zluda phoronix benchmarks didn't seem to suggest the perf is too horrible
20:06Lyude: dakr: btw, I assume we want to drop any of the interfaces from the commits I've pulled into rvkms's tree so far that aren't (and likely won't be) used? seems like I can remove at least half the platform interface since we only use a little bit of it
20:07Lyude: as in - modifying the commits themselves to drop unused interfaces, vs. just dropping individual commits
20:38Lyude: (I will assume so since that's what I remember from our meeting, but I have kept a backup branch in case I'm wrong :)
20:57Lyude: dakr: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rvkms-base cleaned everything up and make sure every commit compiles, and got rid of anything unneeded. I should note: I'm not 100% confident on some of the changes to the drv registration stuff that I made, so don't be afraid of modifying that if needed for nova.
21:07fdobridge_: <gfxstrand> @mohamexiety FYI: I landed the pre-Volta fixes so Pascal should be working again. Sorry about that.
21:09fdobridge_: <mohamexiety> thanks a lot! all good, I just moved to Ampere for the meanwhile
21:09fdobridge_: <gfxstrand> Okay
21:17fdobridge_: <airlied> @gfxstrand looks like kms extracts kind from the modifier path if it is given a modifier
21:18fdobridge_: <gfxstrand> Okay, cool.