16:37 SpaceInvaders: I thought I'd take a look at using nouveau, again, instead of the nVidia proprietary drivers. I have video working successfully. I am having trouble getting hw accel to work (vdpau). Is there any expectation it should work? I am happy to share details but before I go thru that effort thought I'd check in case someone says "doesn't work"
16:38 karolherbst: SpaceInvaders: depends on the GPU
16:38 imirkin: SpaceInvaders: https://nouveau.freedesktop.org/wiki/VideoAcceleration/
16:38 SpaceInvaders: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)
16:38 imirkin: should cover it
16:38 imirkin: yeah that won't work
16:38 SpaceInvaders: ahh thank you :)
16:38 imirkin: at least not without writing a bunch of code first
16:38 SpaceInvaders: yes I've been thru the wiki on VA from top to bottom
16:39 imirkin: note how VP6+ is "TODO"
16:39 imirkin: it needs ... todoing :)
16:39 SpaceInvaders: well nouveau works great for everything else. :)
16:40 SpaceInvaders: I'll install the proprietary drivers and resolve all those pesky todo issues :D
16:40 SpaceInvaders: thank you very much!
16:40 imirkin: that'll fix it right up
16:41 imirkin: and consider AMD for your next GPU purchase
16:43 HdkR: ^ I agree with this
16:44 SpaceInvaders: I looked really hard at AMD. The only reason I made this purchase (for my HTPC) was price. It was on-sale.
16:45 SpaceInvaders: and thanks again!
16:48 karolherbst: HdkR: :D
16:51 HdkR: karolherbst: Really if you want a good open source and/or Linux experience
16:51 karolherbst: HdkR: I know :p
16:51 HdkR: Big green can't compete
16:57 HdkR: karolherbst: I did see that some Volta firmwares got dropped at least? :P
16:57 HdkR: Because sooo many people are buying $3000 GPUs to run Nouveau right now
16:57 karolherbst: HdkR: yeah, it was very important to add
16:59 HdkR: Now time to wait for Turing because those should...hopefully be reasonably priced once the rest of the generation trickles in
16:59 karolherbst: :D of course
17:01 karolherbst: HdkR: I was actually thinking about pming you just for fun an "to only say hello" but... I guess I spare me those kind of "jokes" for now :p
17:01 HdkR: bwah?
17:01 karolherbst: :D
17:05 HdkR: Someone made a comment recently about the nanosleep instruction. I guess they were just perusing the cuda docs
17:09 annadane: i'm not sure why nvidia isn't more open. i know sometimes there's the consideration that some companies *can't* open up their products because of copyright concerns or whatever it is. and i know nvidia has been in touch with the free software community
17:09 HdkR: True, I touched a lot of people's hands at XDC
17:10 HdkR: </s>
17:11 annadane: i'm sure people will buy nvidia cards "for the gaming" or bitcoin or whatever on windows because they don't have a reason to care on windows but i'm like 99% sure my next purchase will be AMD
17:11 annadane: so they're actively losing my sale due to this
17:12 Sarayan: If you want to do neural network training you don't have much choice at that point
17:19 karolherbst: HdkR: that was me probably
17:20 HdkR: :D
17:22 HdkR: <Lioncache> never thought I'd see "nanosleep" be the name of an instruction, yet here we are
17:22 HdkR: You plus someone else
17:22 HdkR:throws Lioncache under the bus quick
17:23 karolherbst: :D
17:23 karolherbst: and I thought my "use case" for nanosleep would be aweful enough
17:24 HdkR: Sort of makes sense when you have real cooperative threads. You can start scheduling them like an RTOS
17:24 karolherbst: sure :D
17:24 karolherbst: but why would you
17:25 HdkR: I can think of something that puts a whole warp asleep and then something else gets scheduled in that it is dependent on
17:25 HdkR: But maybe I'm thinking of ideal use cases
17:26 karolherbst: I mean, I don't even get why you would to add a nanosleep instruction
17:26 karolherbst: when does it actually make sense
17:26 HdkR: For those times when YIELD isn't good enough? :D
17:27 HdkR: Reverse engineering latencies by explicitly waiting nanoseconds of time?
17:27 karolherbst: yeah... that's the use case for nanosleep
17:27 karolherbst: no other reason nvidia added that :p
17:28 HdkR: I can only think of a real "user" use case being some sort of user backoff inside of a shader
17:28 Sarayan: spinlock?
17:28 HdkR: So it backs off more and more while chewing through a work queue or waiting for some async work
17:28 HdkR: spinlock can thrash cache
17:29 HdkR: It is spinning an atomic which will just smash the shared cache :P
17:33 karolherbst: maybe having some RTOS is indeed the workload, but you still have the threads fighting for the cache :/
17:33 karolherbst: or
17:33 karolherbst: you only allow one task at the time
17:34 karolherbst: and if tasks are trivial enough you won't increase gprs usage
17:34 karolherbst: just that nanosleep shouldn't sleep longer than the delay you have for launching a new kernel
18:26 joepublic: Just want to mention that AMD's awesome free software driver--Thank you AMD--depends on nonfree binary firmware.
18:28 imirkin: not really
18:28 imirkin: the hardware depends on having a few bits loaded into it that aren't shipped on a ROM
18:29 imirkin: this is fairly common practice.
18:29 imirkin: the software driver, i.e. the thing that runs on the CPU, is 100% free.
18:30 joepublic: Not saying it isn't common, not saying it's evil, not saying it's (your personal interpretation). But if someone plans to run debian main, or trisquel, or something like that, a recommendation that "AMD drivers are free software" is not doing them a favor.
18:30 imirkin: afaik trisquel is the only thing which removes random kernel functions and decides that it shall be referred to as "libre"
18:30 imirkin: should work fine with debian and any sane distro
18:30 joepublic: Thus, I mention that in addition to "the software driver, i.e., the thing you are talking about" you also need some firmware which those do not include. --And no, it's not in debian main.
18:31 imirkin: that's incredibly surprising
18:31 imirkin: i'm going to have to confirm that... my understanding was that only kernels with the request_firmware() function removed had issues.
18:31 imirkin: thanks for pointing that out
18:32 joepublic: just trying to avoid issues for those who don't get the whole picture.
18:33 joepublic: This difference is also a reason why nouveau is so impressive in comparison.
18:34 imirkin: nouveau wouldn't work with that setup on any nvidia gpu still sold in stores
18:35 joepublic: radeon/amdgpu without firmware won't work on any GPU sold ever.
18:35 imirkin: i thought the firmware thing was only for GCN+ gpu's. i don't really keep track though.
18:36 imirkin: since it's a non-issue.
18:36 imirkin: joepublic: do you know the precise reason why it wouldn't work in debian main?
18:37 imirkin: pretty sure they just use a regular kernel with reasonable patches... so it'd have to be missing firmware?
18:37 joepublic: Here's the list of cards whose firmware are supplied by package firmware-amd-graphics which is in nonfree. Yes, it just needs the firmware, the driver is free software.
18:37 joepublic: https://pastebin.com/4tbWvgL5
18:38 imirkin: gotcha. and one has to do "something" to get that package? (sorry, not familiar with debian myself)
18:38 joepublic: you have to add the "non-free" repositories, otherwise non-free packages are not available.
18:39 imirkin: k. thanks for the info
18:41 joepublic: Thanks for the work you guys do. Without you it would be just intel integrated graphics in the free/libre world.
18:42 karolherbst: uhm...
18:42 karolherbst: joepublic: intel also requires non free firmware now
18:42 karolherbst: so does nouveau on newer gpus
18:42 joepublic: So does Nvidia.
18:42 imirkin: the more modern intel gpu's are probably better
18:43 imirkin: even if you're annoyed by user-loadable firmware, haswell or broadwell will stack up fairly nicely against nouveau without reclocking
18:43 imirkin: (and be *way* more stable. and have a vulkan driver)
18:45 joepublic: I suppose I would have to get rid of my X79 motherboard that supports my 10 core Xeon if I tried that, which would potentially cost actual money. Instead, I ordered a couple used Nvidia GPUs to see what they do.
19:21 karolherbst: imirkin: do you think we should pull in this commit? https://github.com/devkitPro/mesa/commit/260f63428229e8d2b7fd1818ad684260d8101ba3
19:21 karolherbst: I don't really know what the implications here are
19:22 imirkin: probably
19:22 imirkin: we probably missed it in nvf0 bringup, nothing ever cared.
19:22 imirkin: should double-check that nouveau has those class id's
19:22 imirkin: for all the nvf0+ p2mf's
19:22 imirkin: er, gr's
19:23 imirkin: (since otherwise even if it would work, it won't)
19:23 karolherbst: I see
19:23 imirkin: and double-check with skeggsb. but i really don't think any harm (or gain) would come from it
19:24 karolherbst: I've got told that in that case we would use and unbound channel, but again, I have no idea what that would mean
19:24 imirkin: hm?
19:24 karolherbst: "We confirmed that without that fix nouveau will use the COPY channel without an engine bound to it, which is bad"
19:24 imirkin: it's actually not bad.
19:24 imirkin: er, it might be
19:24 karolherbst: depends on what kind of bad ;)
19:25 imirkin: so ...
19:25 imirkin: there's the copy "engine" which is inside fifo
19:25 imirkin: which is synchronous
19:25 imirkin: and then there are async copy engines (aka ce0/ce1)
19:25 imirkin: which are separate engines
19:26 imirkin: if we don't bind the proper class properly, then we could end up using the fifo one when we mean to use the async ones
19:26 karolherbst: ohhhh
19:26 imirkin: otoh, i don't think those copy engines support p2mf
19:26 karolherbst: so worst case, we just run slower
19:26 imirkin: so it could just be nvidia kernel driver being bitchy
19:27 imirkin: skeggsb knows all this stuff for real
19:27 karolherbst: k
19:27 imirkin: i don't have an ideal mental model of how all this stuff works
19:27 imirkin: it was simpler pre-kepler
19:27 karolherbst: with volta we have even 6 async ones afaik
19:27 imirkin: you bind a class to a channel, and voila - you can use it.
19:28 karolherbst: or maybe even more :/
19:28 imirkin: now there's all this engine bs
19:28 imirkin: er, subchannel
19:28 karolherbst: I guess it makes things faster if you use it correctly :p
19:28 imirkin: doubtful
19:28 imirkin: probably makes hw simpler though
19:28 karolherbst: sure, but then you also get more perf
19:30 imirkin: also b0b5 is maxwell+
19:30 karolherbst: ohh, true
19:31 imirkin: pascal has two of them
19:32 imirkin: looks like the old classes aren't even supported
20:10 skeggsb: imirkin, karolherbst: you have to use a whole separate channel if you want async ce
20:11 skeggsb: afaik, host will magically synchronise gr/ce on the channel that supports gr
20:13 skeggsb: most (but not all) runlists have a copy engine (or two...) assigned to them
20:13 imirkin: skeggsb: did you see my questions about mcp89 and compression?
20:13 skeggsb: i'm not actually sure of the details of how/why there are multiple on some runlists..
20:13 skeggsb: i've been away for a couple weeks, so, no :P
20:13 imirkin: ok
20:13 imirkin: so here's the situation
20:14 imirkin: we try to enable compression
20:14 imirkin: with nouveau_bo_new
20:14 imirkin: mcp89 has vmm's which have the compression bit set
20:14 imirkin: however it's all stolen memory
20:14 imirkin: so ... some function whose name escapes me says "ha, no way"
20:14 imirkin: and so nouveau_bo_new gets a EINVAL
20:14 skeggsb: so it hits the aper check
20:14 imirkin: yes
20:14 imirkin: so ...
20:15 imirkin: either it should be flipped to mcp79_mmu
20:15 skeggsb: ok.. now, does it *actually* work correctly if you bypass that check
20:15 imirkin: which is identical to g84_mmu but doesn't have the compressed VMM entry
20:15 imirkin: oh, that i have no clue ;)
20:15 imirkin: but ... i think we have someone who can try patches
20:15 imirkin: hold on
20:15 skeggsb: that was the question we got to last time, and i couldn't remember for sure whether the hw supported it or not
20:15 imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=108500
20:15 skeggsb: i *think* it does
20:16 imirkin: the guy was competent enough to track down that nouveau_bo_new was failing, i'm sure he could build a custom kernel
20:16 imirkin: should we just dump that aper check and see what happens? or is there something more?
20:17 skeggsb: i think that'll do for a quick test perhaps
20:19 imirkin: map->type |= ram->stolen
20:19 imirkin: still want that?
20:19 skeggsb: yes, absolutely need taht
20:19 skeggsb: that*
20:20 imirkin: k
20:20 imirkin: i didn't trace what that did :)
22:32 Kevlar_Noir: helllo !
22:32 Kevlar_Noir: I want to overclock my monitor
22:32 Kevlar_Noir: is there a guide ? can this be doeable with nouveau ?
22:35 karolherbst: no. yes.
22:35 Kevlar_Noir: cool !
22:35 karolherbst: well doable as in: somebody has to write code
22:36 Kevlar_Noir: ah it's another thing
22:36 karolherbst: I mean, you want to do that with your GPU, not your actual monitor, right?
22:36 Kevlar_Noir: no my monitor
22:36 karolherbst: hum
22:37 Kevlar_Noir: 20-nouveau.conf ?
22:37 karolherbst: so you mean like bumping the 60Hz rate to 75Hz
22:37 Kevlar_Noir: no 72hz
22:37 Kevlar_Noir: to be precise
22:37 karolherbst: does your hw support that?
22:37 Kevlar_Noir: yes
22:37 karolherbst: at the highest resolution?
22:37 Kevlar_Noir: yes but I have to activate freesync
22:37 karolherbst: we normally just do whatever the display tells us
22:37 karolherbst: ohhhh
22:38 karolherbst: so with freesync you get 72 Hz, but without it, only 60?
22:38 Kevlar_Noir: yes
22:38 karolherbst: mhhhhhh
22:38 karolherbst: we don't support freesync
22:38 karolherbst: I think AMD cooked up some patches though
22:38 karolherbst: but
22:38 karolherbst: I guess it's not the right time for it yet
22:38 karolherbst: also, it would require us to have capable hw for that to try out
22:39 Kevlar_Noir: ah ok..
22:39 karolherbst: dunno if freesync even works on nvidia hw, but maybe it does. I don't know the details
22:40 Kevlar_Noir: it works
22:40 karolherbst: okay
22:40 Kevlar_Noir: but there's options not accessible now
22:41 Kevlar_Noir: on the monitor I meant
22:42 Kevlar_Noir: and there's two mode
22:43 Kevlar_Noir: but xrandr -q gives me now 72
22:43 karolherbst: I see
22:43 karolherbst: so I guess it will just stick with 72 then
22:43 Kevlar_Noir: I try the second mode
22:44 Kevlar_Noir: ultimate engine rofl
22:46 Kevlar_Noir: yes that's it just 72hz
22:50 imirkin: Kevlar_Noir: just provide a modeline, and enjoy the good times
22:50 Kevlar_Noir: modeline ?
22:51 imirkin: modeline.
22:52 Kevlar_Noir: ok !
22:52 Kevlar_Noir: with nouveau ?
22:52 imirkin: with any driver
22:52 karolherbst: Kevlar_Noir: I thought you got it working with 72 Hz now?
22:53 Kevlar_Noir: yes
22:53 karolherbst: well, then you achieved your goal, no?
22:53 Kevlar_Noir: lol yes !
22:53 Kevlar_Noir: no, in fact we cannot modify hdmi black level in this mode
22:53 Kevlar_Noir: and other things
22:54 Kevlar_Noir: but but in fact.. it's details
23:55 joepublic: Is the idea behind Gsync/Freesync not to run at a variable refresh rate?
23:56 imirkin: that's my understanding, at least
23:58 imirkin: which enables you to delay the next frame by a small amount rather than missing the vsync entirely
23:58 joepublic: so only slightly variable. Makes sense.
23:58 imirkin: so if you have a 60hz "regular" sync frequency, and frames generated at, say, 59hz, you don't have to play silly games
23:59 imirkin: each monitor will advertise a "legal range"
23:59 imirkin: can't go too low though
23:59 joepublic: in edid?
23:59 imirkin: not sure if it's all done in terms of "slow down", or if it's also done for "speed up"
23:59 imirkin: presumably, yes
23:59 imirkin: i don't know the full details