11:21Shred00: now that i have worked out my franken-upgrade issue nouveau seems to be working just peachy. impressively in fact. even vdpau seems to work. nice work!
12:15karolherbst: imirkin: I've updated my MR to libdrm to add some nice to haves (pushbuffer dumping without debug build and option to have synced submissions): https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/65
13:17ajax: Shred00: excellent, glad you were able to work it out!
13:19Shred00: indeed. should i expect as much success on an "ion" (bundled with an atom processor) with Fedora 33? it as Mesa 20.something.
13:31ajax: geforce 9m? should work i think, that's some pretty stable code at this point, but i think that's of the era where performance isn't great because we can't do reclocking
14:21RSpliet: Shred00: I used to own an NVIDIA ION NVAC, yep should work fine
14:21RSpliet: And you are even able to manually select its clocks
14:22RSpliet: ... But there's some similar IONs with an outstanding issue that cause them to not work at all. Best to just boot a live USB installation of F34 or so, and see what happens
14:23RSpliet: ajax: IONs don't have VRAM. I implemented clock changing for them eons ago, but there's no load-based fanciness in nouveau
14:23Shred00: hrm. live f34. interesting way to test. would f33 work reasonably well or is 33->34 significantly better?
14:24ajax: for g98 i'd expect they're quite similar
14:24RSpliet: Shred00: my approach is always to go with newer. Feel free to try F33, but if you run into issues our first response here is "try something newer or get help from your distro people instead".
14:25ajax: but yeah, i always start from the newest thing and try working backwards to see if it regressed, since the newest thing is what i'm gonna want anyway
14:25ajax: granted i work on fedora for a living, but.
14:25Shred00: RSpliet: i generally agree. those ions boot diskless and mount their /usr from a node that is still f33 though. it should go to f34 soon, but just thinking very short term.
14:26RSpliet: Shred00: live USB sticks are the way to test quickly and painlessly
14:26Shred00: RSpliet: indeed!
14:26RSpliet: If you need F33, get an ISO and try it out. If it doesn't work... well, you already know our response, but if it does you can crack open a cold beer* and celebrate!
14:36fling: I increased the average uptime drastically by just removing nouveau card.
14:39imirkin: fling: thanks for sharing. i'll keep that in mind as advice to pass on to others.
14:43fling: imirkin: you actually already gave me this advice a while ago.
14:43imirkin: ah yeah, makes sense.
14:43imirkin: glad you got your system stable
14:44fling: Thanks!
14:45fling: There is also something new in X11 or darktable and now interface is not as slow as it was before when I run darktable without direct rendering
14:45fling: ast rocks!
14:46fling: I will try 710 next in few months probably
14:55isapgswell: hi everyone
14:56isapgswell: my gtx 1060 on ubuntu nvidia ondemand profile hdmi external display lags severe
14:57isapgswell: handled by nvidia
14:57isapgswell: so i uninstalled gamemode and now i can use external monitor into hdmi handled by nvidia witout lag
14:58isapgswell: both nouveau and nvidia proprietary driver
14:59imirkin: is there a question in there?
15:04isapgswell: imirkin no, i am just noticing a workaround
15:04imirkin: ah cool
15:05isapgswell: i have a dell g7 7588 with optimus technology
15:05fling: See? No questions today, only observations.
15:05isapgswell: hdmi is handled by nvidia as i said
15:05imirkin: fling: it's a good day.
15:10isapgswell: nouveau supports gtx 1060 recloking?
15:10imirkin: no
15:11imirkin: 900+ = no reclocking, thanks to nvidia locking down the firmware and then providing neutered firmware for nouveau to use.
15:11isapgswell: imirkin what about public key
15:12imirkin: what about it?
15:12isapgswell: imirkin nvidia signs with his private key, and provide a public key for community to use
15:13imirkin: that doesn't quite make sense, but without being able to "mess around", nouveau can't develop our own firmware to begin with.
15:13imirkin: but also nvidia isn't going to sign nouveau's firmare.
15:13imirkin: firmware*
15:14isapgswell: is there a way to clone nvidia sign firmware offset?
15:14isapgswell: from a previous known firmware
15:15imirkin: you could get proprietary firmware by tracing the blob ... maybe. it used to be very difficult, but it might be easy again, i haven't checked.
15:15imirkin: but it wouldn't be redistributable.
15:16isapgswell: we could dump proprietary firmware and analyze offset looking to the key sign
15:17ccr: umm
15:21imirkin: the key is not in the firmware.
15:21imirkin: the key is at nvidia hq
15:22ccr: in the land of Mordor, where the shadows lie
15:22isapgswell: imirkin public key
15:23isapgswell: when sign a file we have a key pair private key and public key
15:23imirkin: (a) you need to go read up on how public/private key crypto works
15:23isapgswell: windows nvidia proprietary driver doesnt care about nvidia private key
15:24imirkin: (b) the signature in this case is most likely an HMAC with a symmetric key.
15:24isapgswell: imirkin sorry, confusing with assimetric key
15:24imirkin: even if it's asymmetric
15:24imirkin: you still need private key to sign
15:25isapgswell: umm
15:26isapgswell: cripto with symmetric and sign with assymmetric method
15:26isapgswell: so we have both private key and one public key
15:27isapgswell: duo private key and one public key, is that right?
15:27imirkin: but then you just ship the signature. and only need public key to verify that the signature is made with that private key.
15:27imirkin: HOWEVER
15:27imirkin: i'm pretty sure that the signatures that are validated by nvidia hw is an HMAC
15:28isapgswell: umm
15:28imirkin: either way, without the private key, we're not getting anywhere
15:30isapgswell: or suppress nvidia proprietary blob and make a super generic nouveau firmware and locate at /lib/firmware
15:30imirkin: the hardware requires firmware to be signed.
15:31isapgswell: mandatory to be signed by nvidia? a nouveau firmware signed by user or any distro wouldnt solve
15:31imirkin: the hardware verifies that the signature is appropriate.
15:32imirkin: whoever knows the key that the hw is looking for it to be signed with can sign. aka nvidia.
15:34isapgswell: ok the hardware you said is a low level software we dont have access
15:34isapgswell: yet
15:34imirkin: the hardware is ... hardware.
15:34isapgswell: umm
15:35isapgswell: hardware = ic (integrated circuit)
15:35imirkin: yes
15:35isapgswell: wow
15:36isapgswell: maybe the key HMAC is located somewhere, cmos or bios
15:37imirkin: normally it's just part of the IC.
15:38imirkin: because having it located somewhere, as you say, would entirely defeat the purpose of having it
15:39isapgswell: yes
15:39imirkin: sadly nvidia is not a bunch of incompetent fools
15:39isapgswell: as a understand, on windows environment the firmware and driver is distributed already crypto and signed
15:40imirkin: yes, the signature is just shipped along with the firmware.
15:41isapgswell: have you inspect the firmware?
15:41imirkin: sure
15:41imirkin: i can't tell what you're trying to achieve...
15:44isapgswell: i am trying to tell you to dump the nvidia firmware signature and when inject into nouveau firmware
15:44isapgswell: *then
15:44isapgswell: same offset
15:44imirkin: if you think that we're a bunch of incompetent fools, then you should just show us the way.
15:45isapgswell: imirkin noway, i am just trying to understand the complete proccess
15:46imirkin: the process is simple: hw checks the uploaded firmware signature in order to allow "high secure" mode
15:46imirkin: which in turn gets you access to a bunch of things you need to do reclocking-related things
15:46imirkin: if the signature doesn't validate, you get dropped into "low secure" mode
15:46imirkin: or whatever it's called
15:46isapgswell: understood
15:47imirkin: isapgswell: https://nvidia.github.io/open-gpu-doc/Falcon-Security/Falcon-Security.html
15:48isapgswell: so i love my 780ti
15:48isapgswell: lol
15:56isapgswell: if nvidia distribute a signed firmware, the easy solution is to paste this into /lib/firmware ?
15:57imirkin: and make the driver talk to the firmware, yes
15:57imirkin: but such firmware wouldn't be redistributable.
16:00isapgswell: linus was right when he gave hist middle finger to nvidia lol
16:06juri_: i'm not often on the 'linus is right' bandwagon, but in this case...
16:15isapgswell: juri_ yep
16:45karolherbst: ah our favourite topic
16:45karolherbst: imirkin: btw, mind if I push those drm changes once I actually made sure it all works or do you have any concerns there?
16:46imirkin: karolherbst: can you give me the day to review?
16:46karolherbst: sure
16:46imirkin: i'll get to it tonight
16:46karolherbst: cool, thanks
16:47karolherbst: I actually hit a bug in glamor and... debugging that is terrible :D not sure if that's a glamor mesa or nouveau bug actually :( so frustrating
16:47imirkin: i think you know what i'm going to tell you :)
16:47karolherbst: apparently mesa complains a lot about OOB accesses and some might slip through
16:47karolherbst: imirkin: ohh sure, but that might be a legitimate bug causing OOB accesses to memory
16:48imirkin: in shaders, or what?
16:48karolherbst: nope, GL API
16:48karolherbst: it essentially blits a lot
16:48imirkin: oh, you mean like valgrind complaints
16:48imirkin: or mesa complaints?
16:48karolherbst: no, debug context
16:48karolherbst: you know, apitrace
16:48imirkin: like GL API complaints
16:48imirkin: or valgrind oob complaints
16:48karolherbst: so I traced Xwayland and apitrace enables a debug context
16:48imirkin: which GL API's?
16:48karolherbst: and that throws out a lot of errors
16:48imirkin: which errors?
16:49karolherbst: glCopyTexSubImage2D
16:49karolherbst: imirkin: https://gist.githubusercontent.com/karolherbst/d5382120c081eb3343d2798b9f926b68/raw/3bd62e8dcd7cb07f9df390976f91f9654459f222/gistfile1.txt
16:49imirkin: uhhhhh
16:49karolherbst: yep
16:49imirkin: "oops"
16:49karolherbst: exactly
16:49karolherbst: turns out.. it manages to kill our context with an invalid write
16:49karolherbst: so I am curious what's that all about
16:49imirkin: funny that the width/height = 24 always
16:49imirkin: well, it's not coz of those errors
16:50karolherbst: yeah
16:50imirkin: coz those errors are rejections at the API level
16:50karolherbst: but glamor missbehaving is already annoying
16:50imirkin: they never hit the driver
16:50karolherbst: so we might not error check everything
16:50karolherbst: just curious mainly
16:50imirkin: if there's a blit that's out of bounds, you'll get a dispatch error
16:50karolherbst: ohh sure, but I mean glamor might dispatch a draw eventually which does things OOB
16:50imirkin: no
16:51karolherbst: sure?
16:51karolherbst: ohh
16:51karolherbst: tex ops
16:51imirkin: never 100% sure of anything, including my own existence
16:51karolherbst: wait..
16:51imirkin: but pretty sure.
16:51karolherbst: [ 138.538975] nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 00000000023e0000 engine 00 [GR] client 0f [GPC1/PROP_0] reason 02 [PTE] on channel 3 [023f898000 Xwayland[1939]]
16:51karolherbst: sutff like that
16:51imirkin: right
16:51imirkin: that should never happen :)
16:52karolherbst: :)
16:52imirkin: that points to buffer mismanagement of sorts
16:52karolherbst: yeah..
16:52imirkin: or other incompetence
16:52karolherbst: it happens when resizing a lot
16:52karolherbst: so the API might update things too fast
16:52karolherbst: and we are stuck with old state or something
16:52imirkin: we might have insufficient fence
16:52karolherbst: or that
16:52imirkin: or we delete a buffer too early
16:52imirkin: i hate those issues
16:52karolherbst: yeah.. something something :)
16:53imirkin: when you have a draw, the thing it's drawing to gets deleted
16:53karolherbst: anyway, hence I want to dump the pushbuffers and see what happens
16:53imirkin: but you still have to make sure to hold onto it until the draw completes
16:53imirkin: we're not always perfect at that
16:53karolherbst: but I am sure that glamor might also do stupid things.. dunno
16:53karolherbst: annoying issue
16:53imirkin: those API errors are definitely glamor doing stupid things
16:53karolherbst: yep
16:53imirkin: but those stupid things are unlikely to be related to nouveau's stupidity
16:53karolherbst: yeah
16:54karolherbst: except we are missing error checks
16:54karolherbst: but yeah..
16:54karolherbst: I think the buffer missmanagement is probably the reason
16:54ajax: karolherbst: can you get a backtrace of where glamor_debug_output_callback is getting called there?
16:54karolherbst: ajax: that's with apitrace
16:54karolherbst: but yeah
16:54karolherbst: I will check that at some point this week
16:55karolherbst: debugging xwayland is just.. annoying
16:55karolherbst: want to setup some sort of remote gdb thing
16:56imirkin: a lot less annoying that debugging X, i assume
16:57imirkin: coz attaching to X in gdb from an xterm running in X is ... a mistake.
16:57imirkin: not that i know from experience.
16:58karolherbst: imirkin: you know what's nice about gnome 40? xwayland gets started on demand and you can kill it without having to kill the entire session :)
16:58karolherbst: that makes debugging such things a lot less annoying :D
17:00imirkin: karolherbst: presumably a feature of wayland rather than gnome
17:00karolherbst: well, gnome-shell
17:00karolherbst: or mutter rather
17:00imirkin: i assumed that there was a Xwayland process that would wrap each X client
17:00karolherbst: there is one for all
17:00imirkin: but i guess you can just as easily have a single Xwayland process
17:01karolherbst: and what desktops did was to start it as soon as the session was started
17:01karolherbst: and when the connection was gone to simply crash or something
17:01karolherbst: plasma had/has the same issue
18:35pmoreau: Mmh, let’s see if I can figure out what is going wrong with this unspill of a 2x splitted value (i.e. split from 64 to 32, and then from 32 to 16 cause 32-bit mul aren’t a thing on Tesla). The end issue is that both lo.lo and hi.lo get an offset of 0x0 and lo.hi and hi.hi an offset of 0x2 when loading back from l[], instead of respectively, 0x0, 0x4, 0x2, and 0x6.
18:37imirkin: good luck!
18:37pmoreau: Thanks! :-)
18:43pmoreau: Does compMask work only for the inner split, or will it reflect the outer one as well? (i.e. is it supposed to carry some information about its parent which was itself also splitted?)
18:45imirkin: search me
18:45imirkin: i hear printf is nice.
18:46pmoreau: I heard that too, though it can only tell me what happens and not also what is supposed to happen. :-)
18:47imirkin: my printf can :p
18:47pmoreau: :o
18:47imirkin: it's a super-secret format flag
18:47imirkin: which tells it to print the value you wanted it to be
18:47imirkin: rather than the one you gave it
18:47pmoreau: printf("%42")? :-)
18:48imirkin: hehe
19:05ccr: magic printf :o