03:16fidtar: hey, new nouveau dev here (bit of a pun for ya). Is it worth attempting to tackle old bugs on bugzilla? I see some date back to 2013. Or are most those likely fixed but not removed.
03:18imirkin: i've found the best use of time is towards fixing issues that you yourself have
03:20fidtar: Sounds like a good place to start. Thanks.
03:23imirkin: so ... what issues are you having?
03:24imirkin: and what hardware do you have access to?
03:24imirkin: [i might be able to recommend a course of action]
05:12gnarface: if fidtar comes back, i can recommend some games to test...
12:09karolherbst: mwk: how much do you know about the PCI PM reg 0x88064? I saw you added that stuff to rnndb and this might actually causing our runpm issues
12:09karolherbst: if I poke 1 into it (to set the card into D1) like "nvapoke 0x88064 00000001" the card just dies
12:09karolherbst: and I think it shouldn't do this, right?
12:13karolherbst: uhm.. I had to check with setpci of course as with !D0 the mmio stuff is gone
12:13karolherbst: okay, so the card doesn't die
12:13karolherbst: but it wouldn't come back if I call the ACPI stuff afterwards
12:32karolherbst: mwk: anyway, this behaviour: https://gist.githubusercontent.com/karolherbst/ce5664a6f1b6c82529f3b500052c9c55/raw/add9a41deba38569890c62105119d8c09a65e6d9/gistfile1.txt
12:32karolherbst: I am actually wondering why we can't use the PCI bars after the GPU comes back online without removing the device and rescanning the bus
14:33kreyren: hey, i just installed nouveau on debian buster and i'm testing rocket league performance when the difference to proprietary is around +10 FPS and lightning, but i have spikes on both as https://i.imgur.com/QJKYk3i.png any idea what this could be caused by?
14:37imirkin_: kreyren: you can use the GALLIUM_HUD to peer into various internals if you're interested
14:39imirkin_: it's a bit difficult to configure
14:39imirkin_: your best bet is to run GALLIUM_HUD=help glxgears
14:39imirkin_: and look at what's printed in the console
14:39imirkin_: this should give you a general overview of the capabilities
14:39imirkin_: and then you should try to steal someone else's already pre-baked GALLIUM_HUD line and modify it to suit your needs
14:40imirkin_: (i suspect majority are around radeon's counters)
14:41kreyren: it doesn't print anything
14:41imirkin_: pastebin glxinfo output
14:43imirkin_: Device: Mesa DRI Intel(R) Haswell Mobile x86/MMX/SSE2 (0x416)
14:43imirkin_: you're not running on nvidia
14:44imirkin_: perhaps DRI_PRIME=1 GALLIUM_HUD=help glxgears ?
14:44imirkin_: (assuming you have everything else configured)
14:45kreyren: sorry system turned down for some reason
14:46imirkin_: did you see my last messages?
14:46imirkin_: or did it happen as a result of running that command?
14:46kreyren: yep works outputs lots of text
14:46imirkin_: ok cool
14:47imirkin_: enjoy the read :)
14:47imirkin_: btw, i'm guessing you were running rocketleague on the intel chip, not nvidia
14:47imirkin_: unless you had a DRI_PRIME=1 baked into your run command somewhere
14:47kreyren: not it was running on nvidia i had DRI_PRIME set up didn't realize that it's needed for said example
14:48imirkin_: gotcha, ok
14:48imirkin_: yeah, i965 isn't built on top of gallium
14:49imirkin_: so the GALLIUM_HUD setting has no effect on it
14:49imirkin_: also, even if it did, the exact variables exported vary by driver and hardware
14:49kreyren: does GALLIUM_HUD has any affect on performance? or does it output info only?
14:49imirkin_: well, it draws things on the screen, so small effect
14:49imirkin_: (HUD = heads-up display)
14:50kreyren: any idea what to look for said issue?
14:50kreyren: (lag spikes)
14:50imirkin_: that could be caused by data transfers, or heavy shaders
14:50imirkin_: btw - are you reclocking?
14:50imirkin_: or running with base clocks?
14:51kreyren: base clock, didn't change anything myself
14:51kreyren: unless debian ships it with reclock
14:52imirkin_: which GPU is it? fermi or kepler?
14:52kreyren: assuming maxwell?
14:52imirkin_: lspci -nn -d 10de:
14:52kreyren: 01:00.0 3D controller : NVIDIA Corporation GK104M [GeForce GTX 870M] [10de:1199] (rev a1)
14:52imirkin_: kepler. you can reclock it to get a LOT more speed
14:52imirkin_: that's a high-end part, so it'll make a difference. boot clocks are probably like 10% of overall speed
14:53kreyren: i have this in grub cmdline is it relevant? `nouveau.config=NvClkMode=15`
14:53imirkin_: oh yeah, ok. so you're already getting that benefit :)
14:53kreyren: ah didn't know that it's reclocking sorry
14:53kreyren: it's holding on 73C maybe it's overheating?
14:53imirkin_: (assuming you have a perf level 0xf, which most such GPUs do)
14:53kreyren: dunno what that is, more info?
14:54imirkin_: you can get a little more perf by enabling NvBoost=1 which will take temp into account
14:54imirkin_: i.e. low temp = can go faster
14:54kreyren: can i increase a fan speed somehow? seems to be running on low usually it screamed like a cow on windows
14:54imirkin_: (actually hm, i can't remember precisely how it works ... is it dynamic, or does it just chekc at time of reclock ... and karol's not around it seems)
14:55imirkin_: fan speed is controlled based on gpu temp
14:55imirkin_: nouveau probably just can't drive the gpu hard enough
14:55kreyren: nouveau.config=NvBoost=1 in kernel cmdline?
14:55imirkin_: while you have DRI_PRIME=1 glxgears running, can you cat /sys/kernel/debug/dri/1/pstate
14:56imirkin_: (and pastebin the results)
14:57imirkin_: ok, so you're running at 940mhz. that's pretty much max anyways
14:58kreyren: `301 frames in 5.0 seconds = 60.034 FPS` this seems wrong on DRI_PRIME=1 glxgears?
14:58imirkin_: i think you're maxing the clocks within reasons on nouveau
14:58kreyren: it goes to 8K FPS before
14:58kreyren: *it went
14:58imirkin_: you have a 60hz display
14:59imirkin_: read the info it prints -- it's vsync'd
14:59imirkin_: you can override that with ... something
14:59kreyren: noted i think i had override running mb
14:59imirkin_: vblank_mode=0 glxgears maybe?
14:59kreyren: yep sorry
14:59imirkin_: with prime, that's mostly a test of pcie bandwidth
14:59imirkin_: it takes zero time to generate the image
15:00imirkin_: but then it has to be sent over the pcie bus to the intel gpu
15:00kreyren: because dGPU doesn't have access to display right?
15:00kreyren: suggestions then?
15:00imirkin_: i mean ... not sure what you're looking for tbh
15:00kreyren: seems to me that it has trigger on 73C to lower performance
15:01imirkin_: if you're looking for something to change to make it not lag, i doubt you'll get an answer here
15:01imirkin_: if you're looking to understand why it lags, then GALLIUM_HUD might help
15:01kreyren: since the notebook is really silent usually it's very loud on GPU fan -> assuming overheating
15:01imirkin_: 73C isn't that much
15:01kreyren: seems to lock on this assuming that it stays on this temperature
15:01imirkin_: also on many laptops, fan is controlled by EC, not by the GPU itself
15:02imirkin_: (EC = embedded controller)
15:02kreyren: still seems really silent almost like it's running on idle
15:02kreyren: mby acpi issue? https://gist.github.com/Kreyren/d476876d29e1fec1db8226dc1b4789a2
15:02imirkin_: yeah, i get it. i'm just saying it's most likely nouveau has zero control over this
15:03imirkin_: also, how close to being on the lag line is windows?
15:03imirkin_: you should expect a 30% perf drop due to nouveau being ... not as optimized as the nvidia driver
15:04imirkin_: (can be as high as 50%, depends on the circumstances)
15:04kreyren: there ware zero lags on windows last time i tried but that was 2 years ago
15:05imirkin_: yeah ok. sorry, dunno what to say. reduce resolution :)
15:06kreyren: sorry it shut down again dunno why yet
15:06kreyren: you should expect a 30% perf drop due to nouveau being ... not as optimized as the nvidia driver
15:06imirkin_: could be due to overheat.
15:06kreyren: is understood
15:06kreyren: seems to be tried to parse acpi_osi
15:07imirkin_: if the fans aren't turning up, eventually there's a protection measure to shut things down
15:07kreyren: aldo doubt since CPU fan is spinning and CPU seems to be cool based on sensors
15:07imirkin_: it's a laptop, right?
15:07imirkin_: so these things are pretty integrated
15:07kreyren: yes ASUS G750JS
15:07imirkin_: there's no "cpu" fan and "gpu" fan
15:08imirkin_: there's a thing which controls airflow inside the whole thing and manages its temperature
15:08imirkin_: it's a coordinated effort
15:08kreyren: [ 0.323952] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
15:08kreyren: [ 1.681465] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
15:08kreyren: also relevant
15:08imirkin_: which is why there's normally an embedded controller which ... controls it
15:08imirkin_: you could try to boot with a windows-y OSI
15:09imirkin_: mmmm hold on
15:09kreyren: the fan is spinning tho
15:09kreyren: on GPU on load
15:09kreyren: acpi_osi=windows 2015 is beeing used now
15:09imirkin_: oh heh
15:09imirkin_: can i see your full kernel cmdline?
15:09imirkin_: cat /proc/cmdline
15:10kreyren: yep fan is spinning on load -> not ACPI issue
15:10kreyren: also acpi_osi line was added this reboot
15:11imirkin_: nouveau.NvBoost=1 -- that will do nothing
15:11imirkin_: if you want to enable it, do
15:11imirkin_: also acpi_osi shouldn't be in quotes ... i think you're supposed to do like
15:11imirkin_: acpi_osi= acpi_osi="Windows 2015"
15:14kreyren: http://ix.io/1Mdn sane?
15:14imirkin_: Boost, not Booxt
15:14imirkin_: and you want quotes around the value of acpi_osi
15:14imirkin_: and you have to fight the GRUB_CMDLINE_LINUX quotes too
15:14imirkin_: so probably like acpi_osi=\"Windows 2015\""
15:15imirkin_: and you should also throw in a "acpi_osi=" before that
15:15imirkin_: i.e. a blank value, followed by Windows 2015
15:15kreyren: GRUB_CMDLINE_LINUX_DEFAULT='quiet nouveau.config=NvClkMode=15,NvBoost=1 acpi_osi="Windows 2015"'
15:15imirkin_: not sure bash likes single quotes
15:15imirkin_:doesn't use grub2
15:15kreyren: it treats it as plain text this way afaik
15:15orbea: bash is fine with single quotes
15:16imirkin_: ok, so just add acpi_osi= first
15:16imirkin_: or maybe you have to do acpi_osi=! first? i really don't know this stuff =/
15:16imirkin_: i'd recommend you read about what this all does
15:18kreyren: sorry it died again
15:19kreyren: rebooting with requested cmdline
15:23kreyren: rebooting again line was parsed wrong
15:32kreyren: using the acpi_osi seems to fix the issue thanks imirkin_
15:32kreyren: it sounds like wind turbine again :D
15:32kreyren: and FPS are holding
15:33imirkin_: preparing for takeoff!
15:33imirkin_: make sure your seatbelt is fastened...
15:34kreyren: can i go further with reclocking? currently on 15
15:35kreyren: holding temp on 50 and dropping
15:35kreyren: 15 is max or?
15:35imirkin_: on your gpu, yes
15:35imirkin_: 15 refers to the perf level id
15:35imirkin_: (0f in that pstate printout)
15:35kreyren: so if i set 16 the voltage would be too dangerous for hardware?
15:36kreyren: or it will simple not boot or?
15:36imirkin_: it's a table
15:36imirkin_: there's no entry 16
15:36kreyren: ah i see
15:36kreyren: any other way to get more performance from it?
15:36imirkin_: (why are the entries non-sequential? i have no clue. it's whatever nvidia chooses to stick in there)
15:37imirkin_: you could go with NvBoost=2, but that's more dangerous and will get you very little more extra perf, i think
15:37kreyren: elaborate dangerous? i can handle hardware damage unless it damages GPU core
15:38imirkin_: unlikely to damage hardware
15:38imirkin_: at least not in short term
15:38imirkin_: likely to cause overheating
15:38imirkin_: and system shutdown
15:38imirkin_: if you do it a lot, the physical components will start breaking due to heat fatigue
15:38kreyren: > cpu_fan: 25500 RPM
15:39imirkin_: (basically if you heat and cool something a lot, it will break.)
15:39kreyren: does it calculate the RPm correctly? seems as too much
15:40imirkin_: hard to tell. laptop fans can be fast.
15:40imirkin_: there's a reason it sounds like a jet engine...
15:55imirkin_: is the fps consistent now?
15:55imirkin_: or still lagging?
16:00imirkin_: nice. i guess it was the overheating then, maybe slowing down cpu or something
16:00kreyren: just the acpi_osi worked
16:08kreyren: are there any known issues with nouveau + DXVK on the witcher 3?
16:10imirkin_: yeah - it totally won't work
16:10imirkin_: DXVK = vulkan
16:10imirkin_: nouveau = no vulkan
16:10kreyren: is there any way to get vulkan on nouveau?
16:10imirkin_: if it's working at all, it's probably using anv on your intel/hsw gpu
16:10imirkin_: which is only semi-supported by the intel team
16:11imirkin_: (anv is fully supported starting with broadwell, haswell is a half-generation behind)
16:12kreyren: it has Intel 4700HQ which is Haswell so worst case scenario vulkan on intel?
16:14kreyren: Why it doesn't work on nouveau?
16:15ajax: short answer, because no vulkan driver exists for nouveau
16:15ajax: longer answer would go into why it doesn't exist yet
16:17kreyren: any reference on issue or bug tracker?
16:17imirkin_: "driver does not exist" isn't really something that needs to be tracked...
16:17kreyren: so none tracking for development in nouveau ?
16:18imirkin_: it's not being worked on
16:18imirkin_: and it just doesn't exist
16:18kreyren: why none works on it?
16:19imirkin_: why don't you?
16:19kreyren: bcs i dont know what the issue is and i'm testing nouveau atm
16:20imirkin_: as always, lack of interest/time is the reason
16:20kreyren: how many active developers are there in nouveau?
16:20imirkin_: maybe like 2, depending on how you account for things
16:21kreyren: any reason for it to not be interesting for contribution?
16:21imirkin_: for the right person - it's very interesting
16:22imirkin_: meaning that no one with the proper intersection of interest and time has shown up to do it
16:22imirkin_: (and ability)
16:23imirkin_: the bo allocation uapi needs a complete redo
16:24imirkin_: as well as explicit fencing support improvements
16:24kreyren: what is the main repo of nouveau?
16:24imirkin_: which is a lot of work
16:24imirkin_: not to mention the actual vulkan driver, which is no small feat
16:25kreyren: sounds like fun unless Nvidia keeps sabotaging the development somehow
16:25imirkin_: well, the fact that the new gpu's are basically unusable for 3d accel certainly doesn't help things
16:25imirkin_: there's just very little interest
16:25imirkin_: RH funds 2 developers in nouveau-related tasks
16:26imirkin_: many of which are "support RH customers using nouveau", i suspect
16:26imirkin_: and there are a handful of volunteers who do things every so often
16:26ajax: derives more from certification requirements, tbh
16:27ajax: meaning we (red hat, my employer) don't certify systems in non-free-driver configurations
16:27kreyren: why not?
16:27ajax: moral obligation to free software
16:28kreyren: sounds like some IBM policy to me
16:28imirkin_: that's been the policy long before IBM had anything to do with RH
16:28ajax: you're welcome to think that if you want, but you're very wrong.
16:28kreyren: fair enough
16:28imirkin_: IBM's acquisition is recent (like ... months?)
16:29ajax: has not in fact happened yet
16:29imirkin_: they've been paying for nouveau development since ilke 2008 or 2009
16:29ajax: was _announced_ back in october
16:29imirkin_: oh ok. i haven't been tracking such details :)
16:29kreyren: is this the main repository of nouveau? https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/
16:29imirkin_: that is the nouveau ddx
16:29imirkin_: there's also a kernel component
16:29imirkin_: and a 3d driver component
16:29ajax: (ddx means "driver that the X server loads")
16:30kreyren: so everything in Software? https://nouveau.freedesktop.org/wiki/
16:30imirkin_: the GL backend driver is in mesa (https://cgit.freedesktop.org/mesa/mesa)
16:30ajax: (also, in addition to moral obligation, we can't support code we can't modify, and nvidia aren't giving us their driver code, so it's a support question too)
16:30imirkin_: the kernel is ... well any tree, really, there's not a ton of development on it that would be relevant to trying to understand how things work
16:31kreyren: well i would like to know how much lines it has o.o
16:31ajax: datura:~/git/mesa% cat src/gallium/drivers/nouveau/**/*.[ch] | wc -l
16:32ajax: that's the nouveau-specific part anyway
16:32kreyren: so it's wine-like project in terms of size?
16:33kreyren: assuming that wine is around 120K iirc
16:36imirkin_: of the 3d end of it
16:36imirkin_: there's plenty more in the kernel
16:36imirkin_: (and those stupid libdrm wrappers which are the bane of my existence are also not short)
16:37imirkin_: ajax: you also skipped all the cpp in codegen :)
16:37ajax: oh, hah, right
16:37ajax: i keep forgetting mesa contains c++
16:37kreyren: i see.. are all there required? i was thinking about writing rust fork
16:37ajax: datura:~/git/mesa% cat src/gallium/drivers/nouveau/**/*(.) | wc -l
16:37kreyren: dunno how complicated Nvidia chips are asuming that controllers shoudn't be hard to port
16:38imirkin_: nothing is required -- just have to interact with the kernel via a fixed uapi
16:38imirkin_: that 100k lines is the nouveau-specific backend, not the full GL library
16:38imirkin_: there's a substantial shared component
16:39kreyren: any other major issues like vulkan support?
16:39imirkin_: also note that the 100K line count includes all generations since GeForce FX 5xxx
16:39imirkin_: well, for vulkan, like i said, there's a substantial amount of kernel work that needs to be done
16:39imirkin_: in order to support a different uapi for buffer allocation
16:40imirkin_: for vulkan to work, you need to be able to place explicit resources at explicit VA's
16:40imirkin_: while the current API is more like "allocate me an object of size X"
16:40imirkin_: this will have implications for how the VMM is done as well
16:41imirkin_: since you'll need to be able to do post-facto PTE updates for setting diff memtypes depending on the type of resource vulkan decides to place in the allocated memory range
16:41kreyren: i see, there is lots of articles like https://www.reddit.com/r/linux_gaming/comments/7v008n/nouveau_hopes_for_basic_vulkan_driver_this_year/ but it seems that something prevented the work on vulkan?
16:41imirkin_: not really
16:41imirkin_: that was never going to be a thing in the first place
16:42imirkin_: just someone who's over-optimistic about things happening.
16:42imirkin_: (i'm looking at you, mupuf)
16:42kreyren: my main concern is beeing harassed by nvidia tbh i can imagine them doing some changes to make development of nouveau pure hell
16:42imirkin_: i've never been harassed by nvidia
16:42imirkin_: although that is no guarantee of lack of future harassment :)
16:43imirkin_: in fact, the harassment has mostly gone the other way, i suspect
16:44kreyren: it's fine the other way around :D
16:44imirkin_: (some helpful people have on occasion offered some assistance...)
16:44imirkin_: nvidia contributed a bunch of the tegra support, for example
16:45kreyren: everything is written in C or?
16:45kreyren: meaning everything in nouveau
16:46imirkin_: the shader compiler is in (non-crazy) C++
16:46imirkin_: everything else is C
16:47kreyren: is there some rolling release of nouveau or is it purely just stable release?
16:47kreyren: or like some development versions?
16:47imirkin_: release of what exactly?
16:47imirkin_: nouveau is not a thing that is released
16:47imirkin_: nouveau is an idea :)
16:47imirkin_: there are bits in the kernel, libdrm, xf86-video-nouveau, and mesa
16:48imirkin_: each one of those is released in their own way
16:48kreyren: hm i see o.O
16:48imirkin_: (ok, admittedly xf86-video-nouveau is *all* nouveau, but it's a rarely-changing super-stable part of it)
16:55kreyren: so if it's an idea do you have some kind of abstract or concept about it's interpretation to help me understand what needs to be done software-wise?
16:56imirkin_: "make it work" :)
16:56imirkin_: needs to be done for what? a vulkan driver?
16:57kreyren: like generally assuming having GPU hardware like for GPU to recieve power we need function A which does 1 2 3 etc..
16:57kreyren: terrible example but still
16:57imirkin_: you may be interested in https://envytools.readthedocs.io/en/latest/
16:57imirkin_: which talks about some things
16:58imirkin_: diff people learn in diff ways ... i personally learn by doing
16:58imirkin_: so ... dive into the code and ask questions
16:58imirkin_: if your goal is a vk driver, then step 1 is modify the kernel uapi to support what vk needs
17:02kreyren: well my ideall end-goal is redox with open-source software written in rust assuming rust having more effective runtime then C++, but i'm interested in nouveau depending on how much performance i can get so far it's more effective then nvidia's option for my 870m
17:06imirkin_: i doubt you'll have much traction in getting the kernel rewritten in rust, so for the first step of the vk component, you're going to have to stick to C
17:12imirkin_: and i strongly doubt you'd get any perf improvement from changing the driver's language -- there's not a lot of overhead already
17:12imirkin_: the main gains are from driving the GPU in a smarter way
17:12imirkin_: or having a better compiler which produces better shader code
17:29kreyren: imirkin_, sorry had to go afk, yep i know