05:50lovesegfault: karolherbst: did those patches I use get merged into 5.7?
09:34karolherbst: lovesegfault: yeah
10:49fincs: Apparently Nvidia released copy class methods: https://github.com/NVIDIA/open-gpu-doc/commit/091824d969e7633b5a69b6d50e648fa5e9100d61
10:49fincs: Now that's something that can be realistically used \o/
11:05karolherbst: I actually will need those as well :D
11:06karolherbst: "MEMORY_LAYOUT_PITCH" ohh, interesting
11:07karolherbst: imirkin: I don't think we make use of that yet, right?
11:07karolherbst: we also do blocklinear copies
11:07fincs: Yeah, that's something nouveau previously called src_is_pitch_linear or something
11:07karolherbst: ohh, maybe we do use it...
11:07karolherbst: anyway, need it for CL :D
11:08fincs: So that's 2 engines down
11:08karolherbst: PHYS_MODE_TARGET :O
11:08fincs: ( ͡° ͜ʖ├┬┴┬┴
11:09karolherbst: some L2 bypassing as well
11:09fincs: What's "rmw disable"?
11:09fincs: Also it seems like this can bypass the mmu and copy physical addresses?!
11:10karolherbst: I don't think so
11:10karolherbst: the heck
11:11karolherbst: that's... uhm
11:12karolherbst: that would be a massive security issue
11:13RSpliet: is that for VRAM->VRAM?
11:13karolherbst: RSpliet: no
11:14karolherbst: you can also copy from sysmem
11:14karolherbst: or to
11:14fincs:laughs in unified memory
11:14karolherbst: that's the normal m2mf/p2mf engines we can program through push buffers
11:14RSpliet: that's what I thought. I presume "PHYSICAL" here means the IOMMU virtual address
11:14karolherbst: now I am wondering if we really need to parse pushbuffers in the kernel and protect such stupid shit
11:15fincs: I doubt so
11:15fincs: I remember the GPU on the Nintendo 3DS was essentially 80% unprotected physical addresses
11:15fincs: And you could abuse the GPU to pwn parts of the system and take over code execution :p
11:15karolherbst: it doesn't matter there
11:16karolherbst: but on the normal desktop that would be huge
11:19RSpliet: there may be a kernel or firmware configuration to permit/forbid such transfers, can't judge from just the command format. Also, if we use the IOMMU correctly, the data leaking is limited to framebuffers and other GPU buffers between user contexts.
11:19fincs: "NVB0B5_SET_DST_BLOCK_SIZE_WIDTH_QUARTER_GOB" <-- what
11:20RSpliet: There's plenty of other such leaks around, I think mupuf did a presentation many many moons ago abott how not clearing buffers upon deallocation is a data leak source dead easy to exploit.
11:26RSpliet: fincs: a couple years ago someone had a proof-of-concept that disabled SELinux through PMEM. NVIDIA exposed access to PMEM to anyone opening /dev/nvidiactl or a channel like that - which iirc was world read-writeable.
11:26fincs: Heh, sounds like fun
11:27RSpliet: They since blacklisted that register range, user-space doesn't need PMEM
11:27RSpliet: IOMMUs are an essential part of computers, and we ought to take them more serious :_D
11:53karolherbst: RSpliet: we don't use an IOMMU
11:53karolherbst: or it's disbaled by default
11:53karolherbst: we only really have the iommu code for tegra devices afaik
11:54karolherbst: and... IOMMUs are not even essential. These days yes, but 5 years ago they weren't that common
11:54RSpliet: It is my opinion that we should! But... I'll let people who actually do work on this to decide what priority that should get
11:54RSpliet: Yeah I know, everyone's been slow at adopting them for any other reason than VMs
11:54karolherbst: well, with TB they are required :p
11:54karolherbst: or should be
11:55karolherbst: but that's the modern reason to use them
11:55RSpliet: They should have been required with firewire :-D
12:06fincs: Heh, actually these copy class methods are not new
12:07fincs: They were already distributed within the linux blob driver package
12:07karolherbst: inside uvm or somewhere else?
12:07fincs: Can't remember
12:08fincs: But if you download the driver package from Nvidia's official website, you'll find clNNNN.h headers somewhere inside
12:09fincs: So basically they're still moving in stuff that was public somewhere else
12:09karolherbst: yeah, that's uvm
12:10karolherbst: maybe I create a PR against the open-gpu-doc with missing files :D
12:10fincs: Good idea
12:11karolherbst: those are actually MIT licensed or something... don't know the exact one
12:11karolherbst: or some BSD
12:11fincs: There is some really useful gpfifo shit in there too that's not yet in open-gpu-doc
12:11karolherbst: MIT it is
13:41imirkin: fwiw we do use those copy engines already...
13:42imirkin: they're used by the kernel, since they're async
13:42imirkin: it's the "COPY" buffer move method
13:43imirkin: it's good to get docs... on nva3/nvc0, they're firmware-assisted, so the nouveau firmware might not 100% match up to theirs
13:43imirkin: in terms of API
14:06karolherbst: imirkin: but this is p2mf/m2mf
14:06karolherbst: aka the thing we use in userspace
14:07imirkin: the kepler+ p2mf is identical yea
14:07karolherbst: we were curious why there is some physical vs virtual stuff going on though
14:08karolherbst: that sounds... potentially dangerous
14:08imirkin: probably terminology error... i assume this always goes through the gpu vm
14:08karolherbst: if not.. this would mean a lot of work for us :/
14:45mixfix411: you guys use amd or intel for your towers
14:46mixfix411: amd looks kinda good esp just one processor, amd3+ chipsets
14:47gnarface: about half and half honestly, but i like the amd ones more
14:47fincs: Currently AMD CPUs are pretty strong
14:47fincs: And Intel has not laid out a proper response yet
14:48mixfix411: yea i wasnt aiming for the top line ones
14:48mixfix411: i went with cheap intels on my gaming pcs
14:49mixfix411: but i drifted away from those
14:49mixfix411: you can only game so much
14:49fincs: Even in high end you see AMD CPUs with many more cores and great performance
14:49mixfix411: but not to say im not playing something _now_
14:51imirkin: mixfix411: i upgrade once about every decade... previous box as AMD tbred, this one is intel. i think next will be AMD.
14:51fincs:currently running a Ryzen 7 3700X
14:51imirkin: (technically previous box started out as tbird, which i was then able to upgrade to tbred. yay for compatible sockets... too bad nobody does it anymore)
14:53imirkin: (got to be a major pain to get chrome running, since the official builds required sse2)
14:56mixfix411: oh i didnt it effects packages that way even ah i guess processor packages i thouhgt they all just worked
14:56imirkin: well, the cpu was like 10yo by then
14:56imirkin: only supported 3DNow! and SSE, but not SSE2
14:57mixfix411: was it just one patch
14:57imirkin: modern AMD CPU's support things like AVX2, etc
14:57mixfix411: or no patch was there
14:57imirkin: just compiler settings when building, i imagine.
14:57imirkin: when i built it myself, it worked fine. but took like 2 days.
14:57mixfix411: oh ok yeah im building firefox on arm and i pulled the patches from arch linux hopefully it builds on slackware
14:58mixfix411: looks good so far
14:58mixfix411: hoping its not a black screen like it usually is but i updated the distro and now it seg faults
14:59mixfix411: oh yea on a single core processsor i dont build chrome ever
15:00imirkin: good stuff. 180nm process.
15:00mixfix411: on slackware live chromium chromes already on here
15:00mixfix411: live edition
15:00mixfix411: maybe its in slackware in general probs
15:00imirkin: anyways, this is not a slackware support chan
15:00imirkin: good luck with your issues.
15:01mixfix411: yea you guys are really technical
15:01mixfix411: i was looking before i closed finch you were giving a user an understanding
15:31imirkin: hm, so yeah, looking at e.g. c0b5, it does look like it can do stuff to sysmem, bypassing the VM. there's still a iommu though, hopefully.
15:31imirkin: it might also just not be allowed without setting some additional context state
15:41karolherbst: but doing sysmem to vram copies without having to map sounds nice
15:41imirkin: those flags mirror the PTE flags
15:41imirkin: i.e. vram / coherent sysmem / noncoherent sysmem
15:43RSpliet: imirkin: heh. My previous PC was an XP 2800+ (Barton I think). It was 32-bits. And had an AGP port. Has, I should say, it still runs afaik.
15:47imirkin: yeah, that's much newer :)
15:47imirkin: mine had AGP too, but the port fried itself at some point
15:47RSpliet: Only a year right?
15:47imirkin: than XP 1700+?
15:48imirkin: seems like a lot in a year, but perhaps
15:48imirkin: things moved fast back then
15:48imirkin: esp with their fake frequencies :)
15:48RSpliet: I did shell out on high-end back then
15:51imirkin: i was in college, so i got it after it had become cheap already :)
15:52RSpliet: I slaved away a years worth of Saturdays, Tuesday+Wednesday in a supermarket to afford that thing :')
15:52imirkin: i ... did not. i just waited for it to become cheaper.
15:53imirkin: was probably in the $100 range when i got it
15:56RSpliet: Yeah, I don't think I still have the receipts, but pretty sure it was over €200 back then. nForce2 motherboard (they really were the bees knees), GeForce FX 5600 to complement my radiator
15:58imirkin: well this was just a CPU upgrade :)
16:04RSpliet: I did love the good old days where you could just buy RAM
16:05imirkin: i had a super-old box which supported SRAM, EDO DRAM, and SDRAM all at the same time
16:06RSpliet: My current PC only takes Louis Vuitton... it's picky
16:06imirkin: i see supermarket job pays better now, huh
16:07RSpliet: Well, I did move up to HQ in the final year
16:07RSpliet: Java and SAP R/3 dev
16:07imirkin: time well spent
16:56lovesegfault: karolherbst: that's great to hear :)
16:56lovesegfault: congrats on getting that merged
17:41karolherbst: I think I will work on the Nouveau CI this weekend.. enough time and nothing better to do anyway :p
17:49lovesegfault: karolherbst: how does nouveau's CI work?
17:49karolherbst: it doesn't yet, that would be the entire point to make it work :p
17:50lovesegfault: We use jenkins for CI, it works well for our "CI that needs hardware" needs
17:53RSpliet: Yeah, Jenkins is the de-facto standard I believe (or was last time I checked), but also apparently a nightmare to configure
17:53lovesegfault: Yes, it's a nightmare in many ways
17:53RSpliet: Good thing karolhebst has nothing better to do :-D
17:53karolherbst: I won't use jenkins
17:54lovesegfault: Also: if you use jeniks use the blue ocean UI for your own sanity
17:54karolherbst: jenkins has the same effect as anti-virus software on the server, so no way
17:54lovesegfault: What are you thinking of using?
17:54karolherbst: not quite sure yet, but for mesa we have the gitlab-ci stuff
17:55karolherbst: and behind that maybe lava to manage the nodes
17:55karolherbst: not quite sure yet though
17:55karolherbst: I have a switch with PoE support to power cycle tegra devices though :)
17:55karolherbst: this will be nice
19:25uis: I'm banned on #dri-devel
19:26karolherbst: uis: ahh, somebody kicked you because of your broken connection back then
19:26karolherbst: but you shouldn't be banned afaik
19:26karolherbst: maybe it happaned again and somebody went trigger happy
19:35uis: Yes, there is strange connection problem at home network. Mobile net works fine
19:43karolherbst: anyway, there are weird people who are super trigger happy in regards to this
19:43karolherbst: I don't understand those either
19:45HdkR: If it is a very quick disconnect and connect and it lasts for hours I can see it getting a temp ban that accidently never lifts :P
19:46karolherbst: people should just fix their IRC clients if those messages annoy them
19:46karolherbst: it's not rocket science
21:55karolherbst: ehhh uhhh.. ufff
21:56karolherbst: yeah.. using mmiotrace to re that runpm stuff and the machine crashes
21:56imirkin: karolherbst: it's pretty annoying when one person messes up the whole scheme
21:56imirkin: i like seeing who enters/leaves
21:56imirkin: but then someone with a connection problem just messes up the whole thing
21:57karolherbst: sure... but clients also allow you to only list those for active users
21:57karolherbst: and for idling people those are just not shown
21:58karolherbst: and clients can also allow you to blacklist/whitelist it for certain person
21:58karolherbst: I mean.. there are technical solutions to this
21:59karolherbst: but if people rather ban people than to use technical solutions than .. yeah well...
22:24imirkin: ok, so the argument is that because someone isn't following standard netiquette (not producing join spam), i have to change my client? seems a little backwards.
22:25karolherbst: imirkin: well.. if it's because of connection issues?
22:25karolherbst: I can hardly blame that person for that
22:25imirkin: if you have connection issues, don't auto-reconnect
22:25karolherbst: sometimes they just happen randomly
22:25imirkin: it's not the first time for him
22:26karolherbst: well, I don't know it, because I don't see left/joins I don't care about
22:26imirkin: also don't auto-rejoin on kick
22:26imirkin: that's the only reason for the ban
22:28karolherbst: imirkin: I don't see a kick before the ban though
22:29karolherbst: anyway.. I agree with the ban after auto-joining on kick, but not with the ban because of poor conections
22:29karolherbst: we are smart enough to write clients to not annoy us with such crap
22:29karolherbst: and if people prefer to get annoyed, then that's their choice
22:30karolherbst: I decided to not get bothered or annoyed or whatever by join/parts I don't care, so I don't see it and it's better since then
22:30karolherbst: I literally never missed one left/join
22:30karolherbst: missed as in "huh, where did that person go"
22:31RSpliet: Not commenting on individual cases, I do personally feel that auto-reconnecting is crucial to keep a bouncer back-logging. We have the luxury of cbrill logging everything and sticking these logs on-line, but most channels don't offer that luxury. That to me personally far outweighs the "annoyance" of join/part messages when a connection gets wonky.
22:32karolherbst: RSpliet: well, it was about auto-reconnect on getting kicked
22:32karolherbst: but I don't see that kick anyway
22:32karolherbst: and anyway, it's super easy for clients to just ignore join/parts of people who never spoke in a channel for weeks
22:32RSpliet: karolherbst: but the kick was a response to frequent auto-reconnects. I don't feel like that kick would be warranted either
22:33karolherbst: or some other algorithm..
22:33karolherbst: RSpliet: sure, but that person also got baned
22:33karolherbst: and that ban never got removed since then
22:33karolherbst: it's the most stupid reason to get baned, period
22:34karolherbst: if you don't have your client under control, it's your issue and don't blame that on others
22:34karolherbst: poor connectivity happens
22:35karolherbst: IRC is not only a bunch of nerd having the perfect internet connection anymore
22:35karolherbst: and the nerd netiquette was never a good one
22:36RSpliet: It also risks being (unconsciously) discriminatory. Some parts of the world just don't have stable internet connections.
22:36karolherbst: or some have to live with a LTE internet connection at home
22:36karolherbst: we have that even in Germany
22:37karolherbst: clients could even detect if somebody is constantly reconnecting and just don't show those join/parts for some time
22:37karolherbst: the solution is soooo easy
22:37RSpliet: Patches welcome ;-P
22:37karolherbst: my IRC client is fine, I don't have those annoying messages :p
22:38karolherbst: and if RSpliet would leave now, I'd still see it
22:38karolherbst: (without whitelisting)
22:40RSpliet: I suspect I can ask my bouncer to filter them out if it bothers me...
23:35RSpliet: Speaking of the devil. My wired network connection just stopped functioning