06:23ericonr: hey there! Is a bug using DRI_PRIME on intel, though wayland, caused by glthreads too specific? and if not, should I report it in bugs.freedesktop.org/ or in some mailing list?
10:08RSpliet: ericonr: well, glthreads is known broken for nouveau
15:03ericonr: RSpliet: got it, thanks! So no need for more traces or anything?
15:24RSpliet: ericonr: This is one of the few problems that don't require reverse engineering I think. karolherbst is the best person to tell you more about this
15:24karolherbst: :O about what?
15:26ericonr: I had a glitch using glthreads on nouveau
15:26ericonr: with DRI_PRIME, and on wayland
15:27karolherbst: uhh, yeah.. hard to tell what's up there
15:27karolherbst: but yeah...
15:27karolherbst: I think it's best to wait this one out as I've discussed this with skeggsb several times but now we have a plan forward for those threading issues
15:30ericonr: by glitch I mean that my entire session was broken and I had to kill the compositor from another tty. moving the mouse around caused the windows to move about randomly, as well. I'm on sway.
15:30RSpliet: ericonr: I'm under the impression that neither DRI_PRIME nor wayland make a difference here, it's just glthreading :-P
15:31ericonr: makes sense
15:31ericonr: karolherbst: good luck with that! and awesome progress, nouveau was crashing completely for me in 5.5 c:
15:32ericonr: thanks RSpliet too :)
15:32RSpliet: I'd love to see improvement on the matter myself btw :-) glthreading is just a complex beast mainly thanks to legacy
15:32karolherbst: ericonr: ahh, laptop, yeah, I fixed that one :p
15:33karolherbst: 5.5 didn't get the fixed though, missed the last version by a few days
15:35ericonr: shame :p
15:35ericonr: I thought about reporting but hadn't tried 5.6 yet, so I waited around a bit
15:36karolherbst: yeah.. but it didn't get into 5.6.0 as well
15:36karolherbst: it was backported
15:36karolherbst: 5.7 was the first kernel with the fixed
15:36karolherbst: but I just missed the last 5.5 release :)
15:36karolherbst: it's there in 5.4 as well (the fix I mean)
15:38ericonr: ooh got it
15:38ericonr: so it's pretty damn recent
15:38imirkin: skeggsb: https://github.com/skeggsb/nouveau/commit/d6c2f78cac2772fdfece828dc08bdf4e34e5b491 -- did you mean 0 for the mask rather than head << 4?
16:38nightduck: I'm a researcher working on the Jetson boards, and I'm trying to wrap my head around nvgpu, but the internet is scant on details. I figured the Nouveau project would have some STRONG (and well-informed) opinions about it. So questions:
16:38karolherbst: nightduck: use nouveau :p
16:39nightduck: What differentiates it from Nvidia's proprietary drivers or Nouveau? Is nvgpu exclusive to ARM architectures? Can I run Nouveau on a Jetson borad?
16:39nightduck: I take it the answer to my last question is "yes"
16:39karolherbst: there might be bugs though as testing is quite limited, but the GPU bits are essentially identical to desktop GPUs
16:39karolherbst: with minor differences
16:40nightduck: Also, why is their git repo so weird and well-hidden?
16:40karolherbst: of course with nvgpu you could get professional support, but.. you wouldn't probably
16:40karolherbst: nightduck: you mean the one without a git clone URL?
16:40karolherbst: using l4t on the jetson is fine though as long as you require CUDA and all the stability etc...
16:41karolherbst: but.. then you essentially use an ubuntu fork with a custom kernel
16:41nightduck: karolherbst: The link I've found: git://nv-tegra.nvidia.com/linux-nvgpu.git. Idk if it matches what ships with l4t
16:42karolherbst: that's probably the URL for https://nv-tegra.nvidia.com/gitweb/?p=linux-nvgpu.git;a=summary
16:43karolherbst: yeah... it is
16:43nightduck: Yeah, but I can't git clone a webpage :P, and the site convenientally neglected to provide the git link
16:44karolherbst: normally a recent linux kernel should just work (tm), I just don't know how painful it is to get a normal distribution running on it.. I just have some custom scripts compiling my own kernel for my jetson nano
16:45karolherbst: anyway, depending on what you are looking for specifically, nouveau or nvgpu might meet your needs better
16:45karolherbst: the main difference is probably CUDA and Vulkan support with l4t
16:45nightduck: I've found some people who provide how-tos for that, but there lies my biggest headscratcher. Nvidia's proprietary drivers don't work with the PREEMPT_RT kernel on desktop. But nvgpu on Jetson does. Why?
16:46karolherbst: ohh wait
16:46karolherbst: nvidias prop driver isn't GPL
16:46karolherbst: and the RT patches make the kernel GPL only or so
16:46nightduck: So it's not even a technical thing? It's a legal thing??
16:47karolherbst: some just patch out the EXPORT_GPL declarations and make it compatible
16:47karolherbst: as long as you never distribute the binary it's fine
16:47nightduck: We may have to because publishing pressure, but good to know O_o
16:48karolherbst: yeah.. you can always violate source code licenses as long as you never give the binaries away.. mostly :D
16:48karolherbst: anyway.. it's a legal issue
16:49nightduck: Ah, the freedom of OSS >'D
16:49nightduck: Anywho, how is does nouveau handle the rt kernel?
16:49karolherbst: it doesn't have to
16:49karolherbst: why don't have to fight against the kernel devs :p
16:50karolherbst: rt kernel incompatibilities are really just a problem for closed source kernel drivers
16:50karolherbst: mostly I think...
16:50karolherbst: of course there might be random bugs
16:51nightduck: The random bugs are what I'm concerned about. Random interrupts that get cranky if unhandled, etc
16:52karolherbst: yeah well. we won't give you any enterprise support if that's what you ask for :p so all the verification and whatever needs an enterprise would have is up to them, not up to us
16:53karolherbst: and even if anybody reports bugs, we don't have to fix those not because we don't want to, but because most of we do is spare time work and so on ;)
16:53imirkin: nightduck: patches welcome! :)
16:53karolherbst: so if you have enterprise needs we are the wrong people to talk to
16:53karolherbst: or the right ones if you have enough of money of hiring devs :p
16:54imirkin: i bet RH will take that sale
16:54nightduck: That's fair, I just came here to get a better idea of what questions to google
16:54karolherbst: not up to me to decide that :p
16:54karolherbst: nightduck: I see
16:54karolherbst: yeah, I mean we are happy to answer questions and discuss bugs and everything
16:54karolherbst: but we won't give any guarantees
16:56karolherbst: but in regards to RT: at least I am usually running kernels with full preemption enabled and that didn't give me strange bugs afaik
16:56karolherbst: can be different with patched kernels, but that's then not our issue (tm)
16:59RSpliet: nightduck: what do you need PREEMPT_RT for?
16:59nightduck: That's my research area
17:00RSpliet: real-time systems? so is mine ;-)
17:00nightduck: Hey!! Twinsies!
17:01RSpliet: Well, I moved away from Linux. Did a brief stint of research with LITMUS^RT, but that's all the Linux RT stuff I did
17:02RSpliet: Hence my question. Is it applied RT, or an engineering project for GPUs in RTS?
17:03nightduck: I'm in an autonomous vehicles lab at my university and the project is to put ROS2 on a Jetson board and assess its realtime quirks
17:04nightduck: We have another student developing a realtime GPU scheduler. But f*** if I know what that means
17:05karolherbst: sounds painful.. I mean realtime GPU work
17:05RSpliet: You'll learn as you get along ;-)
17:05karolherbst: yeah.. fun
17:05RSpliet: oh I meant that for nightduck
17:05karolherbst: I wouldn't even consider nvidai GPUs prior Turing to be RT compatible at all
17:06RSpliet: I have a small workshop paper in which I hint why I personally think sticking a GPU in a real-time system is a bad idea
17:06karolherbst: maybe I include Volta if I get convinced
17:06karolherbst: RSpliet: you could do a follow up with Turing :p
17:07RSpliet: karolherbst: not really. It's the "measure context switching times" work, for which I modified the FECS/GPCCS firmware. Can't do that beyond kepler
17:07RSpliet: nightduck: shameless plug of my own work: https://www.repository.cam.ac.uk/handle/1810/277888
17:07karolherbst: RSpliet: you wouldn't believe it, but turing has a yield instruction even :p
17:08RSpliet: Heh, that's kind of cool. Of limited use, but still...
17:08karolherbst: I think they added with with Volta
17:08karolherbst: it's the little things
17:08karolherbst: you could probably have an infitily long kernel running doing IPC and stuff
17:08nightduck: I'll take all the shameless plugs I can get. My life is nothing but reading papers at this point
17:08karolherbst: load new coda and weird shit
17:09karolherbst: and with replayable page faults you can probably even do async copies and everything
17:09RSpliet: nightduck: TL;DR: there's a dozen components competing for DRAM bandwidth inside a GPU, and no clue on how requests get prioritised. As a result you get funny stuff like worst-case context switch times depending on display resolutions.
17:10karolherbst: RSpliet: yeah, just that tegra doesn't need to deal with this shit :p
17:10karolherbst: it's all stolen RAM
17:10karolherbst: and no display component
17:10RSpliet: karolherbst: so it's also competing with all the other components that aren't GPU
17:10karolherbst: well.. except in the 2d part
17:10RSpliet: that's actually worse
17:10karolherbst: but that's a different thing
17:10karolherbst: yeah.. true
17:11karolherbst: but you could just do the memory operation and always yield in the kernel and move on :p
17:12RSpliet: nightduck: I went on to design an architecture (cycle-accurate timing model. Chips are too expensive and time consuming to produce) that tackles some of the problems of timing analysis of "GPU kernels". That's a TL;DR of my PhD :-D
17:13RSpliet: Preparing a paper outlining the main results as we speak
17:13RSpliet: But that's still a few kilometres off from a real chip.
17:22RSpliet: nightduck: I think if you want to learn more about RT GPU scheduling there's... ehh... James Anderson's (UNC) work "Globally Scheduled Real-Time Multiprocessor Systems with GPUs", Shinpei Kato's various GPU scheduling papers (he's a familiar face here :-)) and some paper on mixed-criticality RT stuff on Tegra whose authors I can't recall
17:25nightduck: I'mma bookmark those then. And I'm 70% sure my advisor co-published that last one :)
17:26RSpliet: Marko Bertogna?
17:27nightduck: Nope. Nvm lol
17:27RSpliet: Doesn't matter. Which lab you in?
17:28nightduck: The XZ-Group at WashU in St Louis
17:29RSpliet: Didn't Sanjoy Baruah go there?
17:29nightduck: Yeah, he's my algorithms professor
17:30RSpliet: Ah! He's also very very respected in the field of real-time systems :-)
17:31RSpliet: You're lucky to have him around!
17:31nightduck: Pretty cool dude, ngl
17:36RSpliet: nightduck: here's another one to look at https://www.slideshare.net/saiparan/protecting-realtime-gpu-kernels-in-integrated-cpugpu-soc-platforms-104996587
17:37RSpliet: Truth be told, I have reservations about that work. But there's defo interesting stuff to learn from that presentation/paper
21:00skeggsb: imirkin: hmm, unless i haven't woken up enough yet, i think i meant it as i wrote it?
21:00imirkin: skeggsb: it's not the same as the previous code
21:00imirkin: the change made it sound as though it should be
21:01skeggsb: ah right, i see. i think it's right, but should be a separate commit for that change
21:01imirkin: or just change the log to point out that you changed it
21:01imirkin: although i'm always confused by the nvkm_mask args ...
21:01imirkin: i guess head is 0..4, so that's why the 0x70 mask?
21:02skeggsb: because the field is at 6:4
21:02imirkin: and previously it all worked out of sheer luck?
21:02imirkin: since head is always == 0? :)
21:03skeggsb: it worked previously because we were always using DE 0, which is fine for HDMI audio, not so much for MST
21:03imirkin: so then ... shouldn't that change be part of https://github.com/skeggsb/nouveau/commit/4f483a5c6693a5bcf6abe18e380d6efcf56f76b9 ?
21:03imirkin: since otherwise you have a bisect point where it won't work?
21:04skeggsb: it's already broken *anyway* since the recent commits to the dispnv50/ side of things
21:05imirkin: on an unrelated note - any thoughts on adding TTM_FLAG_UNCACHED to disp->sync?
21:05skeggsb: but, good point :P
21:05skeggsb: mmm, why?
21:05imirkin: for arm
21:05imirkin: so that the bo gets the force_coherent flag
21:05imirkin: which i'm hoping means it gets an uncached mapping on the relevant platforms
21:12skeggsb: ah right, perhaps there indeed, though i'm not sure if we don't do that magically already somehow
21:12skeggsb: can't remember what alex did there
21:12imirkin: don't know that he did anything
21:13imirkin: it's display and tegra doesn't care
21:14karolherbst: skeggsb: btw, ping on https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/67 :)
21:14karolherbst: I really just copied over what we have in nouveau, I am just wondering if the removed bits are used _anywhere_
21:15karolherbst: I didn't find anything in mesa or xf86-video-nouveau
21:15karolherbst: or if it was used in the past or something
21:16karolherbst: although then I guess we can say "don't mix newest libdrm with ancient x"
21:16karolherbst: but wouldn't change anything at runtime anyway
21:18skeggsb: yeah, i think it's fine. some stuff has been unused for ages, so if it builds, i say ship it :P
21:18karolherbst: having your r-b or should I just merge it :p
21:18skeggsb: imirkin: i think he did stuff for PCI-E GPUs on those boards yeah?
21:18skeggsb: you can stick my R-b on it
21:18imirkin: skeggsb: hm ... not sure. and not sure that it was for display. but you could be right.