01:57gnurou: karolherbst: sadly no - ACR capabilities are limited to PMU on Maxwell and SEC2 on Pascal, and even if hardware supported it the signed firmware has the falcon's registers hardcoded anyway
02:33shuffle2: is there any sort of documentation available for gm20b? something describing cmd ringbuffer operation would be cool...
02:35shuffle2: would it be identical to others in "NV110 family", as this labels it? https://nouveau.freedesktop.org/wiki/CodeNames/ not that it really helps :p
03:03mangix: hrm no idea how to overclock this. echo 0f > pstate results in not implemented
03:03mangix: sorry, reclock
03:17mangix: hmm temp seems to be an integer value
03:19mangix: looks like my laptop's fan reacts to temp by itself
03:19mangix: no need for Fn+1
03:29mwk: shuffle2: http://envytools.readthedocs.io/en/latest/hw/fifo/index.html
03:29mwk: ringbuffer hasn't changed much since Fermi
03:38shuffle2: it sounds similar to host1x channels, is it actually the same thing?
03:39shuffle2: and yea i was curious about IB specifically, so does some uc process the stream, or does hardware direct the stream?
03:47shuffle2: http://envytools.readthedocs.io/en/latest/hw/memory/gf100-vm.html :'( :D
04:16mwk: shuffle2: I don't know much about host1x, but IIRC it's not the same thing
04:16mwk: though similiar in spirit
04:16mwk: and as for IB, it's one of the few parts of hardware where there's no uc involved
04:16mwk: everything in hw
08:12karolherbst: gnurou: yeah I feared as much regarding the hardcoded stuff already
08:43parchd: is there a way to search the IRC logs?
08:45karolherbst: parchd: download them
08:45karolherbst: or I think google might help
08:45pmoreau: parchd: The logs are indexed by Google, so a simple search should work; add "site:https://people.freedesktop.org/~cbrill/dri-log/index.php" to the search query to restrict the results to that website.
08:47pmoreau: For example, https://encrypted.google.com/search?hl=en&q=parchd+site:https://people.freedesktop.org/~cbrill/dri-log/index.php ;-)
08:53parchd: thank you both
09:40karolherbst: pmoreau: I need a fitting name for the option to enable maxwell2 reclocking, and something like "maxwell2Reclocking" doesn't cut it
09:41karolherbst: I want something like "IAmAwareIMayBrickMyGPU"
09:49karolherbst: maybe even print an warning in dmesg "Thermal control not supported. Watch GPU temperature at any time"
10:08karolherbst: gnurou: anyhow, I figured out how I can reset the PMU in a quite easy way, so it's all fine. There are just other issues we may encounter later if we indeed need to switch between ours and nvidias implementation (if this comes at all)
10:08karolherbst: I think the best way to deal with this is just to assume it won't ever come, then we can't be disappointed anymore
10:29parchd: karolherbst_: I've got no idea what you are talking about, but it sounds depressing
10:36karolherbst_: parchd: it actually is
10:37karolherbst_: parchd: we would like to enable maxwell2 reclocking for everybody, but we can't control the fans, because we need signed firmware from nvidia to do so
10:45parchd: and I am going to guess they aren't especially forthcoming with providing it? (sigh)
10:47parchd: not that I'm personally that bothered... Maxwell is way beyond my card
10:48RSpliet: whoa... http://forums.guru3d.com/showthread.php?p=5447993#post5447993
11:13karolherbst_: RSpliet: why that "whoa"?
11:17karolherbst_: parchd: well we are, because they kind of promised to do so
11:18parchd: karolherbst_: well that is definitely pretty sucky of them
11:18karolherbst_: yes it is
11:31pmoreau: karolherbst_: Small variation of yours: IAmAwareIMayBrickMyMaxwellv2AnyTimeButLetMeReclockAtLast
11:53RSpliet: karolherbst: NVIDIA apparently added DX12 support for Fermi in their latest drivers
12:07karolherbst: RSpliet: yeah well
13:15mangix: any reason why writing to pstate results in ENOSYS?
13:19karolherbst: mangix: chipset_
13:19karolherbst: and kernel version
13:22mangix: gm204 4.11
13:23karolherbst: mangix: you can use my patches
13:23mangix: i am
13:23mangix: cat pstate works
13:24mangix: echo does not
13:24karolherbst: mangix: sure?
13:27karolherbst: well if you use my patches you also need to set nouveau.config=NvFanless=1
13:27karolherbst: but I am very unhappy about that "NvFanless" name, should be something more warning
13:29mangix: what does that do?
13:30karolherbst: enable reclocking for maxwell2
13:30karolherbst: but you should only do that if the fan isn't controlled by the gpu
13:31mooch2: hey mwk
13:33pmoreau: karolherbst: What about IHerebyCertifyMyFanIsntManagedByTheGPUAndTakeAllResponsabilitiesInPotentiallyDestroyingMyMaxwellv2 ?
13:33karolherbst: pmoreau: well we still have that 80 char limit
13:34karolherbst: we have around 55 chars to spend
13:34pmoreau: It's only 98 chars
13:34karolherbst: -8*3 intendation
13:35pmoreau: IDontCareIfIDestroyMyGPU ?
13:35karolherbst: sounds good
13:35karolherbst: we could make two flags
13:35karolherbst: 1. for enabling experimental features
13:35karolherbst: 2. for enabling specific experimental features
13:35karolherbst: and you need always 1. enabled
13:35pmoreau: Yep, why not
13:36karolherbst: but it's already doubtfull if you should include code in your driver which can harm the hardware
13:37karolherbst: what we really need is that thermal throttling
13:37karolherbst: I guess I should indeed focus on that now
13:37mooch2: mwk: so, i have EDID reading implemented, but the driver still isn't doing shit
13:37karolherbst: pmoreau: and maybe it's fine to have those patches not included until we have thermal throttling and everybody who indeed wants to enable maxwell2 reclocking needs to compile the kernel/module
13:39karolherbst: I think the first step for thermal throttling is to be able to read out the max temperature where we need to set the lowest clocks possible
13:39pmoreau: compile the kernel/module to apply a patch enabling for GM20x, I guess?
13:39karolherbst: + needing to specify a config
13:39karolherbst: otherwise silly persons includes those patches in deistributions or so
13:40pmoreau: Mmh, yeah, that would be bad
13:40karolherbst: I am already happy that I found a way without needing to reload nouveau finally
13:40karolherbst: no idea why I didn't do it this way in the first place... it looks so trivial
13:43karolherbst: but this way we can also run other PMU code after secboot
13:44karolherbst: so 2/3 patches could be merged without any harm
16:29mangix: can't figure out if there even is a fan connected to a GPU?
16:30imirkin_: no way to tell for sure, at least that we know of
16:30imirkin_: sometimes the fan has a tach, so we can tell definitively that there is one connected
16:31mangix: for me, the fan speed can't be set with NVAPI or NVML since there's no
16:31mangix: fan connected
16:32mangix: my thinking is, if (gpu has no fan hooked up) enable reclocking, else disable.
16:32imirkin_: we have no way of knowing though
16:33imirkin_: [at least that we know of]
16:35mangix: if the tach can be read, might be good enough i'd guess
16:35imirkin_: heh, but that's only on a small fraction of GPUs
16:36mangix: hmmm. i'm guessing non reference designs
16:37karolherbst: mangix: on maxwell2 we can't set the fan speed at all
16:37imirkin_: no, just on high-end GPUs
16:38imirkin_: having a tach is more expensive than not having a tach :)
16:42karolherbst: mangix: if there would be an easy solution we would already added maxwell2 support
16:42karolherbst: but there ain't one
16:42karolherbst: and even enabling it on fanless ones has a high risk, because we don't know yet if the GPUs shuts itself down on high temperatures, because we can't try it out
16:43karolherbst: It doesn't even feel right to enable it through an option
18:30imirkin_: orbea: so ... what was the issue with ubershaders in dolphin?
18:30imirkin_: it's supposed to be slower, no?
18:30karolherbst: imirkin_: apperantly bad performance, but this is to be expected afaik even under nvidia
18:30orbea: the exclusive ubershaders are really slow
18:30orbea: the hybrid ubershaders are actually fast though
18:30karolherbst: orbea: did you messuare the perf impact on nvidia?
18:30imirkin_: also note that nvidia recompiles dynamically
18:31imirkin_: i.e. if you have some uniforms, it'll recompile a shader with those uniform values
18:31orbea: i haven't used the blob in a long time so no
18:31karolherbst: yeah and that
18:31karolherbst: orbea: ubershaders are considered slow
18:31karolherbst: that's just the way it is
18:31imirkin_: which nouveau could do, but does not
18:31karolherbst: imirkin_: would it be much work to actually implement it though?
18:31imirkin_: the biggest question would be when to do it
18:32karolherbst: mhh, always and in an async way?
18:32orbea: in mario kart wii with the old shaders it stutters at the start of every race while shaders compile, the hybrid ubershaders get rid of that completely with nouveau here :)
18:32karolherbst: orbea: yeah
18:32orbea: anyways, I just tried them out of curiousity
18:33karolherbst: and hybrid is what most should use
18:33karolherbst: but bad pers is expected with those
18:33karolherbst: we could do better with optimized compiles
18:33karolherbst: I think radeonsi does it in an async way?
18:33karolherbst: aka replacing with optimized variants
18:37imirkin_: skeggsb_: btw, in that bug ccaione supplied a mmiotrace of GP108. any objections to adding support for it without GR?
18:40karolherbst: orbea: would you mind copying the compiled shaders? NV50_PROG_DEBUG=1 can do thisif you run a debug build
18:40karolherbst: orbea: maybe there are some opportunities for better optimizations
18:41karolherbst: imirkin_: I think it would be a good idea to actually have the code in place for dynamical recompiles and then figure out later when to actually enable those
18:41imirkin_: send patches =]
18:41imirkin_: right now we don't handle it super-well
18:41karolherbst: I imagine
18:42imirkin_: there are 2 ways for it to currently happen -
18:42imirkin_: one is vertex shaders + increasing number of UCP's
18:42imirkin_: that triggers a full recompile
18:42imirkin_: the other is with binary patches, which triggers a fresh code upload but not an actual compile
18:42imirkin_: we assume that there's The One True version of the shader code right now
18:42imirkin_: we'd need to create some sort of variant thing
18:43karolherbst: is it controlled by gallium to do those dynamic recompiles? never really looked on how it is handled in radeonsi
18:44karolherbst: I guess applications using GL_ARB_separate_shader_objects might get a decent perf gain from this?
18:44karolherbst: which boils down to optimizations at linking time?
18:44orbea: karolherbst: i'll build a debug mesa and try that
18:45karolherbst: orbea: it's just to look over those, but then do a full ubershader run and no hybrid
18:45karolherbst: otherwise you get tons of tiny shaders
18:45imirkin_: which dynamic recompiles?
18:45karolherbst: imirkin_: does it really?
18:45karolherbst: I don't know if it really does
19:13orbea: karolherbst: is this what you want? http://ks392457.kimsufi.com/orbea/stuff/games/dolphin-emu/ubershader.log.xz
19:13orbea: that is with exclusive
19:13karolherbst: could you do it again with NV50_PROG_DEBUG_NO_COLOR=1 ?
19:14orbea: sure, hold on
19:24debo: hi guys
19:25debo: i have trouble with x since i upgraded to debian stretch and removed the nvidia driver
19:25debo: i have to startx manually
19:25debo: i have no taskbar and no context menu on desktop
19:26debo: i get the following error in the Xorg.0.log
19:26debo: (EE) Failed to load module "nv" (module does not exist, 0)
19:27karolherbst: debo: you need to remove any x config as well after removing nvidia afik
19:27orbea: karolherbst: http://ks392457.kimsufi.com/orbea/stuff/games/dolphin-emu/ubershader_nocolor.log.xz
19:28karolherbst: orbea: awesome"
19:29debo: remove /etc/X11/xorg.conf? it is renamed .old
19:29towo`: without a xorg.conf (EE) Failed to load module "nv" (module does not exist, 0) is absolute normal, because nv is autoprobed
19:30towo`: and if startc works, you have another problem, not x or the driver
19:30towo`: maybe no $dm installed
19:31debo: it is the only EE in xorg.log
19:31debo: i have kdm and sddm installed
19:31karolherbst: well kdm/sddm don't get starty by startx
19:31towo`: there is no kdnm in stretch, kdm is dead
19:31debo: there are a few errors in dmesg too
19:31karolherbst: maybe you should just upload your logs somewhere
19:31karolherbst: before guessing what might be relevant
19:34karolherbst: yeah, everything looks fine
19:34debo: xorg log and dmesg
19:34imirkin_: debo: plasmashell on a G72?
19:35debo: it was working before the upgrade
19:35imirkin_: the 3d driver isn't going to be up for that
19:35imirkin_: the nvidia blob one might be
19:35imirkin_: but definitely not the nouveau one
19:35imirkin_: convince plasmashell to not use GL for its acceleration/whatever and it'll be fine
19:35debo: sorry, i had the proprietary driver before upgrade too
19:36karolherbst: orbea: yeah, nouveau generates some really terrible code here
19:38debo: the compositor is not enabled at startup
19:38imirkin_: karolherbst: unfortunately they do a lot of switch's and the glsl ir is super-mangled for switch =/
19:38karolherbst: that's what I was refering to by "terrible code"
19:38imirkin_: karolherbst: i suspect one could fix that by dealing with switch's without conditional breaks separately
19:38imirkin_: (or at least improve it)
19:39karolherbst: I would look over it if I would have shader_test files :p
19:39karolherbst: orbea: mind running it with "MESA_SHADER_CAPTURE_PATH" set and give me all the generated shaders?
20:08orbea: karolherbst: sure, hold on
20:17orbea: karolherbst: here is a tarball with the generated shader files http://ks392457.kimsufi.com/orbea/stuff/games/dolphin-emu/ubershaders.tar.xz
20:18karolherbst: orbea: looks good, thanks
20:18orbea: np :)
20:25parchd: sorry for asking this when I have neither the knowledge to help, nor the time to learn, but is there any update on the simultaneous thread access issue that is finding its way into more and more of the QT programs I use?
20:26imirkin_: parchd: not really.
20:27parchd: Thanks imirkin_. Fair enough. I realise that the issue is largely a result of bad design decisions, and that you lot have been left with the fallout.
20:27imirkin_: plenty of blame to be spread around if one's in for that sort of thing
20:27imirkin_: i was under the impression that kde and/or qt did *something* to lessen the issue
20:28imirkin_: but i don't really use that software myself, so not sure
20:28imirkin_: there is work being done to fix this in nouveau, but it's a pretty substantial rework of the 3d driver
20:28imirkin_: so ... tbd as to when that gets finished
20:28parchd: All I know is, more and more I need to tell QT applications to use software rendering only - which can be a pain
20:29imirkin_: i guess. no real reason for 99.99% of applications to need accelerated rendering beyond what X provides... oh well.
20:29imirkin_: for now your options are "don't use qt" or "don't use nouveau"
20:29parchd: but yeah, I did get the impression the work wasn't going to be a quick fix. I tried searching the IRC logs and mailing list for details of what was going on, but the only things I did find I didn't understand well enough to know if it was actually related.
20:30imirkin_: i did have some patches
20:30imirkin_: that "fixed" it with some issues
20:30imirkin_: unfortunately some geniuses started including them into distro packages
20:30imirkin_: at which point i was forced to take them down
20:30parchd: yeah, I read about that
20:31imirkin_: which is unfortunate - they could help a well-informed user. o well.
20:32parchd: happens a lot in open source... something is made available with a note "for advanced users to help test, not for production use", and all of a sudden every other email to a list is "I'm using this patch, and this is blowing up in my face"
20:32imirkin_: also unfortunate that nouveau did not properly support this perfectly valid GL usage
20:33imirkin_: and also unfortunate that the Qt/KDE folk didn't check if all drivers had proper support before making it a core of their library
20:33parchd: I see what you mean about plenty of blame to spread around
20:34imirkin_: and also unfortunate that there are very very few developers actively working on nouveau available to resolve this level of fuckup
20:34imirkin_: which is why i've been spreading my advice as far as i can -- if you care about OSS, stick to intel/amd.
20:36parchd: if I ever replace this machine (which is inevitable sooner or later, probably sooner sadly) I probably will go with intel
20:38karolherbst: sadly the only driver which will get fully free firmware is nouveau, even for most recent GPU chipsets
20:39parchd: heh... not sure my GPU counts as most recent anymore. Nvidia dropped support a year or two ago I believe.
20:40parchd: I have trouble understanding the extent to which things are locked down in the hardware/drivers world. If the physical product is good, why not make the code free?
20:41parchd: But idealism is a habit hard to break
20:41karolherbst: parchd: well, thats the future of the intel driver: the code is free, but everything important is inside closed firmware
20:42imirkin_: well, there are different levels of it
20:42karolherbst: well sure
20:42karolherbst: but for intel it's getting worse over time
20:42imirkin_: e.g. the broadcom thing which has effectively GL implemented in firmware
20:42karolherbst: not better
20:42RSpliet: at least Intel *releases* firmwares
20:42karolherbst: and currently we are playing nicely with nvidia
20:43karolherbst: we could also stop that act
20:43parchd: karolherbst: what would playing not nicely be? Aggressive reverse engineering?
20:43RSpliet: passive aggressive first
20:44karolherbst: I mean it would be a real shame if users woulc get access to those firmware files nvidia didn't release or are shipped somewhere within their driver
20:46parchd: terrible shame
20:46parchd: anarchy on the streets sort of thing
20:51parchd: I'm off. Night night.
21:01debo: ok, I blacklisted nouveau and I have a desktop and taskbar again
21:01debo: *-display UNCLAIMED
21:02debo: i was in this position 2 weeks ago
21:02debo: horrible resolution
21:03debo: how do i find which driver is running now?
21:07debo: ok, but why is it unclaimed?
21:07imirkin_: no clue what's saying that
21:09debo: lshw -c video
21:13debo: i don't suppose vesa supports 1368x768
21:13imirkin_: lshw probably has some fun internal logic to map drivers to pretty names
21:29snkcld: does 4.12 contain the changes required for GP107M?
21:30snkcld: i see code for the GP107, but i dont see M
21:30imirkin_: M doesn't matter
21:31imirkin_: it's all the same
21:31imirkin_: basic accel could work
21:31imirkin_: although another user was having trouble with the runpm on his laptop
21:33imirkin_: snkcld: https://bugs.freedesktop.org/show_bug.cgi?id=101665
21:33snkcld: imirkin_: ah, perfect. thats my laptop too.
21:34imirkin_: that was with 4.11... who knows, perhaps 4.12 fixes something there? dunno
21:34snkcld: imirkin_: nouveau doesnt even want to use my graphics card tho
21:34imirkin_: ouch. unknown chipset 0xfffffff means the gpu is off
21:35snkcld: how do i turn it on? lol
21:35imirkin_: (and so it reads all 1's, coz pci is active low or whatever)
21:35snkcld: echo enabled > /sys/blah/enabled ?
21:35imirkin_: nothing that simple
21:35snkcld: (fyi the gpu works fine in windows)
21:35imirkin_: talk to Kayden - he's the user who reported that laptop
21:35imirkin_: he said he had to do a ton of workarounds around ASPM
21:36imirkin_: he's one of the intel mesa developers
21:36snkcld: ohhh nice
21:36snkcld: ok, ill find his info on that page i guess
21:36imirkin_: he's not here, but hangs out in #dri-devel and #intel-gfx, among others
21:38snkcld: imirkin_: thanks!
21:39snkcld: imirkin_: why do you feel that bringing it online would be complex?
21:39imirkin_: it's not
21:39imirkin_: just have to give the right set of 75 kernel params
21:39imirkin_: if you check the logs, he said which ones...
21:39imirkin_: probably in #dri-devel on the day that he reported the bug
21:41snkcld: check IRC logs?
21:42snkcld: imirkin_: what do you use to check the logs?
21:42imirkin_: see topic
21:46imirkin_: by the looks of it
21:46imirkin_: and some kind of bios upgrade
21:46snkcld: oh i did =force... ok, brb
21:47imirkin_: 16:55 kayden: not this time...I'm using the 1.1.3 BIOS which doesn't even try...the kernel just notes it's broken and gives up
21:47imirkin_: 16:55 kayden: with the 1.2.4 or 1.3.3 BIOSes it actually tries so you have to do pci_aspm=off
21:47imirkin_: make that downgrade :)
21:47snkcld: no mention of pcie though?
21:49psychicist__: is anyone familiar with the nouveau kernel module crashing on systems with hybrid graphics (also in combination with nvme ssds)?
21:50mangix:has a feeling 4.12's nouveau will be totally broken
21:50snkcld: imirkin_: didnt change anything :(
21:50imirkin_: psychicist__: s/with.*//g yes
21:50snkcld: what day were those messages?
21:51imirkin_: june 30
21:51psychicist__: imirkin_, do you know if this has been fixed on recent kernels? I have had this with debian 9 so I had to blacklist the module and install the proprietary driver (which also performs better on this system)
21:52imirkin_: it's not like a single issue
21:52imirkin_: it's like 100 different issues
21:52psychicist__: oh, I see
21:53karolherbst: mangix: why?
21:53psychicist__: interestingly it never got triggered when booting off an usb drive so I think it has a lot to do with pci-e
21:54imirkin_: more likely the software you're using
21:54imirkin_: e.g. kde/qt5 is known to cause issues
21:54psychicist__: yes, I saw it as soon as I booted into the kde/qt5 desktop
21:55snkcld: imirkin_: looks like his solution was to just blacklist nouveau lol
21:55snkcld: guess ill try pcie_port_pm=off
21:55imirkin_: perfectly fine solution if the problem is "nouveau crashes with software i want to use"
21:56psychicist__: I wouldn't mind testing newer versions of nouveau, I have a second install without a proprietary driver just for this purpose
21:56imirkin_: if you're looking to use qt5/kde, won't help
21:57imirkin_: i'd recommend staying away from nouveau if you want to use qt5/kde, or alternatively staying away from qt5/kde if you want to use nouveau
21:58snkcld: imirkin_: this is interesting. i booted with "pcie_port_pm=off" and got this crash when modprobing nouveau
21:58psychicist__: I didn't know it was such a serious problem, nouveau worked stable with kde/qt5 when I was booting off a usb drive with a full debian install
21:58imirkin_: i think it started to happen with qt5.5 or something? not sure.
21:59imirkin_: or plasmashell?
21:59imirkin_: my knowledge of the precise situation is weak, as i do not use the affected software
21:59snkcld: imirkin_: http://termbin.com/7jvw
21:59snkcld: if you scroll to the bottom yo will see the nouveau crash
21:59psychicist__: I am not sure, as I only started running into this problem a few months ago
22:00imirkin_: snkcld: do you have updated linux-firmware?
22:00imirkin_: (that is, for the record, not a crash, but rather a WARNING)
22:00snkcld: oh sorry, warning
22:00snkcld: imirkin_: it does cause my machine to hang for like 5 seconds though
22:00imirkin_: snkcld: the initially released gp107 firmware was "wrong"
22:00snkcld: but then it doesnt hang for like 10
22:00snkcld: actually it stopped hanging
22:01snkcld: ill check the firmware
22:01snkcld: i will pull master on linux-firmware.git, then reboot
22:01imirkin_: it was updated a while ago
22:01imirkin_: but there was a "bad" period of time
22:02snkcld: i have the lastest firmware i believe
22:02imirkin_: and ASPM is disabled, so that's good...
22:02snkcld: (if the latest is on git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git )
22:02snkcld: well i removed that part
22:02imirkin_: [ 0.743180] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
22:02snkcld: i booted wtith only the pci_port_pm off
22:03snkcld: because my OS was turning off aspm anyway
22:03snkcld: lspci is hanging
22:03snkcld: just like he said
22:04imirkin_: coz the gpu can't wake up
22:04imirkin_: coz it failed to go to sleep
22:04imirkin_: or something
22:04psychicist__: I guess I'll use my second install to build newer nouveau releases and kernels for testing
22:04snkcld: bummer :(
22:04imirkin_: snkcld: try runpm=0
22:04snkcld: now my touchpad isnt working lol
22:04snkcld: as a module option?
22:04snkcld: imirkin_: or kernel
22:05imirkin_: however you set that is fine
22:05imirkin_: either runpm=0 option on nouveau, or nouveau.runpm=0 on kernel cmdline
22:08snkcld: imirkin_: `moprobe nouveau runpm=0`?
22:08snkcld: that mod
22:08imirkin_: not sure if modprobe takes it on cmdline
22:09imirkin_: you can stick it in modprobe.conf with "options nouveau runpm=0"
22:09imirkin_: or use insmod
22:10snkcld: imirkin_: looks like it does
22:10snkcld: so far no hanging... (except for the initially module load)
22:10snkcld: ok, going to try lspci now
22:10snkcld: if i dont respond that means it hung my machine
22:10snkcld: whoa it worked
22:11snkcld: so uh
22:12snkcld: i just rand DRI_PRIME=1 glxinfo, looksl ike thats hanging
22:12imirkin_: as expected
22:12snkcld: nvc0_screen_create:864 - Error allocating PGRAPH context for M2MF: -16
22:13imirkin_: yeah, your accel didn't come up properly.
22:13snkcld: javad@javad-XPS-15-9560 ~ DRI_PRIME=1 glxinfo | grep -i vendor
22:13snkcld: nvc0_screen_create:864 - Error allocating PGRAPH context for M2MF: -16
22:13snkcld: libGL error: failed to create dri screen
22:13snkcld: libGL error: failed to load driver: nouveau
22:13snkcld: server glx vendor string: SGI
22:13snkcld: client glx vendor string: Mesa Project and SGI
22:13snkcld: Vendor: Intel Open Source Technology Center (0x8086)
22:13snkcld: OpenGL vendor string: Intel Open Source Technology Center
22:13snkcld: oops, sorry
22:13snkcld: imirkin_: so pretty much its not working due to... the pci power management layer?
22:13snkcld: or is the GPU like, not behaving properly
22:13imirkin_: GPU is not behaving properly
22:13imirkin_: we tried to load firmware onto it, and it didn't like it.
22:14imirkin_: or something along those lines.
22:14snkcld: imirkin_: if i recall correctly doesnt the new firmware have to be signed or something?
22:14imirkin_: it does.
22:14snkcld: is the firmware on linux-firmware the signed one?
22:14imirkin_: it is.
22:19snkcld: imirkin_: what part of the log indicated to you that it was related to the firmware not being accepted?
22:19imirkin_: gr failing to come up
22:19snkcld: what does gr stand for?
22:20imirkin_: or graph
22:20imirkin_: we'll never know
22:20snkcld: isnt this the channel that like... writes this code?
22:21imirkin_: i believe ben took the names publicly available in the gk20a driver
22:21snkcld: and gr is code related to firmware stuff?
22:22imirkin_: no, but graph unit needs firmware
22:22imirkin_: for context switching
22:45mangix: karolherbst: i'm on skeggsb's 4.11 branch
22:46mangix: i backported all of Gnurou's changes + your maxwell 2 ones. worked. then in backported some more from 4.12. it broke
22:47skeggsb_: snkcld: gr is just an abbreviation of "graphics"
22:47skeggsb_: nothing more
22:47skeggsb_: "graphics" isn't an entirely accurate name for that engine these days anyways
22:54tm512: imirkin_: you were the one helping me out the other day, right?
23:01imirkin: skeggsb_: i prefer it my way... "grrrrr"
23:01imirkin: tm512: it's possible... ppc + nv17 guy right?
23:02tm512: ppc yeah, according to glxinfo the card is nv11 though, iirc
23:02imirkin: ah yeah, wtvr
23:02tm512: I wasn't able to get apitrace compiling on FreeBSD
23:02imirkin: oh, and you wanted me to check if nouveau_vieux was totally fubar on ppc or not
23:02imirkin: tm512: does glxgears work ok for you?
23:02imirkin: coz if not, you're in serious trouble :)
23:03tm512: yeah, glxgears works perfectly fine, and stays around the refresh rate
23:03imirkin: hmmmm ok
23:03imirkin: so something's working at least a little. that's nice to know.
23:03tm512: I guess I didn't check to see if it eventually went blank or not
23:03imirkin: can you share your application with me?
23:03imirkin: (is it easy to run?)
23:04tm512: I don't mind sharing the source code. it only depends on glfw
23:04imirkin: ok cool
23:05imirkin: hopefully i can (a) confirm that it's all fine with nouveau_vieux on LE and (b) look at why it might be failing on BE
23:05imirkin: could be that it's broken on LE too
23:05tm512: it uses a custom build script, which only depends on POSIX sh and pkg-config, works on linux, freebsd, and openbsd at least
23:06imirkin: nouveau_vieux is hardly a perfect driver, so i wouldn't be overly surprised
23:06imirkin: ok cool - and i don't mind messing with build things if push comes to shove
23:06imirkin: (esp if they're simple things and not cmake)
23:07tm512: yeah, I'm pretty averse to cmake myself, and I'm not a fan of make because scripting in it is a bit irritating
23:07tm512: my build script just uses find -newer to determine what needs to be recompiled
23:10imirkin: skeggsb_: did you want me to respin that patch, or will you take care of dropping the hunk?
23:11imirkin: tm512: i'm ready whenever :)
23:11tm512: yeah, just tarring this up
23:16tm512: imirkin: http://entropixel.com/1gam-src-20170703.tar.gz
23:16tm512: just ./build and ./1gam should suffice, as long as pkg-config can find glfw
23:18imirkin: ok cool
23:21imirkin: tm512: ok, and what's the precise issue you're seeing?
23:22imirkin: i'm seeing a bunch of random-ish red lines with nouveau on GK208
23:22imirkin: which change every time i start it
23:23tm512: huh. those shouldn't be random
23:24imirkin: the precise pattern changes from run to run
23:24tm512: the issue on my powermac was that eventually, the screen would just go blank. that was before I added in the level rendering though
23:24imirkin: this isn't on a nv11 though (or similar). it's on a modern GPU, for which nouveau has pretty good conformance
23:24imirkin: (though nothing's perfect)
23:24tm512: only the lines at the border of the level should be showing
23:25tm512: they're there so I could verify the vertex data I am going to use for collision detection
23:25imirkin: i'm also seeing this on the nv50 driver
23:25imirkin: as well as llvmpipe
23:26tm512: http://i.imgur.com/JREvWUW.png is on intel, on FreeBSD
23:26imirkin: yeah, i mean i get the intent...
23:26imirkin: could be you're triggering an issue in st/mesa
23:27imirkin: or could be that you have a bug that i965 happens to gloss over
23:27imirkin: where do you draw those lines?
23:27tm512: on my old nvidia, the issue seemed to have to do with drawing the textured polygons, not the lines
23:27tm512: and the lines are drawn in render_scene, which is at the bottom of render.c
23:28imirkin: could numlines be way off?
23:28tm512: on the old nvidia, seemed like the amount of time it took to go blank, was correlated with the number of polygons I was rendering, so with the full level rendering, the problem should have shown up really fast
23:29imirkin: lines: 2388, coord: 15656752
23:29imirkin: printf("lines: %d, coord: %d\n", level->numlines, level->linecoord);
23:29imirkin: seems high for numlines.
23:30tm512: yeah, that's actually the number of non-empty tiles, not all of which have corresponding lines, so...
23:30tm512: but the screen doesn't just end up going black for you?
23:31imirkin: well i havent' tried it on the older gpu
23:31imirkin: only newer so far
23:31imirkin: older is harder... have to remember how to do it ;)
23:31tm512: aside from the lines, it looks like everything is rendering fine
23:31imirkin: how long would i have to wait for it to blank out?
23:32tm512: it was only taking a couple seconds, and that was without the level being rendered
23:32imirkin: ohhh wait
23:32tm512: I'd expect it to be nearly instant with the level rendering, but I can double-check that real quick
23:32imirkin: i think int h should be ret->numlines
23:32imirkin: not i / 3
23:33imirkin: nope, that's not it
23:33imirkin: (or * 4)
23:33tm512: I don't think so. i is the offset into the vtxcoord/texcoord arrays, which have 3x as many vertices as the line array
23:34imirkin: right, but what if there are holes in the collisions
23:34imirkin: [not like i know your code, just guessing]
23:34imirkin: perhaps you have another stage that compacts it all
23:34imirkin: but down the line you draw the entire array
23:35tm512: what do you mean exactly by holes in the collisions?
23:35imirkin: not every tile will have a collision
23:35imirkin: so the entire linecoord array won't be initialized
23:35imirkin: let's try to memset it with 0's...
23:35tm512: oh, I see what you mean
23:36imirkin: hm, nope...
23:36tm512: I'm over-allocating
23:36imirkin: well, that's fine - more importantly you're setting data at the tile index
23:36imirkin: but you're drawing based on the total number of collisions.
23:37imirkin: (and what happens if !tile->solid... same thing)
23:37imirkin: but that bit actually seems fine
23:37tm512: yeah, I was kind of rushing when writing that code, just needed something quick, and didn't think it through all that much
23:38imirkin: yeah no worries
23:38tm512: that's not really the problem that I'm concerned about, since that code shouldn't be sticking around for long anyway
23:39tm512: you could go ahead and set debug = 0 in main.c, or simply delete the GL_LINES rendering stuff in render_scene, if it'll be messing anything up
23:40tm512: gonna hop on over to the G4, and test the latest code
23:40imirkin: ok, so with NV34 it still renders. let's try with NV25....
23:41imirkin: it *seems* like it works with the nouveau_vieux driver on LE
23:44ppc512: oh, on big endian, the level will fail to load. I forgot to add byte swapping for the 32-bit integers
23:45imirkin: i let it run for a while, with the nouveau_vieux driver running on a NV34 (emulating a NV25), it all seems fine
23:46imirkin: you don't seem to do anything too crazy in here, so ... dunno
23:46ppc512: excuse my ignorance, but what is the _vieux driver?
23:47imirkin: the driver that handles nv04..nv28
23:47ppc512: is that just the complete name of the nouveau driver?
23:47ppc512: ah, I see
23:47imirkin: those were fixed-function-only GPUs
23:47imirkin: (well, nv2x had kinda-sorta programmable things, but was still much better at fixed function)
23:48imirkin: nv30 = GeForce FX 5xxx series
23:48imirkin: nv2x = GeForce 3 / GeForce 4 Ti
23:49imirkin: nv30+ are all handled with gallium drivers, while earlier chips have their own "dri" driver
23:49imirkin: that one's called nouveau_vieux
23:49ppc512: I'm just fairly unfamiliar with nvidia and ati gpus
23:49imirkin: (vieux = old in french, while nouveau = new)
23:50imirkin: gives a good breakdown of it for nvidia
23:50ppc512: since I don't do much gaming, I stuck with intel because the open source drivers at least used to have much better performance
23:50ppc512: not sure how nouveau fairs nowadays
23:52ppc512: if you'd like, I still have this apitrace dump
23:52imirkin: i thought you coudlnt' get apitrace to work
23:53ppc512: it compiled fine on the G4, which has debian
23:53imirkin: oh i see.
23:53ppc512: I couldn't get it compiled on FreeBSD in order to try replaying the dump
23:54imirkin: oh btw - dumb question - what version of mesa is on the G4?
23:54imirkin: coz about 100 years ago, i fixed some pretty serious bugs in nouveau_vieux
23:54imirkin: but ... debian could easily be older than that
23:54ppc512: OpenGL version string: 1.2 Mesa 10.3.2
23:54imirkin: iirc those fixes went into 10.3
23:54imirkin: lol. let me check then.
23:55ppc512: this is debian 8
23:55imirkin: ok, this is the fix i had in mind - 8867ffbf95808dfa82029ad89d1571799a242d4d
23:55imirkin: and looks like it did make it into 10.3 :)
23:55imirkin: so you're good there
23:57imirkin: and even b13a4ca3f7f622cbf688eec14d3f4156533af44e was backported into 10.3 as well (including the original release, just post branchpoint)
23:59ppc512: I'll get that trace real quick