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