05:21 fdobridge: <a​irlied> @gfxstrand on non-REBAR shouldn't we expose two heaps like NVIDIA?
05:24 fdobridge: <g​fxstrand> Maybe? But then we still have to fight with contention.
05:25 fdobridge: <a​irlied> yeah but it allows app to make smarter decisions, and since amd and nvidia both expose it like that I assume apps might care
05:26 fdobridge: <a​irlied> I'm just trying to track down why it all dies here, I'm seeing it die without even seeing any bo's being moved into visible space
05:26 fdobridge: <g​fxstrand> Oh, yeah, apps will definitely use it. Blocking it behind the BAR size is definitely a stop-gap
05:27 fdobridge: <g​fxstrand> I'll probably continue using an upload queue on small-BAR GPUs but we should be good to advertise a BAR heap once things are stable.
05:28 fdobridge: <g​fxstrand> We've also got some sort of nasty leak in nouveau.ko that I'm planning to start looking at tomorrow or Tuesday.
05:29 fdobridge: <g​fxstrand> This ☝🏻
05:48 fdobridge: <a​irlied> Sounds like a possible accounting problem
06:04 fdobridge: <g​fxstrand> Possibly? I'm not sure how that's possible, though. I need to dig into it. Or you can.
06:05 fdobridge: <g​fxstrand> But that one feels like one I can probably tackle if I've got the time.
07:04 fdobridge: <a​irlied> looks like a scaling problem somewhere
07:04 fdobridge: <a​irlied> I just added some debugfs bits and it's wrong there
07:06 fdobridge: <a​irlied> apparently usage is in bytes, which isn't consistent
07:38 fdobridge: <a​irlied> just sent a fixup patch to the list
08:14 fdobridge: <a​irlied> okay I figured out the proper evicting path, and yes once that gets hit, things explode
09:20 fdobridge: <!​DodoNVK (she) 🇱🇹> Is this the path when the BAR gets full?
09:36 fdobridge: <j​ohn454545> Just to add my two cents, but I recommend faking the driver version instead, as Baldur's Gate 3 for example has Nvidia specific features such as DLSS which will hopefully work with nvk in the future with some PTX magic down to line. Not reporting Nvidia as the vendor would prevent these from working.
10:15 fdobridge: <a​irlied> yes
10:16 fdobridge: <a​irlied> okay found some small bugs, but haven't found the big problem, will dig more tomorrow
10:29 maybebaby: https://github.com/UCHI-DB/sboost it's part of their codecdb engine, they implement all possible methods of compression, the method I had in mind was dictionary based method, but though that works, the bigger initiative would be to match operator intrinsic stack to that compressed domain, for that I need to wrap my head around that subject for couple of weeks more.
10:31 maybebaby: Just read the code and PDF. I got a bit tournaments to play in this week, will be trailing behind I assume.
14:07 fdobridge: <g​fxstrand> Oh, well that'll do it
15:03 fdobridge: <d​adschoorse> > vulkan/meat: Handle VK_REMAINING_ARRAY_LAYERS in blit and resolve
15:03 fdobridge: <d​adschoorse> 🐸
15:04 fdobridge: <g​fxstrand> Fixed
16:07 Lyude: karolherbst: I'll see if I can look into it, I think I should still have a fermi GPU lying around somewhere
16:08 Lyude: also - making more progress on rvkms I think :). Was actually able to work on it during my flight to Sweden and back
16:08 Lyude: (also currently typing from a plane lol)
16:09 Lyude: So many types to come with before I can even start testing to see if I have any of the modesetting stuff working yet
16:09 karolherbst: Lyude: btw, there is a user with a very annoying bug.. like newer kernels ditching modes
16:10 Lyude: boo
16:10 Lyude: but gotcha, could you link?
16:10 Lyude: hm. just realized getting a fedora VM setup is probably something I should have done before the plane and not on the plane
16:11 karolherbst: Lyude: https://gitlab.freedesktop.org/drm/nouveau/-/issues/310#note_2297792
16:11 karolherbst: ehh
16:11 karolherbst: not the comment, but uhh
16:11 karolherbst: anyway, I hope there are enough logs
16:11 Lyude: all these fermi issues huh
16:12 Lyude: fermi/tesla
16:12 karolherbst: yeah...
16:27 Lyude: btw karolherbst - the pinning guarantee mentioned on the documentation for Arc<T> should be good enough if T has self-referential pointers (specifically for an intrusively linked list) so long as we actually initialize T in place, correct?
16:29 karolherbst: Lyude: if T references itself you can't really allocate it in place, unless you mean it references to other instances of T
16:30 Lyude: karolherbst: no it references itself, the kernel does have "in-place initializers" for this sort of thing though: https://rust-for-linux.github.io/docs/v6.8-rc3/kernel/init/trait.InPlaceInit.html#tymethod.try_init
16:30 Lyude: as well, we don't actually assign those pointers until after the Arc has been allocated
16:31 karolherbst: mhh normally there is Arc::new_cyclic for this kinda of uses cases
16:31 Lyude: Oh-no I think I misexplained myself
16:31 Lyude: T contains a ffi struct which references itself
16:31 karolherbst: ahhh
16:31 Lyude: The Arc is really just to handle some lifetime silliness between drm and rust
16:31 Lyude: so pretty much the entirity of drm just has one reference that it gets from Arc::into_raw()
16:32 karolherbst: I see
16:32 karolherbst: yeah.. then I guess Init is the thing to use there
16:33 karolherbst: just dealing with pointers directly is always kinda pain. _but_ Arc more or less does a heap allocation anyway, though not sure if that's actually guaranteed, but would be cursed if not
16:33 karolherbst: and pointers to the data hold my an Arc kinda have to be stable anyway
16:33 Lyude: makes sense
16:34 karolherbst: meaning Arc is defacto Pin, even though it's kinda not declared as such
16:34 karolherbst: Arc also has pretty strict semantics around &mut refs
16:34 Lyude: yeah - which actually kind of ends up being perfect for this
16:35 karolherbst: yeah.. I only use Arc<T> for rusticl and I had 0 issues with handing out pointers to C runtimes for those, but the CL types are also opaque so only the rust side actually accesses data, but still has to do Arc::into_raw and Arc::from_raw
16:36 karolherbst: Lyude: though.. one thing you should be aware of with Arc, that Arc::from_raw does _not_ increase the ref count
16:36 Lyude: since the majority of stuff in drm_plane, drm_connector, etc. falls into one of these groups: statically assigned during driver creation, protected by some other lock (which we can get mutation through, also counting "within a modeset" as a lock since we'll have an actual container type for representing that),
16:36 Lyude: karolherbst: but it does leak our current increment until we piece the arc back together later with from_raw(), correct?
16:36 karolherbst: so if you temporarily construct an Arc out of a pointer and you drop it (without calling into_raw again) it its ref count decreased
16:37 Lyude: ah gotcha, yeah I've been careful to make sure not to do that
16:37 karolherbst: I have wrapper functions for that in rusticl
16:37 karolherbst: arc_from raw which calls Arc::increment_strong_count + Arc::from_raw
16:38 karolherbst: and ref_from_raw which only returns a reference
16:38 karolherbst: like.. casting the pointer to a ref
16:38 karolherbst: so if you need to increase the ref count, you ask for an Arc, and if not you simply get a ref
16:39 karolherbst: and calling Arc::into_raw again just causes leaks in the worst case, but won't cause use-after-frees
16:41 Lyude: so: luckily the way I'm going to be handling this is that the increment thta DRM owns is going to last through the entire lifetime of drm_device
16:42 karolherbst: ahh
16:42 karolherbst: then you really only need to operate on the reference and not Arc<T> anyway
16:42 Lyude: the arc is only really there to handle the fact that -technically- it's possible for the driver to hold a reference to a Plane<T> or Crtc<T> even after registration has finished, or could drop the references it made to a Plane<T>/etc. immediately after device registration
16:43 karolherbst: right...
16:43 karolherbst: but yeah.. you don't really have to call Arc::from_raw there as the only point of doing so is if you really need an Arc
16:43 Lyude: karolherbst: I'm not really sure how we'd get a proper reference without tying the lifetime to a single ARef<drm::Device>
16:43 karolherbst: just cast the pointer to one
16:44 Lyude: oh huh
16:44 karolherbst: there is pointer::as_ref as well
16:44 karolherbst: which only checks for null and maybe alignment? dunno
16:44 karolherbst: nah.. just null
16:44 karolherbst: but yeah.. that's obviously unsafe, but so is Arc::from_raw
16:44 Lyude: yeah but that could still leave us with dangling references after drm calls drm_plane_funcs->destroy
16:45 karolherbst: sure, if you need to take a ref, you'd store an Arc<T> anyway
16:45 Lyude: that's the weird lifetime bit
16:45 karolherbst: but like Arc::from_Raw also doesn't protect you against something destroying the Arc in another thread
16:45 karolherbst: because it doesn't incrase the ref count
16:46 karolherbst: none of this solves the "only one owns this reference"
16:46 Lyude: note: the actual implementing driver gets its own reference to the Arc as well
16:46 Lyude: so: one reference on the rust side, one on the drm side
16:46 karolherbst: right
16:47 Lyude: and that is done via clone()
16:47 karolherbst: yeah, just saying that the semantics aren't intuitive enough to get right
16:47 karolherbst: yeah
16:47 karolherbst: Arc::clone creates a new ref for real
16:51 Lyude: i wonder if I can push this code to a repo for a sec from above the ocean
16:51 Lyude: My connection keeps being very flaky though,
16:51 Lyude: oh hey there I am
16:53 Lyude: ok let's hope :)
16:59 Lyude: https://gitlab.freedesktop.org/lyudess/linux/-/tree/rvkms-wip/rust/kernel/drm/kms?ref_type=heads straight from a metal tube above the ocean currently leaving the area of greenland
16:59 Lyude: drivers/gpu/drm/rvkms/plane.rs and drivers/gpu/drm/rvkms/crtc.rs should give an idea of what I'm doing
16:59 Lyude: we got lucky in that drm_connector actually does have a refcount, so we can just get away with using a normal Box<>
17:00 Lyude: (and implementing AlwaysRefCounted)
17:00 Lyude: also I should note, the lack of Deref on all of those structs is quite intentional
17:00 karolherbst: isn't there a kernel version of Arc which just uses a ref counter?
17:00 Lyude: karolherbst: that's what drm_connector uses
17:00 Lyude: but that relies on the actual ffi struct having a kref
17:01 Lyude: which both drm_plane and drm_crtc unfortunately lack
17:02 Lyude: also wait oops those are the wrong file paths
17:03 Lyude: I meant to say rust/kernel/drm/kms/crtc.rs and rust/kernel/drm/kms/plane.rs - and rust/kernel/drm/kms/connector.rs has an example of the kernel's actual refcounting mechanism eing used
17:04 karolherbst: I see
17:09 Lyude: boy spotify does some really weird stuff on an airplane
17:10 karolherbst: Lyude: if you have premium, you could have downloaded everything and just go into offline mode or something :P
17:10 Lyude: karolherbst: yeah but I never know what I want to listen to ahead of time :P
17:10 karolherbst: :D
17:10 karolherbst: fair
17:10 karolherbst: (just download everything)
17:15 karolherbst: Lyude: but anyway, not sure how much time I'll have this week to really dig into your rust code, because I wanted to port the gl driver to VM_BIND, because that's needed to fix modifier stuff for nvk :')
17:15 Lyude: hehe, np
17:16 Lyude: I'm sure I'll eventually find out how sound it is once I've actually got enough code to start creating real planes and such
17:16 Lyude: (and hopefully actually doing this stuff in a vm will make it a lot easier for me to debug it. maybe. I have no idea how painful kgdb is and especially kgdb with rust
17:17 karolherbst: I never used kgdb :')
17:17 Lyude: neither have I
17:18 Lyude: but I figure it might be worth giving it another shot since there's not much of a need for me to run any of this on real hardware
17:18 karolherbst: fair
17:36 Lyude: esson learned: avoid SAS airlines, they think they can be cheeky and charge you business class for access to the most basic functionality imaginable: a power outlet.
17:40 DodoGTA: Lyude: I'm getting SNCF Ouigo vibes from this
19:41 bgnr: Hi! Good evening
19:41 bgnr: A user here
19:42 bgnr: System Clearlinux 36010, linux kernel 5.16, mesa 22, GPU 780ti reclocked "manually"
19:42 bgnr: I'm getting very low performance If I start a graphical app from console/tty
19:42 bgnr: Confirmed from 2 diff systems, one starting on console, other on Xorg desktop
19:42 bgnr: Also confirmed on one system with Xorg, and after VT switching same degraded performance appears
19:42 bgnr: cat /proc/fb says its 0 nouveaufbdrm , and cat /sys/kernel/debug/dri/0/pstate says I'm using most performant level 0f
19:43 bgnr: the application (opengl) also says its on nouveau
19:43 bgnr: I came asking for help to solve problem, if it might be something well known to you
19:43 bgnr: Thanks
19:44 fdobridge: <r​hed0x> Risen (64bit D3D9 DXVK) crashes with NVK but curiously an apitrace of the game replays without issues.
19:44 fdobridge: <r​hed0x> any idea how to proceed debugging this?
19:49 karolherbst: bgnr: sure the graphical app is accelerated?
19:50 karolherbst: but anyway.. is it also slow when starting within Xorg?
19:51 karolherbst: and what's the content of `pstate`?
19:55 bgnr: Hi Mr karolherbst
19:55 bgnr: For reference on Xorg at 800x600 res i get 2000+ fps without manual recloking
19:55 bgnr: and with manual reclocking I get almost 8000fps
19:56 bgnr: from console...level 3 boot..or VT Switch I get 200 or 400 fps not stable
19:56 bgnr: So It's not "slow" on Xorg
19:57 bgnr: I set the performance level at modprobe.d
19:57 bgnr: with this options nouveau config=NvClkMode=15,NvMemExec=1,NvBoost=2
19:58 bgnr: I manually checked often the value of /sys/kernel/debug/dri/0/pstate
19:58 bgnr: the asterisk was on the most performant level
19:58 bgnr: not the AC ofc
19:59 bgnr: I did some things..I checked DMESG...I noticed a handoff from simple fb to nouveau...and I didnt noticed a handoff from nouveau to others I did blacklisted the nvidiafb...but still the same
19:59 bgnr: btw this application uses SDL2
20:00 bgnr: Don't know if this is relevant
20:00 bgnr: I'm not a tech person....but i tried diff settings..on the kernel module options of nouveau...but not so much about the bios ones
20:01 bgnr: and other stuff...To be clear..I can even boot to XORG, check the app...everything normal..VTswitch..performance is not ok....go again to Xorg and works well
20:18 karolherbst: bgnr: the issue might be that displaying on a vt isn't accelerated and that you are CPU limited here or something else
20:19 bgnr: Mr Karol Herbst, thanks for replying
20:20 bgnr: But shouldnt the display on a VT or console be accelerated? Since Nouveau has kms?! and SDL also has kmsdrm mode?!
20:20 bgnr: I have a friend that at least on AMD has accelerated graphics on console or VT
20:21 bgnr: This "adventure" actually started from an install problem that sent me to a system without Xorg,,and I was pretty curious about running this application on a less loaded environment
20:22 bgnr: Also curious why perfomance is normal in Xorg and not on VT or console mode...What is changing between these 2 environments
20:43 bgnr: Actually I just dm this friend that i said at least on AMD had managed,,he dis a sysadmin...and the person that ontroduced me to linux
20:44 bgnr: and he mentioned that he add acceleration on console with a kepler card on debian..worth what is worth..but I do believe him
20:59 karolherbst: bgnr: the code got removed, because it was expensive to maintain, broke a lot and doesn't really give any benefits except in very niche use cases
21:00 karolherbst: _but_
21:00 bgnr: Oh.......So in older releases that possible?!
21:00 bgnr: Could you please point to wich time or version thats still available? or any other solution?!
21:01 karolherbst: it also sounds like that SDL2 is doing something incorrectly if it realies on that, es Xorg and wayland compositors do it in a way it's not slow. So I'd kinda be surprised if SDL2 wouldn't be able to on a tty
21:03 karolherbst: bgnr: I think it got dropped in 6.2 or so?
21:03 bgnr: kernel 6.2...ermm but I was on kernel 5.16 so weird..but sitll good to know
21:03 karolherbst: maybe you ran into a different issue then
21:03 karolherbst: maybe it will be faster on 6.2
21:03 karolherbst: at least something to try out
21:04 bgnr: but Mr Karol Herbst..and I reaelly do appreacite greatly any of your time
21:05 bgnr: actuallt texting with a great name of the opensource world
21:05 bgnr: The acceleration in cause here is more for the app started from the VT/tty
21:05 bgnr: since it runs on SDL2, i think the VT acceleration itself is not important for the matter
21:05 fdobridge: <r​hed0x> false alarm, doesnt work with lavapipe either, so its probably broken because of wayland. (I ran it on X11 Nv Prop earlier today)
21:06 bgnr: Yes I will try on different kernels for sure...I will do that
21:06 karolherbst: yeah.. it might also be something else going wrong, it's just something I can imagine making a big difference
21:12 bgnr: I won't take more of your time
21:12 bgnr: and Thank you very much for your attention and help
21:12 bgnr: a honor talking to a big name
21:12 bgnr: thanks for your contributions
21:12 bgnr: :)
21:12 karolherbst: np
21:13 bgnr: If I get other behaviour in different Os or Kernel I will report
21:13 bgnr: Thanks again
22:02 letsgofrom: Well rest of it is dad difficult to me, i have chosen unorthodox language named scala and over llvm native, though i am yet looking and getting to know it's possibilities , however with arbitrary integer encoding resulting in packed integer codes, i can be wrong today but i believe currently that this will boil down to odd and even predicates per operands of the instruction in the modified bitset iterateables traced and unrolled, for an example
22:02 letsgofrom: there are answer sets indexed, through the operands predicates, so first operand of the operation in the collections merged forwards odd numbers from 1 3 5 and second operand forwards even numbers for the powers 2 4 6, that would result into accessing
22:02 letsgofrom: some value on ordered set if one derived it, and that value is the result of the operation
22:12 fdobridge: <g​fxstrand> I'm attempting an ESO CTS run with 8 threads (instead of 18). If this passes I'm going to blame noveau.ko for my crashiness and land ESO
22:21 fdobridge: <g​fxstrand> Or not....
22:21 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1211800300021616650/message.txt?ex=65ef83f9&is=65dd0ef9&hm=6f1856f2504eac2c14f9c9434b3e7232d6a7619e4e17daf775ae82f7a705a458&
22:22 fdobridge: <g​fxstrand> @airlied ^^
22:28 fdobridge: <g​fxstrand> That feels like some sort of an unhandled error condition. Maybe a race? If the client is somehow racing a page access and an unmap/close, we should SIGBUS the client.
22:28 fdobridge: <g​fxstrand> But IDK what's going wrong.
22:35 fdobridge: <k​arolherbst🐧🦀> @gfxstrand what's the easiest way to run into the broken modifier issue?
22:35 fdobridge: <g​fxstrand> Check out my modifiers branch, set `supports_modifiers = true` in nvk_wsi.c, and run any Vulkan app
22:36 fdobridge: <g​fxstrand> Unless you're looking at the linear issue on Kepler in which case the answer is "just run a Vulkan app"
22:36 fdobridge: <k​arolherbst🐧🦀> both kinda I guess
22:36 fdobridge: <k​arolherbst🐧🦀> though uhh
22:37 fdobridge: <k​arolherbst🐧🦀> the kepler one is unrelated to the gl driver or is it?
22:38 fdobridge: <g​fxstrand> Oh, I'm pretty sure that's the GL driver's fault
22:38 fdobridge: <g​fxstrand> We're copying to linear and it's interpreting it as tiled
22:38 fdobridge: <k​arolherbst🐧🦀> I see
22:38 fdobridge: <k​arolherbst🐧🦀> so both
22:38 fdobridge: <g​fxstrand> I legitimately don't know how the kepler bug is even a thing
22:39 fdobridge: <g​fxstrand> It could also be an alignment issue
22:40 fdobridge: <k​arolherbst🐧🦀> there is this weird `info->tile_flags &= 0x0000ff00;` I found in the libdrm code... and I have no idea what that's all about :ferrisUpsideDown:
22:41 fdobridge: <g​fxstrand> IDK either
22:41 fdobridge: <k​arolherbst🐧🦀> I just now it's kinda modifier related
22:42 fdobridge: <k​arolherbst🐧🦀> ehh wait... I think I messed up and that could isn't actually hit.. uhhh
22:42 fdobridge: <k​arolherbst🐧🦀> this code...
22:43 fdobridge: <k​arolherbst🐧🦀> but anyway...
22:43 fdobridge: <k​arolherbst🐧🦀> I'll see how far I get tomorrow, but I might be done by then...
23:24 fdobridge: <r​edsheep> There's some resemblance here to the rip I got with baldurs gate
23:24 fdobridge: <r​edsheep>
23:24 fdobridge: <r​edsheep> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10432
23:25 fdobridge: <r​edsheep> Though if your issue there is consistent and only on the ESO branch then maybe not connected
23:29 fdobridge: <g​fxstrand> I don't think it has anything to do with ESO
23:29 fdobridge: <g​fxstrand> It's some sort of a race with maps
23:30 fdobridge: <g​fxstrand> Maybe the kernel is trying to evict to something that we're accessing directly from userspace?
23:30 fdobridge: <g​fxstrand> Unclear
23:30 fdobridge: <g​fxstrand> My ESO branch is just mean enough in just the right way to make my Ampere fall over
23:49 fdobridge: <a​irlied> seems like a failure mapping something into VRAM
23:50 fdobridge: <a​irlied> so likely a race, probably with something kicking something out of vram