00:55 karolherbst: :p
01:05 karolherbst: mslusarz: 0x7ff is UVM_IS_8_SUPPORTED
01:05 karolherbst: "Temporary ioctls which should be removed before UVM 8 release Number backwards from 2047 - highest custom ioctl function number windows can handle." ...
01:05 karolherbst: famous last words
01:26 karolherbst: mslusarz: you know what? Maybe we should just include the nvidia header fils directly. Should be easier than trying to keep it up to date manually? what do you say? It seems like the uvm interface isn't considered to be stable at all
01:26 karolherbst: as arrays are just embedded inside the structs
01:26 karolherbst: and length are compile time constants
01:27 karolherbst: wow and each API call is even document
01:27 karolherbst: ed
01:46 Lyude: skeggsb: in nvkm_dp_hpd() in dp.c on line 532, is dp->outp.func->acquire(&dp->outp); just supposed to check whether or not the DP link needs retraining?
01:47 Lyude: (and retrain if that is the case)
01:47 skeggsb: pretty much
01:50 Lyude: hm, alright
07:35 pmoreau: HdkR: Already got my eyes on the 2080 Ti <3 --" I was expecting it to be announced quite a bit later, similar to the 1080 Ti that came out 1/2 year/ a year after the 1080.
07:38 HdkR: pmoreau: I would have preordered it immediately if I didn't just purchase a 2990WX. GOing to hold off until next month now
07:39 pmoreau: Oh, nice! I need to buy a new CPU one day.
07:40 HdkR: My new build PC :)
07:41 pmoreau: :-)
10:40 karolherbst: mslusarz: soooo... the thing with uvm is, that you setup a unified memory region which can be used by the CPU and the GPU and migration happens when any device faults on that memory
10:40 karolherbst: so we don't have explicit copies from CPU -> GPU anymore
10:41 karolherbst: so I think mmt itself doesn't need to handle much here. Should be all done inside demmt, right? I mean, in mmt I handle the struct sizes and parse those out, but that should be pretty much it (except some ioctls have pointers to memory, which they don't)
10:42 karolherbst: (or at least not the ones I've encountered)
11:24 `ani`: hello.
13:42 RetardedOnion: i was thinking about buying an old nvidia card for living blob free. i guess the last blob free card is the gtx 680. its not exactly well documented anywhere. can someone tell me how nouveau works with kde/will work with future projects like wayland? i dont have an nvidia card out of that generation to test it.
13:56 gnarface: RetardedOnion: go for a 780 instead
13:57 RetardedOnion: gnarface: oh do they work as well? nice to know. i guess 780 ti then. what about compatibility? nvidia is just garbage i know, but is nouveau on par with intel?
13:59 mooch: no, but it's at least decent
13:59 gnarface: RetardedOnion: no, they're not unfortunately, but for the 700's at least they're good enough the hardware can still make up for it
13:59 mooch: the most powerful blob free card would likely be the titan black
14:00 gnarface: yea but does reclocking even work on that one?
14:00 gnarface: for the 700's, reclocking works, which is pretty critical for anything beyond proof-of-concept testing of the nouveau driver
14:00 `ani`: I need tips on acquiring a graphics set for 3D acceleration in freedom.
14:00 karolherbst: mslusarz: things start to make sense: https://gist.githubusercontent.com/karolherbst/1ab16ea0018d0f9dc943d967996665a4/raw/de498ccbc2d37b3d2062fe37edca9093fd6f5f7f/gistfile1.txt
14:01 gnarface: for the 600's, hardware video decoding doesn't even work
14:01 mooch: gnarface, it should, it's still kepler lol
14:01 RetardedOnion: ok. so i guess a 700 it will be. whichever one.
14:01 mooch: gnarface, 600s and 700s are both kepler
14:01 mooch: so i don't see why hw video decoding wouldn't work on the 600s
14:01 karolherbst: UVM_REGISTER_GPU_VASPACE.hClient == NVRM_IOCTL_MEMORY2.vspace
14:01 mooch: if it doesn't also work on the 700s
14:02 RetardedOnion: mooch: can you compare the amdgpu to noveau in any ways? amdgpu still is not perfect if it goes to opengl.
14:02 karolherbst: there are some maxwell1 ones in the 700 series
14:02 karolherbst: but we can reclock those as well
14:02 karolherbst: RetardedOnion: amdgpu has vendor support
14:03 kernel-3xp: 750ti is maxwell for sure
14:03 karolherbst: and I am sure in regards to OpenGL they should be much better than lets say, a year ago
14:03 RetardedOnion: karolherbst: i guess my rx 460 sucks then
14:03 karolherbst: or your drivers are old
14:03 RetardedOnion: archlinux. i guess not
14:04 karolherbst: well the rx 460 isn't a fast card
14:04 RetardedOnion: so the 700 series are compatible without blobs?
14:04 karolherbst: should be
14:04 karolherbst: there can be always random issues though
14:04 karolherbst: no guarentees
14:05 karolherbst: if you buy one and nouveau doesn't work, then you are out of luck until we fix the issues
14:05 RetardedOnion: i know the 460 isnt fast. i dont mean speed, i mean following opengl standards. which nvidia doesnt like
14:05 karolherbst: ahh
14:05 karolherbst: well
14:06 karolherbst: on linux game devs are kind of targeting nvidia blob
14:06 karolherbst: and if nvidia blob screws up...
14:06 karolherbst: (which they do)
14:06 RetardedOnion: it would be great if someone with a gtx 780/780 ti would tell me how the experience is without blobs. thanks if you do
14:06 kernel-3xp: i only have 750ti
14:06 karolherbst: Tom^ used one and I think he was more or less happy with it
14:07 RetardedOnion: karolherbst: i dont play games on there. i guess that makes sense if i want to build a libre system.
14:07 RetardedOnion: kernel-3xp: does it werk without blobs?
14:08 kernel-3xp: i have no idea it is in storage as of now, back then i ran only nvidia proprietary one
14:08 karolherbst: RetardedOnion: if you don't play games a 780 ti is overkill
14:10 RetardedOnion: karolherbst: how many screens does it support? at what resolution? i guess performance is half of what i can expect with proprietary drivers. so i dont think i would go 770. not sure though. opterons are expensive
14:11 kernel-3xp: opteron? you wanna libreboot it?
14:12 RetardedOnion: nah. trannyboot is behind a lot. i will use coreboot.
14:12 kernel-3xp: ah ok nice
14:13 RetardedOnion: if you can grab your 750ti and test it in a libre distro, that would be cool. if not, ebay handles my mistakes
14:17 nyef: RetardedOnion: My 750 Ti worked well enough for the few minutes I used it. What doesn't work well is closing the computer case while it's installed, and I really don't need that much of a graphics card, so...
14:17 RetardedOnion: nyef: did you use a libre distro?
14:17 nyef: I use Gentoo.
14:18 RetardedOnion: afaik that uses the proprietary kernel and firmware by defautl
14:19 nyef: And I tend to build my own kernels, for various reasons. I'd've been using nouveau with the 750 Ti.
14:19 RetardedOnion: based on linux-libre? that is the whole reason why i am here other than asking compatibility. and that seems to be fine if you dont use the newest stuff
14:20 nyef: I... don't know of the distinction that you're trying to make.
14:20 kernel-3xp: i think kernel etc without firmware blobs and so on
14:20 RetardedOnion: sys-kernel/linux-firmware uses git.kernel.org. it has proprietary blobs.
14:21 nyef: ... Does nouveau even load firmware for basic operation pre-GM20x?
14:21 karolherbst: free firmware, yes
14:21 kernel-3xp: if you go without firmware that might limit your choices in hardware i guess
14:22 RetardedOnion: karolherbst: would i find the firmware here? https://jxself.org/firmware/
14:22 RetardedOnion: kernel-3xp: i know. that was in my first message though.
14:23 kernel-3xp: ok didnt read
14:24 mooch: RetardedOnion, my 750ti works without blobs, but again, there's no telling until you run it on YOUR card
14:25 RetardedOnion: mooch: thanks for your answer. i guess if its kepler i will buy a kepler card, if maxwell, maxwell.
14:25 kernel-3xp: from what ive read maxwell1 might go without firmware but maxwell2 cant
14:26 RetardedOnion: so gm10x is fine, gm20x is not.
14:27 kernel-3xp: yeah
14:28 mooch: yep
14:28 RetardedOnion: great. i guess i will throw my money into a titan black because that will be efficient. thanks guys!
14:33 kernel-3xp: maybe also check if reclocking works on that particular card
14:34 kernel-3xp: i got some quadros 2000/4000 where it still doesnt
14:35 RetardedOnion: i cant see it on the feature matrix. so i guess as the main site says "experimental support" for gm10x
14:36 RetardedOnion: which seems like is NOT the titan black, but the 770 is the best. hm. oh well
14:37 kernel-3xp: maybe check forums etc if someone has been successful, otherwise good luck
14:37 RetardedOnion: as said: rarely documented. i sometimes saw a 1030 "work fine".
14:38 RetardedOnion: https://h-node.org/videocards/view/en/1960/GeForce-GT-1030/1/1/undef/undef/undef/undef/video-card-works/1030 here for example. while parabola should support software renderung "out-of-the-box"
14:39 kernel-3xp: but not sure if this will work without blobs
14:39 RetardedOnion: it does not.
14:39 RetardedOnion: the 10xx series locked up arch isos when typing lspci at one point
14:40 kernel-3xp: oh ok
14:40 RetardedOnion: i guess the gk110 are not reclockable. shucks
14:42 kernel-3xp: if i can i will always use quadro fx 1800 cards on linux, fast enough (for me), reclocking works and low input lag
14:43 RetardedOnion: the good old fx 1800. so many 1366 workstations with these cards. i think i still have 2-3.
14:43 kernel-3xp: yeah love it
14:44 RetardedOnion: too bad only 2 displays at one time work
14:45 kernel-3xp: hm 3? it has 2 dp and one dvi
14:46 RetardedOnion: no. maybe you can copy one display, but you can extend only one.
14:46 RetardedOnion: and when covering myself in monitors i rarely copy them.
14:47 RetardedOnion: why would i?
14:47 kernel-3xp: yeah sure, ok didnt knew never used more than 2
14:47 RetardedOnion: i really doubt nouveau can fix that. would be nice though
14:50 kernel-3xp: yeah i read its a hardware limitation
14:51 nyef: Can DP MST work around that, or does it still require multiple CRTCs?
14:51 RetardedOnion: MST did not work for me
14:54 kernel-3xp: maybe 2 cards and 2 xservers?
14:55 RetardedOnion: that should not be limited by the cards, would it?
14:57 kernel-3xp: just a theory for 4 screens... infact i have no idea
14:57 RetardedOnion: i never merged two xs together usefully. but it should work
15:06 karolherbst: mslusarz: okay, so that weirdo 0x30000001 was UVM_INITIALIZE and is a linux specific value
15:06 karolherbst: with that no unknown ioctls
15:12 karolherbst: mslusarz: I know it is quite ugly, but this gets the job done quite nicely for now: https://github.com/karolherbst/valgrind/commit/63203ebe3989ce6b591c301752afc09199463be0
15:14 RSpliet: kernel-3xp, RetardedOnion: all cards require firmwares. Up to first gen Maxwell, nouveau reimplemented firmwares for power/fan management and context control. These firmwares are open source. All NVIDIA GPUs require proprietary video decoding firmware if you want HW acceleration. Additionally, the VBIOS has and always will be a closed component.
15:16 mooch: why can't we just use our own open-source replacements for the VBIOSes?
15:16 karolherbst: mslusarz: problem is, those header files are under propritary license, so we can't just copy them. And just copy the structs would be kind of problematic as well... but overall using nvidias header files is less painful, as we don't have to track changes (hopefully there are none, but you never know)
15:16 karolherbst: mooch: because it is pointless
15:16 karolherbst: and we have none
15:16 karolherbst: and impossible
15:16 mooch: how is it pointless and impossible?
15:16 karolherbst: because we need the vbios of every GPU to write the replacement for every GPU
15:16 RSpliet: mooch: it contains OEM-specific configuration information. We can't replace that...
15:16 mooch: ah, weird
15:16 karolherbst: why weird?
15:17 karolherbst: how else would you do it?
15:17 karolherbst: sold some chip on the GPU with all the information?
15:17 karolherbst: sounds like a vbios to me ;)
15:17 kernel-3xp: RSpliet: ok thx for info
15:18 mooch: no i mean, why would you need oem-specific configs?
15:18 RetardedOnion: RSpliet: so i guess the 770 is the best card for nouveau
15:18 mooch: other than for factory ocs
15:18 RSpliet: mooch: the OEM decides which DRAM chips to use, which display headers to connect etc...
15:18 mooch: ah, fair enough :/
15:19 RSpliet: RetardedOnion: I've had a 780TI running and changing clocks with nouveau as well... but yes, for high end cards your best bet is second gen Kepler. Also, I'd like to point out that so far AMD's GPU division has been more open-source friendly than NVIDIA.
15:20 RetardedOnion: RSpliet: i want a libre system. not open source. so amd is not an option.
15:20 karolherbst: mooch: also sensors found on the GPU, clock/volt tables, etc...
15:20 RSpliet: RetardedOnion: ... care to elaborate?
15:20 karolherbst: for OC cards you want to enter higher clocks
15:21 karolherbst: RSpliet: amd doesn't use open firmware at all
15:21 karolherbst: as nobody bothered to write open one
15:21 karolherbst: and AMD didn't bother to make them open
15:21 RSpliet: Oh rly? Scandalous...
15:21 RetardedOnion: RSpliet: linux-libre (or hurd)not linux. fsf approved distros. without proprietary firmware
15:22 karolherbst: RSpliet: so on every libre kernel you don't get accell on AMD/ATI gpus :)
15:22 RetardedOnion: even with old hd series you get none
15:22 karolherbst: atombios it is called or something?
15:22 RSpliet: RetardedOnion: did the libre people stop doing silly stuff like removing our open source firmware from the kernel?
15:22 karolherbst: which is like literally bytecode
15:23 karolherbst: RSpliet: they stopped that
15:23 RSpliet: Ah good!
15:23 RetardedOnion: RSpliet: i think so. problems are some rt patches which became obsolete with 4.16.
15:23 RetardedOnion: they will get removed. i hope.
15:23 karolherbst: RSpliet: yeah, was some missunderstanding and they fixed it quite fast I think
15:24 RetardedOnion: amds gpus are just not an option for a libre system.
15:24 RetardedOnion: the open source driver is somewhat decent.
15:24 karolherbst: RSpliet: interested in mmt tracing compute programs? I think I will be able to get it done today :)
15:24 RSpliet: Ignoring the firmware situation, the AMD open source driver is in better shape than nouveau at the moment
15:25 RSpliet: They've come a long way since 10 years ago
15:25 RSpliet: karolherbst: Hacking up valgrind? That's pretty good news. Which GPUs?
15:25 RetardedOnion: RSpliet: no doubt. but when i go as far as corebooting my pc, i will not stop at "oh well, firmware might be ok"
15:25 karolherbst: RSpliet: all which use nvidia-uvm
15:26 karolherbst: RSpliet: which includes Kepler. Now idea about fermi
15:26 karolherbst: the good thing is, nvidia-uvm is kind of open source, so all the ioctls structs are there
15:26 karolherbst: and the ioctls are even documented
15:26 karolherbst: like really documented
15:26 karolherbst: even with error code documentation
15:26 karolherbst: RSpliet: inside the nvidia driver package: kernel/nvidia-uvm/uvm.h
15:27 karolherbst: 3.3k loc, 3.0k documentation :)
15:27 RSpliet: Hehe, not bad, sounds pretty useful.
15:28 karolherbst: yes
15:28 karolherbst: for now I simply include those headers inside valgrind-mmt and demmt
15:28 karolherbst: and this seems to work quite nicely
15:31 RetardedOnion: is there anything stopping you from using a libre distro? or is it just lazyness?
15:35 nyef: Please do not dismiss the careful management of capacity to do work as mere "lazyness".
15:38 RetardedOnion: i guessed you sometimes have a few hours of freetime... i guess not
15:41 nyef: As though mere "freetime" is all that is required? Can there not be better use of "freetime", such as exercise, meditation, learning new skills, simply taking a break?
15:43 RetardedOnion: this is my hobby. i guess i have a different look on it. still interested in the question if you could do with only free software
15:44 Riastradh: nyef allocated all free time to arguing with pseudonymous strangers on the internet.
15:44 gnarface: RetardedOnion: the real problem is so much hardware requires some type of firmware (non-free or otherwise) that most people just don't have access or funding to free themselves of it. for example, there's only ONE motherboard in existence that requires NO non-free blobs and it costs $3000 and there's a waiting list.
15:44 gnarface: (and no, it's not x86 so kiss all your games goodbye)
15:44 Riastradh: Especially entitled ones who consider different priorities to be laziness!
15:45 RetardedOnion: i guess i dont game when i want a libre distro. i wasnt talking about libre hardware. that is very complicated. i know. coreboot without ME/PSP is freedom enough for me.
15:46 Riastradh: (Hi nyef!)
15:46 nyef: Hello Riastradh.
15:46 gnarface: RetardedOnion: so once you've crossed off realtek, broadcom, intel, nvidia, amd, and every x86 motherboard not supported by the libreboot alternative BIOS project, you're down to really slim pickings of stuff that's no longer manufactured, and becoming increasingly scarce
15:47 gnarface: and no, you can't just blow it all off for ARM hardware either, because even ARM hardware that "doesn't require firmware" still requires *ARMs* firmware
15:47 RetardedOnion: gnarface: that is why i especially asked about the libre distro. lowrisc is not ready.
15:48 Riastradh: So I have a nouveau conundrum. Working to upgrade NetBSD's kernel graphics drivers from Linux 3.15 when the last update was done. Made an increment at 4.4. Intel, radeon, and amdgpu work, but nouveau blanks the screen and doesn't come back.
15:48 RetardedOnion: arm hardware is especially bad when it comes to nonfree firmware
15:48 Riastradh: Spend more time trying to diagnose nouveau from Linux 4.4 or give up and take the next step to 4.18?
15:49 gnarface: Riastradh: it goes to sleep and doesn't wake up? there was a power management issue around then in linux i think...
15:49 Riastradh: gnarface: No, not suspend/resume, just boot.
15:49 gnarface: oh hmm
15:50 RetardedOnion: Riastradh: i guess a mere changing of mirrors/ reinstalling with the same packages isnt too much. i wasnt trying to attack. i guess if you could entirely work with free software, many people try to do that. but maybe i am wrong
15:51 nyef: I used to get screen-goes-blank-on-nouveau-startup issues at one point.
15:51 Riastradh: It detects modes correctly, and then when it first tries to do a mode switch inside drm_fb_helper_restore_fbdev_mode_unlocked, the screen blanks and nothing.
15:51 Riastradh: Worked in 3.15, so I'm guessing I made a mistake in merging 4.4.
15:51 nyef: In at least one case, it was nouveau deciding to try to re-train the DP link, and failing.
15:52 Riastradh: I'm testing with an ancient laptop display, but others have seen it on newer hardware too.
15:52 nyef: Riastradh: I don't suppose NetBSD has anything going with HDMI 3D support, does it?
15:52 Riastradh: nyef: I have no idea what HDMI 3D entails!
15:53 nyef: At the kernel level, it entails specific video modes, plus HDMI infoframes. I'm more wondering about possible userland support.
15:53 Riastradh: If it's not in Linux's drivers already, then no.
15:55 Riastradh: RetardedOnion: Personally I do aim for a libre-only computing platform, but I acknowledge that different people have different priorities and tend not to accuse them of laziness in that case -- it doesn't endear anyone to you to do so.
15:55 nyef: Current Linux has HDMI 3D kernel support for i915 and nouveau, not sure about any other hardware... And not sure if any of it goes as far back as 4.4.
15:55 Riastradh: nyef: Well, I'm planning to update to 4.18 soon too.
15:58 nyef: ... Looks like the nouveua HDMI 3D stuff was merged for 4.12. The intel stuff was earlier.
15:58 nyef: s/nouveua/nouveau/.
15:59 Riastradh: Anyone have a good idea of what ducks I need to have lined in a row for a mode switch to happen, once the modes have been correctly detected? What should I be focussing on to make sure the right commands get sent to the right place in the device?
15:59 gnarface: something about xrandr maybe?
16:00 nyef: Riastradh: Ancient laptop display basically means LVDS, doesn't it?
16:00 Riastradh: nyef: Yes.
16:01 nyef: Oh. The driver is trying to re-POST the panel, isn't it?
16:01 Riastradh: I confirmed that it gets the right EDID modes from the display -- had a bug in that for a while but it's fixed.
16:01 Riastradh: gnarface: I will see if I can get useful xrandr output. (Haven't tried launching X at all yet.)
16:04 nyef: Umm... Another pretty basic thing to check is if it's "just" the panel backlight.
16:05 Riastradh: dmesg from working old 3.15 nouveau: https://www.netbsd.org/~riastradh/tmp/20180821/old.20180821.0
16:05 Riastradh: dmesg from not-working 4.4 nouveau: https://www.netbsd.org/~riastradh/tmp/20180821/dmesg.20180821.0
16:10 Riastradh: (I added some debug output for the calls to nv50_crtc_set_image and nv50_crtc_mode_set to see if they were different. Verdict: not as far as I can tell.)
16:11 Riastradh: Wonderful. Attempting to startx resets the system. No stack trace from ddb!
16:13 Riastradh: nyef: It could be the backlight is off. How can I try to force it on?
16:14 Riastradh: Or, how is it normally turned on when nouveau starts up?
16:15 nyef: It should normally be on. It's an unlikely thing to go wrong, on several levels, but it's an easy thing to check with a decent directional light source.
16:16 nyef: I'm sortof looking at the question as "what can go wrong with a modeset that would cause a blank screen".
16:17 nyef: The backlight getting disabled is one, and an easy one to diagnose, since it's mostly a matter of supplying light and seeing if the LCD itself has pixels set.
16:19 nyef: Panel power is harder to diagnose, in a way, since it's about half GPIO and half CRTC configuration (my system has the panel power GPIO configured either to be automatically controlled by PDISPLAY or to be manually controlled by twitting the GPIO line directly, depending on if it has an LVDS or eDP panel attached).
16:19 nyef: But there are also "display scripts" to be run on modeset, and something could be going wrong with those.
16:20 nyef: (These scripts are bytecode scripts stored in the VBIOS, and they can be wrong or the script interpreter can be wrong...)
16:21 nyef: It's almost certainly not an HPD issue, given that it's an LVDS panel.
16:23 nyef: (Actually, the presense of scripts in the VBIOS basically mean it's "non-libre", doesn't it?)
16:27 RetardedOnion: Riastradh as said: I just wanted to ask, not insult those who do not aim for a libre system. If you don't push snap/flatpak/docker/Debian uselessly we can have a conversation.
16:40 kernel-3xp: a libre system is kinda pointless imho, everything is required to be backdoored by the us govt. etc. once you plug in a network cable... and you cant change the hw using a libre system maybe the TLAs even laugh about it...
16:43 RetardedOnion: the point of a libre system is not security. we would do microcode updates. and use newer platforms.
16:44 kernel-3xp: ah ok what is the point then?
16:47 RetardedOnion: i guess you cant escape the backdoors build by governments, but at least try your best to get around it by using libreboot. for me a libre distro makes more sense so i dont install closed software. closed software is a potential backdoor and systems to phone home by some weired guy that kills minorities while you sleep(or something). its more of an ideology, but every software must be gpl in these distros (why is linux still gpl?).
16:51 RetardedOnion: actually: i wont use libreboot because its way slower than coreboot. it doesnt really add much on top so you are better off using coreboot without binaries
16:52 RetardedOnion: with slower i mean the release schedule
16:53 kernel-3xp: yeah i understand and respect that, ofc anything closed source needs to be viewed as a backdoor i agree, ah ok
16:53 `ani`: I need to find a graphics card for sale that runs 3D acceleration with free drivers.
16:55 RetardedOnion: `ani`: a new gpu that runs with free drivers? amd.
16:55 `ani`: RetardedOnion: the new AMD cards require non free software.
16:55 `ani`: I haven't found one.
16:55 `ani`: I have two, they don't work.
16:56 gnarface: RetardedOnion: to be clear, i don't think you're wrong in principle about this. it's just that it's not practically achievable with the way most hardware is manufactured these days. we need to fundamentally change the way hardware is designed and made market-wide before these types of ethical stances can be put to practice.
16:56 RetardedOnion: rx 460 works with amdgpu. do you need a gpu for a libre system without proprietary blobs? i think the 780 ti.
16:57 gnarface: it would be my first choice too, but don't believe there's nothing evil hidden in that hardware
16:57 RetardedOnion: there is no free gpu. none.
16:58 kernel-3xp: evil hw, yes
16:58 gnarface: yea, i lament this. what the linux community really needs is a reference spec opengl accelerator. modest power but no tearing in compositing.
16:58 RetardedOnion: gnarface: actually: nobody cares so nothing will change. spyware is everwhere and its not going away. you can do your best but noone will follow because noone has standards like this
16:59 RetardedOnion: just look at how discord is used everywhere. its litterally the definition of spyware.
16:59 gnarface: RetardedOnion: you and i clearly care, despite not having any means to fix it ourselves. that's not no-one.
16:59 gnarface: heh. don't get me started on discord. i'm pretty bitter actually.
16:59 RetardedOnion: gnarface: give some money to lowrisc?:D
16:59 RetardedOnion: oh discord is not even the worst
16:59 `ani`: would there be a list apart from h-node or something that I can view to see what AMD cards work?
17:00 `ani`: rx 460 and 780 ti?
17:00 gnarface: doesn't the Xorg page have a list?
17:00 gnarface: they had a list but i don't know how current it is
17:00 gnarface: they had pages for every driver
17:00 RetardedOnion: `ani`:what card do you want? a libre compatible or a card running with open drivers?
17:01 `ani`: RetardedOnion: a libre compatible.
17:01 RetardedOnion: `ani`: no good list. i asked around, i will get the 780 ti soon(tm)
17:01 RetardedOnion: seems to be the best one available.
17:01 `ani`: RetardedOnion: is the 780 ti available in stores?
17:02 `ani`: I swore I would never buy from AMD again.
17:02 RetardedOnion: every amd card in the last 10 years requires firmware. no the 780 ti is not available in stores. you are better off with an intel igpu. those just require blobs for powermanagement
17:02 gnarface: they don't make it anymore but i bet you can buy old stock 780's
17:02 gnarface: i bet you can find them on clearance on amazon.com
17:03 `ani`: ok.
17:03 RetardedOnion: if you can get igpus up to broadwell they run wihtout blobs
17:03 kernel-3xp: maxwell1 quadros might work aswell
17:06 kernel-3xp: k2200
17:15 Riastradh: nyef: The backlight is definitely off, but there's also definitely nothing on the display, even with the help of a bright light source.
17:16 nyef: Riastradh: Okay, so it's more likely to be panel power, which means either a GPIO issue (unlikely), a PDISPLAY issue with respect to LVDS configuration, or something with the output scripts.
17:16 Lyude: karolherbst: we run all of the normal fini methods in nouveau before the system shuts down if the module is still loaded, right?
17:16 karolherbst: Lyude: not quite sure, maybe?
17:16 nyef: ... Or there could be more complexities to the entire thing that I'm unaware of or not thinking of at the moment.
17:17 Riastradh: nyef: Funny: the _old_ nouveau prints a PDISP error INVALID_STATE to the console, but it works just fine.
17:17 Lyude: karolherbst: ahh, well I finally figured out an actually reliable reproducer for the random disp issue
17:17 Riastradh: So does the new one.
17:17 Riastradh: Hmm. They're different, though.
17:17 Riastradh: Old: [ 1.045096] drm kern error: nouveau E[ PDISP][nouveau0] 0x0094: 0x00000000 -> 0xcafe0000
17:17 Riastradh: New: [ 1.044469] nouveau0: info: disp: 0094: 00000000 -> f0000000
17:17 Lyude: strangely enough: boot machine while docked, load nouveau, undock machine, let GPU suspend, reboot with nouveau still loaded (which causes it to resume the GPU right before shutdown)
17:18 nyef: Crazy question, but... Have you tried booting a Linux 4.4 kernel on this hardware? It'd tell you if it's nouveau, or your porting job.
17:18 Riastradh: A few other values printed are different too.
17:18 Riastradh: nyef: No, I haven't...
17:18 Riastradh: But 3.15 worked fine, so it would be a little surprising if it doesn't work. Not a lot surprising -- regressions happen -- but a little.
17:19 nyef: There have been a couple of major architectural shifts in nouveau over the years, they can break compatibility for a bit, and this may have been one.
17:19 Riastradh: Lemme see if I have an Ubuntu 16.04 image lying around.
17:19 nyef: It should be an easy thing to check, too. Or, at least, a straightforward thing to check.
17:41 karolherbst: progress!
17:53 Riastradh: _Would_ be straightforward if my cat didn't run off with all my spare USB flash drives as toys.
17:56 RetardedOnion: i guess you sometimes find usb sticks somewhere. my usb sticks usually just die.
18:01 Riastradh: Bah, Ubuntu 16.04.5 moved to a 4.15 kernel.
18:03 RetardedOnion: whats wrong with 4.15? other than its not lts?
18:04 kernel-3xp: you can always compile your own one
18:13 Riastradh: RetardedOnion: It is not the reference version against which I'm trying to compare.
18:30 Riastradh: nyef: 4.4 works fine here.
18:38 Riastradh: nyef: So you think it's worthwhile to try to diagnose how the panel gets powered?
18:39 Riastradh: Is that nvkm/engine/disp?
18:41 nyef: Umm... You have two bodies of code that are supposed to have the same effects on the hardware. Some amount of the hardware state is visible via mmio access. Copy out both sets of state and compare them?
18:42 nyef: This should tell you either "there's a difference here, look more closely at how it gets set up" or "there is no difference here, look at things that are not directly visible via mmio."
18:42 Riastradh: Urgh.
18:42 nyef: Yeah, I know.
18:44 nyef: The "interesting" range for this is going to start at 0x610000, runs for 0x20000 bytes, and is 32-bit access only.
18:45 Riastradh: Is there some kernel boot option that will dump the mmio access?
18:45 nyef: I think that there's something in envytools that can read out the mmio area, given access to the PCI device.
18:46 Riastradh: How would I use that at boot time?
18:46 nyef: You wouldn't. ssh in once the display has loaded or failed to load and work that way.
18:46 Riastradh: Blef.
18:47 nyef: You're looking to compare the post-startup states. One of them is right, one is wrong.
18:47 Riastradh: Oh, you mean just read half a megabyte of data from mmio?
18:47 nyef: Well, you could also arrange to run the script to do the dump as part of your startup script.
18:47 Riastradh: or however much that is
18:47 nyef: 128k.
18:48 nyef: We could narrow down more-probable regions with a bit of work?
18:48 Riastradh: Can I just dd from /dev/mem?
18:48 nyef: Umm... Maybe?
18:48 Riastradh: How do I read the PCI BARs from Linux userland?
18:49 nyef: I don't know how well it will react to non-32-bit access, and I don't know if dd will do only 32-bit access.
18:49 Riastradh: Oh, OK, sure, I can write a program to do 32-bit access.
18:49 nyef: http://www.lisphacker.com/temp/crtc-lcd-test.lisp might help as far as finding access to PCI space from Linux userland goes.
18:50 nyef: But don't actually run that as-is.
18:50 Riastradh: Heh.
18:51 nyef: (I think that I may have written that for an NV17 or so.)
18:55 mslusarz: karolherbst: if they will change ioctl or struct definitions in those header files demmt will not be able to decode traces created with previous version
18:58 Riastradh: nyef: BAR 0, right?
19:00 mslusarz: karolherbst: and they will change, just like they did it many times for other ioctls
19:00 karolherbst: ahh, okay
19:01 karolherbst: so using nvidia headers directly isn't such a bad idea afterall
19:01 Lyude: anyone know what PMC actually stands for in nouveau? e.g. PMC like the PMC.ENABLE register at 0x200
19:01 dbristow: Having trouble with a new nvidia gt 1030 card on debian 8
19:02 dbristow: Pretty cheap card but blank screen when finishes the boot sequence
19:02 karolherbst: mslusarz: anyway, it seems I made "some" progress as demmt started to print some "GP104_COMPUTE.UPLOAD.DATA" things
19:02 mslusarz: karolherbst: it is a bad idea if you want to decode traces created with other than current blob version
19:02 karolherbst: mslusarz: sure, but does demmt support that itself anyway?
19:02 mslusarz: yes
19:02 dbristow: Would like a card that works out of the box with nouveau, don't really want to install the nvidia proprietary driver
19:03 dbristow: Should I try a 1060?
19:03 mslusarz: karolherbst: it deals with many interface versions
19:03 RetardedOnion: dbristow: new cards will likely never work well with nouveau since nvidia fights hard against it.
19:04 karolherbst: mhh, it really didn't look like it
19:04 Lyude: no they will work with nouveau
19:04 dbristow: I wouldn't mind an old card but we
19:04 Lyude: just, right now reclocking isn't really a thing
19:04 dbristow: we're going from a 450
19:04 dbristow: I need something that does 1080p hdmi
19:04 mslusarz: karolherbst: one ugly example: https://github.com/envytools/envytools/blob/master/demmt/nvrm.c#L582
19:05 Lyude: RetardedOnion: also come on man, do you really need that nickname
19:05 karolherbst: mslusarz: uhh, yeah, that is ugly
19:05 dbristow: I don't care how new it is, just has to be on the shelf at microcenter
19:06 karolherbst: dbristow: check dmesg and the X log
19:06 karolherbst: maybe there is something
19:06 mslusarz: karolherbst: also IOCTL_MEMORY vs IOCTL_MEMORY2, IOCTL_CREATE_VSPACE vs IOCTL_CREATE_VSPACE56, etc
19:06 RetardedOnion: Lyude: no but i used it for years. if you think it is necessary to change my name i can just leave.
19:06 dbristow: I saw "unsupported chipset"
19:07 karolherbst: mslusarz: okay, but those are different ioctls, no?
19:07 mslusarz: karolherbst: different methods, like subdevice_get_chipset vs subdevice_get_chipset16
19:07 karolherbst: dbristow: guess you need to update your stack
19:07 Lyude: RetardedOnion: you know where the door is then
19:08 RetardedOnion: Lyude: there aint no rest for the triggered.
19:08 Lyude: lol
19:09 karolherbst: Lyude: some persons are just trolls by nature ;)
19:09 Lyude: karolherbst: yep...
19:09 karolherbst: or at least thourougly sarcastic
19:10 Lyude: karolherbst: gah; so it seems like the gr is actually stuck on by the time nouveau gets the GPU from the bios when the weird state that caused those disp failures happens
19:10 Lyude: sort of\
19:10 mslusarz: karolherbst: yes, they are, sometimes they change ioctl ids (by changing data size id also changes), so it's clear what has changed, but sometimes they change the meaning of some fields
19:10 karolherbst: mslusarz: right.. anyway, I try to get it working first, but _something_ is still wrong on my end
19:10 Lyude: 0x200 shows it's enabled on the PMC
19:10 nyef: Riastradh: Yeah, BAR 0.
19:10 karolherbst: mslusarz: would be ncie if we could just copy headers from each versions and handle all the differences... :(
19:11 mslusarz: yeah
19:11 karolherbst: mslusarz: anyway, here are the parsed UVM ioctls: https://gist.githubusercontent.com/karolherbst/ec225a9d659833637a1e8b969b39e03e/raw/7e6363da9892d03d0b18f0f9a6e78c3b4b678f7c/gistfile1.txt
19:11 karolherbst: and it looks pretty much correct
19:11 karolherbst: I am not 100% what UVM_MAP_EXTERNAL_ALLOCATION does though
19:11 mslusarz: nice
19:12 karolherbst: mslusarz: mind looking at the parsed demmt output and see if you find something?
19:12 mslusarz: sure
19:12 mslusarz: or, "why not" :)
19:12 karolherbst: mslusarz: for UVM_MAP_EXTERNAL_ALLOCATION I add a new gpu_mapping
19:13 mslusarz: sounds sane :)
19:14 karolherbst: demmt changes: https://github.com/karolherbst/envytools/commit/b3a4e458843ee04b5eac599de18cddfb7e410f75
19:14 karolherbst: parsed file still compressing :(
19:15 karolherbst: mslusarz: https://drive.google.com/open?id=1TfY7HhawniPH-Zjxk_aFDTNR_VA97TgU
19:16 mslusarz: lol, nice bugfix for print_d64_align
19:16 Riastradh: nyef: Urk. These dumps look...completely different.
19:16 karolherbst: :)
19:16 Riastradh: Oh, wait.
19:16 Riastradh: Never mind, pebcak.
19:18 Riastradh: Hm.
19:18 Riastradh: Still completely different.
19:19 kernel-3xp: karolherbst: is it advisable to use the nouveau driver of your github repo?
19:19 karolherbst: kernel-3xp: huh? what do you mean?
19:19 karolherbst: for what?
19:19 Riastradh: nyef: 0x20000 bytes at register 0x610000 starting from BAR 0, right?
19:19 kernel-3xp: for daily use
19:20 karolherbst: kernel-3xp: depends. I have many branches, but usually there is no difference from whatever skeggsb has, except some WIP stuff
19:20 karolherbst: might be a different case if you need some special fixes though
19:20 nyef: Riastradh: Yeah. Byte-indexed, word values, so bumping the pointer by 4 each time.
19:21 Riastradh: Is BAR 0 expected to be a 32-bit BAR?
19:21 kernel-3xp: ah ok i thought maybe it was kinda more advanced
19:21 nyef: Let's just do a basic sanity check: What's the first 32-bit word in each dump?
19:22 Riastradh: Linux: 00000010 00000001 0000007d 00000082
19:22 nyef: Should be something like 0x827d0110 ?
19:22 nyef: Hrm.
19:22 Riastradh: NetBSD: 827d0110 00000000 00000000 00000110
19:23 Riastradh: This smells like I screwed up the Linux dump.
19:23 nyef: Okay, so the... yeah.
19:23 Riastradh: Bah, I wrote that program on /tmp during the Linux boot.
19:24 karolherbst: mslusarz: or maybe it looks good enough and I just need to handle those remaining UVM_REGISTER_CHANNEL ioctls
19:24 nyef: Actually, heh. Do you see the 827d0110 in the Linux dump? Because I do, even if it's not quite useful that way. (-:
19:24 Riastradh: Yes, I do. I got bytes instead of words, it seems.
19:24 Riastradh: However, I only got 1/4 of the mmio range, obviously!
19:26 karolherbst: mslusarz: mhh, actually, I found the compute shader
19:26 karolherbst: PB: 0x6260206d size 608, subchannel 1 (class: 0xc1c0, desc: GP104_COMPUTE, handle: 0x0000c1c0), offset 0x01b4, constant
19:26 karolherbst: PB: 0xfe0007f6 GP104_COMPUTE.UPLOAD.DATA = 0xfe0007f6
19:26 karolherbst: ...
19:26 mslusarz: great
19:26 karolherbst: sched (st 0x6 yl) (st 0x0 yl) (st 0x1 yl wr 0x0) mov $r1 c0[0x20] 0xf mov $r3 c0[0x8] 0xf mov $r0 $ctaidx
19:26 karolherbst: and so on
19:26 karolherbst: but... demmt should parse that itself :)
19:28 karolherbst: :O
19:28 karolherbst: insane
19:28 karolherbst: https://gist.githubusercontent.com/karolherbst/60bb7766e1491483829aa1ae3e96244c/raw/8a3d225122aec11d6b8b315218716251e1c7c200/gistfile1.txt
19:28 karolherbst: no clue what that is after the first exit
19:28 karolherbst: uhm
19:28 karolherbst: first block
19:30 Riastradh: That looks more reasonable.
19:30 karolherbst: anyway, that looks like correct code
19:31 dbristow: Any ideas on what video card might work out of the box on Debian?
19:32 Riastradh: -00000010 09 ec 0f 00 00 00 00 00 64 59 f9 14 0f 00 00 00 |........dY......|
19:32 Riastradh: -00000020 00 00 00 00 00 00 00 00 00 00 1f 00 74 03 00 00 |............t...|
19:32 Riastradh: +00000010 09 ec 0f 00 00 00 00 00 05 ae 95 1f 0f 00 00 00 |................|
19:32 Riastradh: +00000020 00 00 00 00 04 00 00 00 1f 00 1f 00 70 03 00 00 |............p...|
19:32 dbristow: Right now the box doesn't seem to come up to be pingable without a monitor connected
19:32 Riastradh: nyef: - is linux, + is netbsd.
19:32 karolherbst: dbristow: none
19:32 karolherbst: don't use debian
19:33 karolherbst: debian is good for 5 years old GPU, because by then they managed to move to a reasonable kernel :p
19:33 nyef: So, deltas at 0x18, 0x24, 0x28, and 0x2c right off the bat?
19:33 karolherbst: mslusarz: okay, that was just nvidias insane idiv lowering
19:34 Riastradh: nyef: Yes. Where do I find what these offsets are?
19:34 karolherbst: okay, so now get demmt to parse that shader
19:34 nyef: envytools, rnndb/display/g80_pdisplay.xml
19:34 nyef: 0x24, 0x28, 0x2c are interrupt status and enable registers.
19:37 Riastradh: Status makes sense; enable, not so much.
19:37 nyef: ... And it only now occurs to me that another angle might be mmiotrace, if you have mmiotrace on netbsd.
19:37 mslusarz: karolherbst: it seems 0xc06f0101 is a new version of NVRM_MTHD_FIFO_IB_OBJECT_INFO
19:37 Riastradh: Oh, but that might be because X is running on Linux.
19:37 Riastradh: What is mmiotracE?
19:37 karolherbst: mslusarz: ohh, I guess I need to re that
19:37 mslusarz: karolherbst: you will get rid of many ERRORs if you will handle it
19:38 karolherbst: okay
19:38 karolherbst: thanks
19:38 mslusarz: that's not much to RE
19:38 nyef: Trace framework. Set it going before you load a driver, and it will log all memory map performed, and all I/O to the mapped spaces.
19:38 karolherbst: mslusarz: also "PB: 0x0044d400 GP104_COMPUTE.TRAP_HANDLER = 0x44d400" \o/
19:38 mslusarz: karolherbst: it seems they only changed the id, struct look the same
19:40 Riastradh: Anyway, here's the full diff: https://www.NetBSD.org/~riastradh/tmp/20180821/mmiodiff
19:42 Riastradh: How do I find what part of nouveau is responsible for each register?
19:42 Riastradh: Grepping for 0x0*24 and INTR_0.*24 doesn't turn anything obvious up.
19:42 nyef: Grep for the offsets.
19:42 Riastradh: Oh, 610024.
19:43 nyef: Which one of these is which?
19:43 Riastradh: Also it would help if I had said INTR_1.*24 instead of INTR_0.*24.
19:43 karolherbst: mslusarz: I guess 0xb06f0101 is another one, as we only have 0x9 and 0xa
19:44 nyef: Hrm. "CHANNEL" setup is different, whatever that is...
19:44 Riastradh: But OK, anyway, interrupt stuff is going to be different because of X vs not-X, I imagine.
19:44 Riastradh: (not-X ---> no vblank irq)
19:46 karolherbst: mhh, still two of those errors left
19:46 mslusarz: karolherbst: yup, the upper part ot the id seems to be fifo_ib class
19:46 Riastradh: <reg32 offset="0x0080" name="TRAPPED_ADDR"/>
19:46 Riastradh: <reg32 offset="0x0084" name="TRAPPED_DATA"/>
19:47 karolherbst: 0x0000c1b5, driver forgot to call NVRM_MTHD_FIFO_IB_OBJECT_INFO? and for 0x0000c197 as well
19:47 karolherbst: ohh, might be different ids now
19:47 Riastradh: Is this likely to mean an error? There are a few more bits set here.
19:50 karolherbst: mslusarz: ohh, the code is only dumped when X_COMPUTE.LAUNCH is called, but it isn't
19:50 karolherbst: or at least it isn't in the trace
19:51 mslusarz: karolherbst: to make REing easier you should resolve all "[no data]" errors
19:51 mslusarz: you can do that by using mmt's ioctl fuzzer
19:52 karolherbst: mslusarz: what does 'no data' mean? valgrind-mmt wasn't able to trace date writes/reads at that address?
19:53 mslusarz: it means mmt didn't record what was behind this address, because it didn't know how much data it should record
19:53 karolherbst: ahh
19:53 mslusarz: ioctl_create fuzzer will help you find that size
19:53 mslusarz: and then you'll be able to make change like this: https://github.com/envytools/valgrind/commit/369a553f5fbcb0b4c8081cb07758a0ae7e6f07cd
19:54 karolherbst: okay
19:54 karolherbst: but for what do I look inside the traces then?
19:55 nyef: Riastradh: So, I'm not seeing anything obvious here, unfortunately.
19:55 nyef: There are a lot of differences, but mostly in places that I'm not seeing documentation.
19:56 mslusarz: fuzzer generates ioctls with increasing size (using memory just below unmapped page), and the first one that succeeds tell you the size
19:56 karolherbst: mslusarz: ahh
19:56 Riastradh: nyef: I'm trying to boot into single-user mode to see if I can get it without X.
19:57 karolherbst: like that one: https://gist.githubusercontent.com/karolherbst/b2c680e88d45121a24658b803f5e20d9/raw/de30fee98a0d2f97426c6d321bfad86e99eb8476/gistfile1.txt
19:58 karolherbst: ahh LOG: MSG: ==21216== minimal argument size for class 0x83de: 12 bytes (3 words)
19:58 mslusarz: yeah
20:00 karolherbst: mslusarz: {0x0080, 8}, // 10 on maxwell/340.32, TODO -> 14 on pascall/390
20:00 mslusarz: heh
20:01 mslusarz: mmt isn't prepared to handle that
20:01 annadane:scrolls up, frowns
20:01 annadane:uses debian...
20:02 karolherbst: mslusarz: yeah, I will go through all the stats and add all those things
20:04 mslusarz: so have you figured out what was wrong with c1b5 and c197?
20:28 karolherbst: mslusarz: I have a meeting right now :), so I will look into that later
21:26 spinningCat: hey
21:26 spinningCat: how to set #nouveau in debian?
21:26 spinningCat: nvidia properiaty driver did break my system
21:28 karolherbst: spinningCat: I guess you have to remove nvidia first
21:28 karolherbst: and repair your syste,
21:28 karolherbst: *system
21:28 spinningCat: i removed that
21:31 spinningCat: do you know how to set nouveau driver in system
21:35 pmoreau: The kernel part should already be there, make sure that you install mesa (and xf86-video-nouveau).
21:35 spinningCat: that driver is ralready installed
21:36 spinningCat: after installing nvidia-drivers my system is broken
21:36 pmoreau: And also make sure that the kernel module is not being blacklisted: looks in /etc/modprobe.d and /usr/lib/modprobe.d
21:37 spinningCat: yes
21:37 spinningCat: driver is blackliste
21:37 spinningCat: d
21:37 spinningCat: should i remove that line?
21:38 spinningCat: i have nvidia-blacklists-nouveau.conf
21:38 pmoreau: You can probably remove the whole file even
21:38 pmoreau: Unless it contains something you want to keep
21:39 spinningCat: just one line
21:39 pmoreau: Which is "blacklist nouveau"?
21:40 spinningCat: yes
21:40 spinningCat: i removed that file
21:40 spinningCat: i have dkms.conf nvidia.conf nvidia-kernel-common.conf
21:40 spinningCat: should i remove those also?
21:40 pmoreau: Look at their content first
21:41 pmoreau: If they don’t blacklist Nouveau, it is probably fine to keep them.
21:47 Lyude: karolherbst: jfyi, I just made a very big discovery about the disp failures thanks to skeggsb's help: the P50 is leaving the card on between reboots!
21:48 karolherbst: Lyude: :D
21:48 karolherbst: sooo, we don't do a full repost?
21:49 Lyude: karolherbst: no, although if you know if there's a way we can we should probably add that to nouveau anyway
21:49 spinningCat: x still didnt come
21:49 Lyude: agd5f: btw, have you guys seen any issues like this with AMD cards before? ^
21:53 pmoreau: spinningCat: Anything showing up in dmesg?
21:56 spinningCat: a lot of thing
21:56 spinningCat: what specifically i am looking for
21:57 pmoreau: For messages from nouveau ;-)
21:58 pmoreau: I’ll have to go though; hopefully someone else can help you.
22:08 Lyude: karolherbst: on newer prime systems, _PR is the ACPI method we call during runtime suspend/runtime resume, right?
22:08 karolherbst: yes
22:23 karolherbst: :O
22:23 karolherbst: I've found the nvidia trap handler
22:23 karolherbst: the heck
22:30 karolherbst: and I don't see how the save thr registers
22:30 karolherbst: *the
22:31 karolherbst: or maybe they don't and we can actually read them out after the trap handler
22:31 karolherbst: or something
22:32 karolherbst: ohh, there are random jumps
22:32 karolherbst: fun
23:17 dbristow: So it turns out that my nvidia 450 has a mini HDMI out port that I didn't know about, so I just got a mini HDMI to HDMI converter cable, works fine.
23:18 dbristow: Had to get a new HDMI KVM, but that was no big deal and most everything works now.
23:27 spinningCat: HDMI to HdMI converter
23:27 spinningCat: what is the thing converted here?
23:29 dbristow: spinningCat, The video card had a mini HDMI port, so I got a mini HDMI to HDMI converter. Simple cable.