01:10pmoreau: Weird: changing that timer back to previous behaviour on HEAD makes nv50_fb_ctor fail on my MCP79 due to an "unable to handle kernel paging request", but it works for the G96.
01:13pmoreau: Ok, maybe not that weird. It could just mean there was another change that made the MCP79 unhappy about it, and makes the additional mask necessary to take into account this unhappyness.
01:25karolherbst: ohh nice, with the blob I get the exact PLL configs reg values, at least for my 0f pstate
01:25karolherbst: didn't check that yet
01:26mupuf: karolherbst: hey, did you see my tool peek_diff?
01:26mupuf: it lives in vbios/scripts/
01:26karolherbst: I investgate a gddr5 instability with my patch currently
01:27mupuf: well, it could help you
01:27mupuf: you just peek a range of registers on hte blob
01:27mupuf: same on nouveau
01:27karolherbst: I debug not with my values
01:27mupuf: and run peek_diff to see the difference and parse the differences
01:27karolherbst: also I do a lot or reclocks now, so
01:27karolherbst: thanks for the info, but I doubt it will help me now
01:27mupuf: well, you may find use for it in the FB area
01:27mupuf: that is why I wrote this tool
01:28karolherbst: I see
01:29karolherbst: seems like the blob doesn't like a mem clock of 2988000*2
01:30karolherbst: but why
01:31karolherbst: also I have a little script which parses the values of both PLLs out
01:34karolherbst: I don't get the issue
01:34karolherbst: I doubt there is anything wrong with the PLLs now
01:35karolherbst: boah, stupid blob
01:35karolherbst: blob just crashed :/
01:36karolherbst: Karlton: okay, I don't think there is anything wrong with my patch as it is, maybe the difference in clock is bad, but well :/
01:36karolherbst: will finish this then
01:41karolherbst: RSpliet: still there?
01:41karolherbst: anyway, I don't get this line: https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/clk/gk104.c#L69
01:42karolherbst: fN is never set for the second PLL, so is it like always 0xf000?
01:47RSpliet: karolherbst: yes, and now try and figure out what (u16)0xf000+4096 is :-P
01:47karolherbst: RSpliet: mhhh
01:47karolherbst: I have a bug inside my patch :D
01:47RSpliet: spiders like eating those
01:48karolherbst: when I calculate the error, I should kind of use that fN value then
01:49karolherbst: for some reasons, it doesn't matter for my 0f pstate
01:50karolherbst: but this explains why everybody got a lower clock with my patch
01:51karolherbst: okay, now fN adjustment
02:19karolherbst: RSpliet: 0.004MHz difference from requested ones for me now :)
02:26pmoreau: skeggsb: http://cgit.freedesktop.org/~darktama/nouveau/diff/drm/nouveau/nvkm/subdev/fb/rammcp77.c?id=9d8e8873c8c9d321e888e4750ed941a1aa2a2efe
02:26pmoreau: - *pobject = nv_object(priv);
02:26pmoreau: + *pobject = nv_object(fb);
02:26pmoreau: I guess that's the culprit
02:37pmoreau: Yup, it was :)
02:48karlmag: Hi, I'm new in here, so forgive me if my questions are stupid. I was reading "[...] multicard setups are very rare among developers." I started wondering about the reason for that. Lack of hardware? (It be [identical] graphics cards or mobos to hold -say- multiple pcie card) Or maybe not having enough monitors. Or perhaps not really having room for more monitors.
02:48karlmag: The reason I started wondering was putting two dual cards in a machine and only having one being configured automagically.
02:49karlmag: Got it woriking using the MultiMonitorDesktop tips, but yeah, long time no xorg.conf was my conclusion :-)
02:51RSpliet: karlmag: well, there's multicard setups and there's SLI
02:52RSpliet: generally to justify a multicard setup with kepler and newer you need 5 monitors, which... well, no comments
02:52karlmag: I know. I guess they are somewhat different beasts
02:53karlmag: (code wise at least)
02:53RSpliet: if you want superultrafast rendering on a single monitor or something (which is where SLI comes in), nouveau is an interesting choice of driver
02:53RSpliet: as there are quite a few other performance bottlenecks
02:53RSpliet: for single-card set-ups
02:53karlmag: Nah, I want to connect umteen monitors to my system, basically. And rather use whatever cards I have/get my hands on without having to sell said hands or other lims first :-P
02:54pq: there are also dual-gpu cards, which counts more or less as multi-card.
02:55karlmag: Having everything automagically being configured is the ideal situation, obviously.
03:00karlmag: If I am to guess I would think most developers have multiple cards, though possibly not identical ones (that may or may not be an issue though). I would think either "motherboards taking multiple cards" and/or "having enough monitors" are more of an issue. And time and priorities, obviously.
03:01specing: time is always the biggest issue
03:01karlmag: I might be able to wrestle up some (unspecified for now) cards (identical too) and send those to some developers, but not sure if that's where the main issue is.
03:01karlmag: specing: yeah, I know that from my own existence too.
03:03karlmag: I'm unfortunately no programmer, so not much I can do in that department, I'm afraid.
03:04specing: not sure if anyone is paid to work on nouveau, but there are 4 devs chatting almost every day here
03:04karlmag: that's cool :-)
03:05karlmag: What I do see, however is that more than two monitor setups and also multi grapics card setups are getting more common than it used to be.
03:05specing: radeon has atleast two employed by AMD
03:07specing: AMD still has a proprietary option rom blob (atombios) that initializes the card
03:07karlmag: a few years back we had so much problems with ati/amd graphics card that we actually had to ban the purchase of them for use with Linux.
03:07specing: I think nvidia has the same, but idk
03:07RSpliet: karlmag: a single Kepler can drive up to 4 monitors
03:07specing: karlmag: I still have them, heh
03:08specing: karlmag: had to patch 4.0.8 because of hangs (same on 3.18)
03:09karlmag: Maybe I should present myself a little bit more; I work as a Linux system admin (client computers, not servers). We're deplying a few hundred Linux machines to people. However, the question was related to private setups though.
03:10karlmag: s/client/workstation and laptops/
03:11bozhan: hi yesterday karolherbst told me that i need to run : "optirun -b none bash " to make mmiotrace on my Optimus card... but i only get some errors is it worth to make such trace? here is what i get: http://pastebin.com/5Z15w4s4
03:11bozhan: or it was day before yesterday...
03:12specing: karlmag: and you are no programmer? wtf?
03:12karolherbst: bozhan: you can also start X on the second card
03:12karolherbst: but I was thinking that optirun would be easier because you had a bumblebee setup already?
03:13karlmag: specing: *shrugs* well, I never pursued programming that much. So, no I'm not a programmer. I do some scripting and stuff, but I'd not call that programming per se.
03:15bozhan: yes i have bumblebee setup... if you ask me that?
03:15karolherbst: bozhan: seems like that it doesn't work?
03:16bozhan: i just get errors. did you open that pastebin?
03:16karolherbst: did bumblebee ever worked for you?
03:17bozhan: yes in multiuser i can run optirun glxgears -info and i get that it is run on nvidia card
03:18karolherbst: what do you mean by "multiuser"?
03:18bozhan: i even can play dota2 or tf2
03:19bozhan: in pastebin i am running this in recovery mode...single user
03:20bozhan: because that is what i've understand from https://wiki.ubuntu.com/X/MMIOTracing
03:20karolherbst: where does it state you need sinlge-user mode?
03:20bozhan: The initial set up for an MMIO trace needs to be done before the driver is loaded. This means that we need to do it outside of X.
03:21bozhan: Boot your system in “recovery mode”. You can select this from the GRUB boot menu. If the GRUB menu is not shown by default you can bring it up early in your boot process by pressing the “shift” key. Select “Drop to a root shell prompt” from the recovery menu to bring up a terminal.
03:21karolherbst: you only need to enable mmiotrace before loading the nvidia module
03:21karolherbst: which is no big deal on a laptop
03:21karolherbst: because its usually not loaded by deafult
03:22karolherbst: so what you need to do is this
03:22karolherbst: 1. Enable the mmio tracer
03:22karolherbst: 2. optirun -b none bash
03:22karolherbst: 3. do whatever
03:22karolherbst: 4. exit
03:22karolherbst: 5. wait until trace is finished
03:22karolherbst: you can also start X directly on the second card without bumblbee, but it really doesn't matter
03:23karolherbst: its only nice to use bumblebee, because you can actually see what the card is doing or do other stuff on it
03:24bozhan: when i start my laptop it starts X directly , did i have to stop X first and than to others stuff?
03:24bozhan: to dp
03:25bozhan: to do
03:25karolherbst: you are on a laptop
03:25karolherbst: X runs on the intel card
03:25karolherbst: not nvidia one
03:25karolherbst: bumblebee starts a second X server for you
03:26karolherbst: you can also start it directly without it, but I was thinking it would be easier for you to use bumblebee
03:26bozhan: yes i just think , aren't other stuff goes to that trace from intel card :)
03:27bozhan: ok, thank you. :)
03:45pmoreau: Hum... 7a8569d fixed it, so it broke again somewhat later.
03:45pmoreau: Oh well, bisect take 2: action!
04:26librin: Is there any way to completely disable HDMI audio support on the nouveau driver initialization?
04:27librin: i.e. is there a way to load nouveau so that it would be completely stripped of HDMI audio capability?
04:30pmoreau: librin: I don't think so: it doesn't look like there is a kernel parameter for that.
04:31RSpliet: librin: that's a very uncommon use-case you ask; is there a particular reason why it must be disabled rather than just say - muted?
04:33librin: yes – I am investigating a [massive] rendering slowdown in cs:go that appears in nouveau, but doesn't appear on the blob at all
04:33librin: a slowdown that is caused by guns being shot
04:34librin: yet, I observe the slowdowns regardless if it happens on-screen or off-screen
04:34librin: i.e. regardless if it is actually rendered or not
04:34librin: which suggests it's some weird audio-related problem
04:34librin: and the HDMI audio is the only nouveau/blob thing I can think of
04:36pmoreau: One way to *disable* HDMI audio would be to plug the screen using a DVI cable I guess
04:36librin: RSpliet, and that's why I want to test it with HDMI audio completely disabled; even though I have audio output to HDMI "disabled", that doesn't prevent querying and so on
04:37librin: pmoreau, that still leaves it open for querying
04:37librin: i.e. being checked for existance
04:37librin: I suspect that what's happening
04:37librin: got no other semi-sane explanation
04:39pmoreau: I checked: there is no param you can give Nouveau to disable HDMI audio.
04:39librin: pmoreau, thanks
04:39pmoreau: I think there was a bug report concerning HDMI audio, I'll have a look
04:39librin: guess I'll just have to roll up my sleeves and start commenting out some code
04:41pmoreau: What card do you have btw? And which Linux version are you using?
04:42librin: 2x GTX 770 and 4.2
04:42librin: although, I see the slowdown since as long as I can remember
04:42librin: i.e. at least since 3.1x
04:43librin: was simply using the blob for everyday things until about a year ago B|
04:46pmoreau: Don't seem to find any related bug report
04:47pmoreau: Do you have any error messages in dmesg or Xorg.0.log?
04:49karolherbst: meh, somebody broke mesa
04:50librin: pmoreau nothing that'd look even remotely related
04:51pmoreau: So, no Nouveau errors at all I guess
04:55pmoreau: nouveau_drm.c and nv50_display.c seems to be the only files in Nouveau talking about audio
04:55pmoreau: You could try hacking from there I guess
04:57librin: Already on it ;]
04:57librin: and thanks!
04:58pmoreau: You're welcome :)
04:58pmoreau: Good luck!
05:09msgctl: imirkin: it worked, but now I can't see the second DVI port in xrandr :v
05:10msgctl: o tempora o mores
06:22pmoreau: So http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=623829322f166f9a37b03716155c9a7f44d36c43 is the one who broke external screen support on my laptop.
06:22pmoreau: It will take some time to analyse it
06:25RSpliet: librin: keep in mind that it could well be related to problems related to culling vectors that are outside the viewport
06:26librin: RSpliet yes, indeed
06:27RSpliet: (eg. not audio related)
06:27librin: I did some testing already – it indeed is NOT audio-related
06:56pmoreau: With commit 623829, Nouveau considers "dcb 2 0/6" as not supported, whereas before it did support it. Looks like the ctor in nvkm_disp_create_ is returning -ENODEV now
06:59huehner: karolherbst: i didn't get around to test your reclocking patches on my kepler/gddr5, and will be out now 2 weeks. If there is some thing still to test around end of september ping me then
07:07pmoreau: l1k: Thanks for the patch! I'll try to test it tonight, but most likely I will only have time tomorrow or on Sunday.
07:10Karlton: karolherbst: vanilla nouveau sets my mem clock higher at 0f
07:11Karlton: AC: core 1293 MHz memory 6075 MHz
07:11Karlton: and once at 6048 MHz
07:20Karlton: karolherbst: except I could only change the pstates 3 times before the screen went black xD
07:28RSpliet: Karlton: PLL generation is not necessarily the only thing that could go wrong with GDDR5 reclocking on Kepler
07:29RSpliet: shakesoda: I'm curious to hear your reclocking tests on the GDDR3 Tesla :-D
07:29RSpliet: or well, if I hear the tests I'm worried, but if you could inform me of the test results
07:29RSpliet: that'd be grand
07:30shakesoda: RSpliet: I should be able to do that today or this weekend, link the repo again?
07:30RSpliet: erm... yes
07:30RSpliet: I did a rebase a few days ago, so I'll try and test it tonight first myself
07:31RSpliet: and fix issues may there be any
07:50librin: ...did someone mention a Kepler reclocking patch?
07:53RSpliet: librin: well, there's definitely developments on that area recently...
07:54RSpliet: nothing finalised though
07:55librin: where do I sign up for testing? xD
07:58Karlton: librin: checkout the gddr5 branch from https://github.com/karolherbst/nouveau
08:04l1k: pmoreau: no need to hurry, we're not on the run. :)
08:04RSpliet: karolherbst: can I offload a small task to you, as proud owner of a GDDR5 board?
08:06RSpliet: karolherbst: a little while ago I wrote this thing: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/686eea0c7c9e629c06aec45b32e6860747b3c563
08:06RSpliet: and adapted the DDR3 reclocking routine to include DLL reset when required
08:06RSpliet: but... I couldn't see what the blob does on GDDR5 in the case DLL is enabled
08:08RSpliet: would you mind faking a VBIOS to trace how altering the DLL enable changes the reclocking script? you might want to try that in a low clock configuration, as there's a lot more leeway in the configs there
08:18Human_G33k: hello, do you know if nouveau and wine used to work fine together ?
08:20Human_G33k: because i have some graphical trouble in game
08:28RSpliet: Human_G33k: you might want to give a bit more details than "nouveau and wine"
08:29Human_G33k: ok i take a screen :)
08:29RSpliet: I mean, I do assume that you are not talking of the favourite beverage of the developers here, but any games in particular? stock wine or with NINE? Is your nouveau properly up to date?
08:34Human_G33k: RSpliet i'm on debian stretch, nouveau version is 1:1.0.11-1+b1 ; here you can see a example of troubles with wine http://i.imgur.com/AglXPG8.png
08:35RSpliet: went through the basic troubleshooting questions?
08:37Human_G33k: i talk in winehq irc and i checked basic troubleshooting question yes
08:37RSpliet: wait a tick... is that a debian version with actual up to date packages? :-P
08:38RSpliet: right, okay
08:39RSpliet: continuing: mind pasting your dmesg into a paste website of choice and sharing the URL?
08:40RSpliet: (furtheron referred to simply as pasting ;-))
08:40specing: there is no such thing, as landing in debian means the package is obsolete ;)
08:41RSpliet: specing: kernel 4.1, mesa 10.6.something... stretch is not so terrible from what I can judge
08:41specing: yeah, even my Gentoo boxen are using older
08:42RSpliet: but that has funrolled loops! :-P
08:42RSpliet: Human_G33k: sorry, let me highlight you again, just in case you missed me :-)
08:42specing: yes it does
08:42librin: Human_G33k, that looks eerily similar to a problem I reported earlier
08:42librin: sec, lemme find the bug report
08:42Human_G33k: ok thx librin
08:44librin: might be the very same issue
08:48RSpliet: Human:G33k: just for the sake of it, in addition to sharing your dmesg, would you mind trying to disable MSAA x4 and see if it makes any difference whatsoever
08:48librin: Human_G33k, hmm... after taking another look at Your screenshot, I am 99.99999% sure it's the same issue
08:48Human_G33k: librin it's ! and there is the same type of issue on guid wars 2
08:49Human_G33k: ok i going to wait :)
08:50librin: FWIW, running the game in OpenGL mode works fine for me.
08:50librin: at least with a WotlK client
08:51librin: no idea about the latest client
10:02msgctl: any clue why I'm not getting all the video outputs on modesetting driver?
10:04imirkin: msgctl: pastebin xorg log and xrandr output
10:12msgctl: imirkin: http://pastebin.com/8EpXzJ8u here it goes
10:12imirkin: and what's the issue?
10:13msgctl: in xrandr, I don't see the outputs I had on nouveau X driver before
10:14imirkin: btw, this probably isn't great:
10:14msgctl: I can't really use them
10:14imirkin: [ 18.668] EGL_MESA_drm_image required.
10:14imirkin: [ 18.668] (EE) modeset(0): glamor initialization failed
10:14msgctl: certainly doesn't look good
10:14msgctl: is it a known issue?
10:14imirkin: but that has to do with accel
10:14imirkin: which isn't your immediate issue
10:14imirkin: which outputs did you see with the nouveau DDX that are missing now?
10:15imirkin: that's DVI-0 now.
10:15msgctl: DVI-0 is DVI-D-1
10:15imirkin: pastebin the output of 'grep . /sys/class/drm/card*-*/status'
10:16imirkin: ooh fun
10:16imirkin: airlied: --^
10:17imirkin: could there be a bug in modesetting that aliases DVI-D and DVI-I?
10:19imirkin: [i'm also asking in #xorg-devel]
10:21imirkin: yeah looks like a bug in modesetting
10:21towo`: that root=/dev/vda1 looks like a virtual machine, so maybe that's the problem?
10:21msgctl: it is
10:22imirkin: msgctl: would you be able to apply a patch and rebuild?
10:22msgctl: imirkin: sure
10:22msgctl: is it the kernel?
10:22imirkin: no, xserver
10:23imirkin: msgctl: http://hastebin.com/carabesoxu.md
10:23imirkin: i dunno if i got the order of all that right
10:35imirkin: msgctl: you're using gentoo iirc, which allows pretty easy user-patching
10:35imirkin: let me know how it goes
10:37msgctl: imirkin: I cloned a repository from the ebuild, tag 1.17.2
10:37msgctl: just started compiling
10:37msgctl: doing it right?
10:37msgctl: (after applying your changes, that is)
10:37imirkin: msgctl: erm... not doing it *wrong* but it'd be easier to just do it by patching the gentoo build
10:38imirkin: you can stick user patches into... /etc/portage/...something
10:38msgctl: ah yes
10:38msgctl: there was a patch list
10:43msgctl: > * !!! User patches were applied to this build!
10:44imirkin: faster than figuring out how to build it all yourself
10:44imirkin: and more likely to work in the end
10:50msgctl: xantico ~ # strings $(which X) | grep DVI
10:50msgctl: and so on, but no changes in xrandr output
10:50msgctl: should I look for anything else?
10:52imirkin: it still says DVI-0 ?
10:53imirkin: you did restart X yes?
10:54imirkin: robclark: --^ fail :( didn't read closely enough, it uses find_output which in turn iterates over xf86_config->output
10:54msgctl: ah, stupid. I thought getting to xdm and back does that
10:54msgctl: it's working
10:55msgctl: at least, the output is different
10:55imirkin: oh, it's good?
10:55msgctl: I'm going to try to get the other monitor to work.
10:55msgctl: big thanks, and that's quite inspiring BTW
10:55imirkin: ah yeah. drmmode_output_init() which sets that array up also calls the same function (where it hits the fallback case)
10:59msgctl: sweet, it's running great
10:59imirkin: very slowly though, i'm guessing
10:59imirkin: since... no accel if glamor init failed
10:59imirkin: should probably look into why
11:00imirkin: mesa only started supporting maxwell in 10.3.x iirc
11:00imirkin: and you'd need linux kernel 4.1+ in order for accel to actually work out of the box
11:00msgctl: In despair I turned off nouveau in VIDEO_CARDS and recompiled related packages.
11:00msgctl: I'm going to recompile them w/ nouveau useflag, like it's been before
11:00msgctl: it was working back then
11:01imirkin: ah ok :)
11:01imirkin: yeah, glamor uses GL for accel
12:04briocalter: How do I use the mesa libs from git instead of the default ones on fedora? It's compiled and installed on /usr/local/lib/
12:06imirkin_: although you might consider installing somewhere into /home instead so that there's no need to be root and accidentally the whole thing
12:06briocalter: yea, went default
12:07briocalter: OpenGL renderer string: Gallium 0.4 on NVE4
12:07briocalter: OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.7.0-devel (git-6844d6b)
12:07imirkin_: right, /usr/local is the default prefix
12:07imirkin_: but you can override it when running configure
12:07briocalter: am I on the wrong branch? Thought it was 11
12:07imirkin_: anyways, that's a pretty old git checkout
12:07imirkin_: before 10.7 got renamed to 11.0
12:08imirkin_: and before the tess stuff landed
12:08briocalter: I'm really confused with git, git pull apparently doesn't update my copy
12:09imirkin_: do you have local stuff that you care about?
12:09imirkin_: then run
12:09imirkin_: git checkout master
12:09imirkin_: git reset --hard origin/master
12:09imirkin_: what commit does it say you're on when you run 'git show'?
12:10briocalter: commit from today
12:11briocalter: thanks, recompiling
12:18briocalter: odd, glxinfo still pointing to that old commit
12:18briocalter: make install copied the files to default dir
12:19imirkin_: well, if it's to /usr/local you have to run it as root
12:19imirkin_: unless there's something special going on
12:19imirkin_: alternatively you might not be building nouveau and so it's leaving the old nouveau you had there
12:19briocalter: might be
12:19imirkin_: what configure line did you use?
12:20briocalter: none :)
12:20imirkin_: can't build without doing a configure
12:20imirkin_: head config.log
12:20imirkin_: should provide you with the line that was used
12:21briocalter: --with-nouveau then?
12:23briocalter: gonna need a newer libdrm_nouveau
12:24imirkin_: yeah, various requirements got bumped
12:27karolherbst: RSpliet: what is https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/686eea0c7c9e629c06aec45b32e6860747b3c563 ?
12:29imirkin_: delay loop i think?
12:29imirkin_: delay loop lock?
12:29imirkin_: delay-locked loop
12:29karolherbst: mhh what is it for?
12:29imirkin_: i was close ;)
12:30karolherbst: even more stable reclocking?
12:30imirkin_: to enhance the clock rise-to-data output valid timing characteristics of integrated circuits (such as DRAM devices). DLLs can also be used for clock recovery (CDR).
12:30imirkin_: iirc you use it at either higher or lower speeds, and turn it off for the opposite
12:32RSpliet: that's what NVIDIA usually does yes
12:32karolherbst: ohh I get it now, I shall check what the blob does on a gddr5 board here
12:33RSpliet: well, yes, but with a VBIOS that actually has the DLL enabled
12:33RSpliet: which apparently is not that common on GDDR5
12:33karolherbst: how do I check?
12:33RSpliet: see if we can recognise the well-known reset sequence
12:33RSpliet: fake a VBIOS to set the bit in one of the perflvls, clock about a little, trace it
12:34RSpliet: and see if you see two consecutive writes near the end of the reclocking sequence to the same reg with one bit difference
12:34RSpliet: to one of the MR registers
12:34karolherbst: never manager to fake the bios...
12:34RSpliet: you can even sort out which bit that is from the docs
12:35RSpliet: it's easy... boot into initlvl 4 when the blob is installed, unload nvidia, fake your bios, start X
12:35briocalter: oh wow
12:35briocalter: nvc0/nvc0_screen.c: In function 'nvc0_screen_create':
12:35briocalter: nvc0/nvc0_screen.c:682:16: error: 'NOUVEAU_BO_COHERENT' undeclared (first use in this function)
12:36karolherbst: RSpliet: I have a laptop, no such drastic measures needed
12:36imirkin_: briocalter: need a newer libdrm...
12:37briocalter: yep, got from git
12:37imirkin_: briocalter: it shouldn't have let you get that far without it... odd..
12:37karolherbst: RSpliet: so I need to poweron the gpu, fake the bios, load nvidia, start x
12:37RSpliet: well, make sure the nvidia GPU does...stuff to initialise it and such
12:37imirkin_: it's probably picking up your system one instead of the one you told it to use :(
12:37RSpliet: for Optimus your milage may vary :-P
12:37RSpliet: but make sure nvidia is not loaded until you faked your vbios
12:37karolherbst: RSpliet: yeah, I know
12:37imirkin_: briocalter: what configure line are you using?
12:37karolherbst: I usually start nvidia-settings
12:37briocalter: imirkin_, I set PKG_CONFIG_PATH to drm/nouveau and it starts compiling
12:38karolherbst: I will try if I can disable a pstate first
12:38karolherbst: because that failed earlier
12:38imirkin_: briocalter: did you re-run configure?
12:38imirkin_: can i see your configure line?
12:38briocalter: ./configure --with-gallium-drivers=nouveau
12:38briocalter: just that
12:38imirkin_: ok, well that's not a path to good times i'm afraid
12:39imirkin_: you'll at least want --enable-texture-float
12:39imirkin_: although that's not your immediate problem
12:39imirkin_: what is PKG_CONFIG_PATH set to?
12:40karolherbst: what is the parameter again for nvafakebios?
12:40karolherbst: ahh e
12:40briocalter: PKG_CONFIG_PATH=~/drm/nouveau ./configure --with-gallium-drivers=nouveau
12:40imirkin_: what's in ~/drm/nouveau?
12:41karolherbst: hehe, as I thought, didn't work
12:41karolherbst: "Edit offset 0x7fab from 0xf to 0xff (hex, 8 bits)" should this change in a consectuvie call?
12:42imirkin_: briocalter: pastebin 'ls -lR ~/drm/nouveau'
12:42briocalter: libdrm 2.4.64 will be compiled with:
12:42briocalter: Nouveau API yes
12:42karolherbst: RSpliet: can't disable my pstate with nvafakebios :/
12:43imirkin_: briocalter: that's great. if you want my help, follow my instructions. otherwise work it out yourself.
12:43briocalter: imirkin_, http://pastebin.com/9eUKQYtY
12:43briocalter: sorry about delaying, I'm slow
12:44imirkin_: no wonder that doesn't work
12:44imirkin_: but yes, it's good enough to fool configure
12:44imirkin_: you need to 'make install'
12:44imirkin_: and point to the proper pkgconfig dir
12:44karolherbst: RSpliet: I really don't know why, but it seems like I can't change the vbios at all
12:44briocalter: I see, thanks
12:45briocalter: thought the libs would be there without installing
12:45RSpliet: karolherbst: did you verify the official driver isn't loaded?
12:46karolherbst: maybe I have some experimental signing stuff already :D
12:47karolherbst: RSpliet: if I fake the bios, load nouveau, should I get the faked bios through debugfs?
12:48imirkin_: briocalter: the pkgconfig stuff is extremely fragile. it's not just the libs, also the headers etc
12:48imirkin_: and the .pc file has all the info about where they are
12:49karolherbst: and if somebody wants, could you review this new version of the gddr5 patch? https://github.com/karolherbst/nouveau/commit/6500f51f2e1c532abcf146d0c18f3e231289ad92 mupuf
12:49karolherbst: there is now some fN handling
12:49karolherbst: and I use the correct fN value for calculating the clock I currently would generate
12:50karolherbst: so clocks should be a lot nearer to the requested one
12:50briocalter: imirkin_, it also installed on /usr/local/lib, but using LD_LIBRARY_PATH before ./configure still can't find it
12:51imirkin_: did you set the PKG_CONFIG_PATH to point to /usr/local/lib/pkgconfig?
12:52briocalter: Now I understood what you said about .pc files
12:52briocalter: they are indeed fragile
12:52imirkin_: it's basically the worst idea ever. but... i'm not going to change the world.
12:52RSpliet: karolherbst: well, there's multiple methods of fetching the VBIOS, of which nouveau picks one by heuristics
12:52karolherbst: librin: did you test my patch? here is a new version which should be tested, but it could have more bugs: https://github.com/karolherbst/nouveau/commit/6500f51f2e1c532abcf146d0c18f3e231289ad92
12:52RSpliet: perhaps optimus does mess with that particular method (probably PRAMIN)
12:53karolherbst: RSpliet: yeah
12:53karolherbst: RSpliet: how can I check how the blob fetches the vbios?
12:54briocalter: imirkin_, thanks, it did the trick, but now glxinfo is disgusted
12:54briocalter: OpenGL renderer string: Software Rasterizer
12:54imirkin_: progress ;)
12:54imirkin_: pastebin LIBGL_DEBUG=verbose LD_LIBRARY_PATH=... glxinfo ?
12:55karolherbst: RSpliet: but in theory, if I upload with PRAMIN, and nouveau looks through PRAMIN, should I see the faked bios?
12:55karolherbst: because if the vbios doesn*t change at all, what would that mean?
12:58briocalter: imirkin_, something about an undefined symbol, http://pastebin.com/nMPKQ2pp
12:58imirkin_: undefined symbol: r600_screen_create
12:58imirkin_: j'accuse xexaxo
12:59imirkin_: briocalter: could you try to do a clean rebuild
12:59imirkin_: 'make clean' followed by 'make'?
13:08briocalter: imirkin_, all is well now
13:08karolherbst: RSpliet: so is there anything I could do now?
13:09imirkin_: briocalter: cool
13:09RSpliet: karolherbst: sorry, got a bit occupied myself
13:09RSpliet: with dinner and stuff :-P
13:09karolherbst: I see
13:09librin: korolherbst, sorry, no – mesa is completely broken for me since a few hours ago
13:09RSpliet: but erm... well, technically it's possible to find out the blobs VBIOS fetching method from trace
13:09karolherbst: librin: I know
13:09librin: gotta fix that first B|
13:09RSpliet: but... it makes sense that it's not PRAMIN tbh
13:09karolherbst: librin: did you try LD_DEBUG=libs ?
13:09karolherbst: I bet you get something sha1 related
13:10RSpliet: because if they want to power down VRAM, the VBIOS would disappear :-P
13:10librin: yes – it fails on building with some unresolved sha1-related symbols
13:10librin: in osmesa
13:10karolherbst: its broken upstream
13:10karolherbst: its not your issue
13:10librin: I rebuilt it with osmesa disabled
13:11librin: which worked
13:11librin: and now OpenGL and GLX simply don't work
13:11karolherbst: this was added http://cgit.freedesktop.org/mesa/mesa/commit/?id=0db323a62481a57269a46287a64fa743756e80f3
13:11karolherbst: and http://cgit.freedesktop.org/mesa/mesa/commit/?id=04e201d0c02cd30ace5c6fe80e9f021ebb733682 broke it then
13:11karolherbst: because the latter just uses the sha1 function, allthough it can be disabled
13:11karolherbst: and is disabled for us, because we didn't enable sha1 support
13:12karolherbst: imirkin_: ping!
13:12karolherbst: as it seems everybody missed my notive in dri-devel
13:12imirkin_: no, i saw it
13:12karolherbst: you already saw
13:12imirkin_: and sarnex also mentioned it
13:12karolherbst: I bisect mesa, so I am pretty sure
13:12karolherbst: also a clean portage build is messed up
13:13librin: I am still wondering and trying to figure out why all hell breaks loose if I disable osmesa
13:13karolherbst: librin: not your fault
13:14karolherbst: librin: pass --with-sha1 to configure
13:14karolherbst: then it will work
13:15librin: the thing is, I can build it fine as long as osmesa is disabled (osmesa is not essential at all, right?)
13:15imirkin_: only if you have something that needs it...
13:15librin: after I rebuilt wine, I don't
13:17librin: and with osmesa disabled...
13:17librin: >libGL error: unable to load driver: nouveau_dri.so
13:21RSpliet: wine probably requires the 32-bit version of that
13:23briocalter: how do I know if steam is launching with the correct libGL and nouveau_dri? I got both installed on /usr/local/lib, and using LIBGL_DEBUG=verbose LD_LIBRARY_PATH=/usr/local/lib still gives me the wrong path I guess: http://pastebin.com/1MbDmJyc, pointing to /usr/lib/dri instead of /usr/local/lib/dri
13:26joi: you also need LIBGL_DRIVERS_PATH=/usr/local/lib/dri
13:26imirkin_: definitely not
13:26RSpliet: briocalter: hmm, yes, steam is a bit more tricky
13:26imirkin_: LIBGL_DRIVERS_PATH is a horrid hack
13:26imirkin_: which should never ever ever be used
13:26imirkin_: unless you REALLY know what you're doing
13:26RSpliet: I think in a games properties you can set environment variables, but let me double-check
13:26imirkin_: steam is not at all more tricky
13:26imirkin_: you just need a 32-bit build for 32-bit libraries
13:27imirkin_: er, 32-bit binaries
13:27briocalter: yes, wrong ELF class: ELFCLASS64
13:27RSpliet: imirkin_: I did struggle with steam not passing on env variables to steam to the games it starts
13:27briocalter: a configure flag prior to compiling?
13:27imirkin_: RSpliet: hmmmm.... yeah, you might be right
13:28imirkin_: RSpliet: with steam you have to set it in the game's settings
13:28imirkin_: or run the game separately from steam
13:28RSpliet: ah so you can :-)
13:28imirkin_: but either way you need a 32-bit build for a 32-bit game
13:28RSpliet: yes, that was my approach
13:28RSpliet: that too
13:29briocalter: how to build mesa with both?
13:29imirkin_: one at a time
13:29imirkin_: cna't do both
13:30briocalter: --enable-32-bit then
13:33imirkin_: briocalter: http://mesa3d.org/autoconf.html
13:33imirkin_: see the bit about cross-compiling from x86_64 to x86_23
13:34RSpliet: and you might want to toy with the library target dir (like name it lib32 instead of lib) if you want it to co-exist with a 64-bit build eventually
13:34RSpliet: or if a Red Hat derirative, have the 64-bit build live in lib64
13:36briocalter: nice, will do that
13:36briocalter: will drm request a 32bit lib as well?
13:36briocalter: mesa request a 32bit drm I mean
13:37imirkin_: the whole stack has to be 32-bit
13:37imirkin_: you can't mix and match...
13:37briocalter: do you mean all mesa dependencies needs to be 32bit?
13:37imirkin_: yeah, but you already have all that presumably
13:38briocalter: configure gave me no warnings, so let's see if it works
13:39AndrewR: hi all
13:40RSpliet: feels like helpdesk-friday all of the sudden :-)
13:41RSpliet: AndrewR: hello, and welcome to nouveau customer support. How can I help you today sir?
13:41AndrewR: I was reading emails on mesa-devel about nv3x/4x hangs, turned out to be related to multisampling ..so, I googled a bit an found this article - it claim at least high end nv3x had special compression mode for AA: http://www.anandtech.com/show/1034/5
13:42AndrewR: but other source (in russian) says low-end nv34 (fx5200) has no such machinery ...because I only have nv43 in machine nearly and nv92 in this machine ... I can only 'help' with such links, sadly.
13:43AndrewR: but I was about to ask imirkin about his re-vp2 tools, they failed to build for me ..I was hoping to debug this h264-related vdpau hang on my card ...
13:43RSpliet: now the developer working on NV3x is actually not on IRC very often
13:43RSpliet: for... reasons
13:44imirkin_: AndrewR: the nv4x?
13:44imirkin_: AndrewR: or do you have a G92?
13:45imirkin_: er right, you do. and both will hang with vdpau ;)
13:45imirkin_: how convenient.
13:45AndrewR: I have both, but currently running nv92 (pcie) in this more new and powerful machine. Old machine with AGP nv43 just unpowered currently, I need to update mesa/etc there for any test
13:45imirkin_: AndrewR: what was your question about re-vp2?
13:47AndrewR: imirkin_, guess I jus linked it to mesa soures wrong way ..or it doesn't work with new mesa..it failed to compile bsp_test.c (I supppose this block hangs first, and bring everything down ..)
13:48imirkin_: it's been a bit of a while since i've looked at it ;)
13:48imirkin_: AndrewR: what's the exact build fialure?
13:50imirkin_: change that to -I$(GALLIUM_DIR)/drivers/nouveau
13:50imirkin_: nouveau got reorg'd a bit
13:52imirkin_: well that's nice.
13:53imirkin_: you need to add some annoying things probably
13:53imirkin_: like -D_GNU_SOURCE
13:53imirkin_: or something?
13:53imirkin_: wtf is that?
13:54AndrewR: imirkin_ probably from my bling attempt to fix it. will git reset all this
13:54imirkin_: AndrewR: add -DHAVE_PTHREAD
13:54imirkin_: that should fix it right up
14:02AndrewR: imirkin_, http://fpaste.org/263788/41400530/ ..slightly different ..but still fatal
14:03imirkin_: it does include time.h
14:04imirkin_: where's timespec defined??
14:04imirkin_: ugh. sys/time.h?
14:04imirkin_: just add that include somewhere up top. not the right solution, but will get you going
14:06AndrewR: imirkin_, ok
14:08karolherbst: RSpliet: ohh I see
14:08karolherbst: so what could I do else?
14:09AndrewR: imirkin_, http://fpaste.org/263789/14009291/
14:10RSpliet: karolherbst: hmm... yeah, I don't have any particular idea atm, haven't dealt with faking VBIOSes on optimus myself
14:11imirkin_: AndrewR: -D_XOPEN_SOURCE
14:11RSpliet: (my most recent laptop has Tesla... yes)
14:11imirkin_: AndrewR: -D_XOPEN_SOURCE=700
14:13AndrewR: imirkin_ \o/ it compiled!
14:13RSpliet: ship it!!!
14:14imirkin_: RSpliet: oh, it's already been shipped
14:14AndrewR: time to hang this machine ..any way to make this hang more useful?
14:15imirkin_: AndrewR: i don't think the bsp test will hang it
14:16imirkin_: AndrewR: i suspect that decode_frame.c might
14:16karolherbst: RSpliet: how can I chech which method the blob uses?
14:16RSpliet: honestly, I have no idea... there's bound to be a few hints in the trace
14:17AndrewR: imirkin_, ok, then I need to apply same local fix to its line in makefile (I have X11 installed in non-standard location)
14:17RSpliet: I guess you can try and recognise the patterns implemented in nouveau from trace
14:17karolherbst: there are a lot of PROM thingies at the start
14:17imirkin_: at least i have the sample test frame checked in
14:19AndrewR: imirkin_, ops, i hit enter in term and it executed. No hang :} (I mean bsp test)
14:19imirkin_: did it succeed?
14:19imirkin_: what did it print?
14:20AndrewR: imirkin_ bo offset: 20019000 bo handle: 4 bo map: 0xb77c4000 deadbeef abce
14:21karolherbst: RSpliet: I guess the blob uses PROM?
14:21imirkin_: that means that the bsp software came up and is operating as expected
14:21RSpliet: karolherbst: likely
14:23briocalter: OK, cross-compiling mesa seems to not be working... nouveau_dri.so: ELF 64-bit LSB shared object, x86-64, here is my configure line: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-gallium-drivers=nouveau --enable-texture-float --build=x86_64-pc-linux-gnu -host=i686-pc-linux-gnu --libdir=/usr/local/lib
14:23RSpliet: I think you have build and host upside down?
14:23briocalter: I even tried to invert them
14:23imirkin_: RSpliet: no
14:24imirkin_: build = where you're building
14:24imirkin_: host = target
14:24briocalter: but according to the mesa page, it's fine
14:24briocalter: In order to build cross-compile Mesa on a x86-64 machine that is to run on a i686, one would need to set the options to:--build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu
14:24RSpliet: imirkin_: that is horrible
14:24RSpliet: the truth is horrible!
14:25imirkin_: you can't handle the truth!
14:25briocalter: I can't handle 32bit libs
14:26AndrewR: imirkin_, time to run decode_frame
14:26RSpliet: briocalter: this horrendously long string is in my notes somewhere
14:26AndrewR: guess it hangs partially
14:26imirkin_: oh yeah, you also need the -m32
14:27briocalter: ok, will try
14:27AndrewR: uff..it unhangs itself
14:27imirkin_: as the mesa page indicates btw
14:27briocalter: it does, I'm stupid
14:29AndrewR: imirkin_, http://fpaste.org/263795/14021281/ - terminal output
14:29RSpliet: I apologise for my slight recalcitrant behaviour btw... long week, long compile times, too much time on my hands for responding here O:-)
14:30imirkin_: AndrewR: that seems right
14:30imirkin_: it should have also written a bunch of stuff to stdout
14:30imirkin_: i.e. the decoded image
14:31imirkin_: in some crazy format that i eventually convinced either imagemagick or graphicsmagick to read in
14:31AndrewR: imirkin_ it sadly produces those errs in dmesg: http://fpaste.org/263796/02222144/
14:31imirkin_: (but definitely not both)
14:31imirkin_: that's unfortunate
14:31imirkin_: that means the vp engine went bye-bye
14:31AndrewR: imirkin_ I can't see anything after final for me line with just "3" in it
14:32imirkin_: (or bsp? i forget... one's at 00f the other is at 103)
14:32imirkin_: the 3 is normal
14:32imirkin_: that gets printed to stderr
14:32imirkin_: the image should then be written out to stdout
14:33AndrewR: imirkin_ no image for me ...should I try h264_player, or it will more completely hang vp part of card?
14:33imirkin_: no, that won't help
14:33imirkin_: that just drives the vdpau library
14:33imirkin_: while providing various additional info
14:34imirkin_: it was more convenient to use that than mplayer for RE'ing the format of things
14:34imirkin_: esp since among other things it doesn't do anything fancy, like reordering frames
14:34imirkin_: (so the video will look horrible if you ever use it, but again it's not designed for real use)
14:35AndrewR: imirkin_ I'll return in some 10-20 min - dog walk time here
14:41briocalter: oh jeez, sorry but this keeps happening: <command-line>:0:11: error: hexadecimal floating constants require an exponent
14:41briocalter: ../../src/gallium/auxiliary/draw/draw_context.h:67:5: note: in expansion of macro 'HAVE_LLVM'
14:41briocalter: while cross-compiling
14:41imirkin_: disable llvm
14:41briocalter: llvm.i686 is installed
14:42imirkin_: --disable-gallium-llvm should do it
14:42imirkin_: you don't really need it for anything
14:42briocalter: it's only for a faster compile?
14:43imirkin_: it's not really used by nouveau at all
14:43imirkin_: i guess there are a few software fallbacks for e.g. GL_SELECT or whatever
14:43imirkin_: and it would speed up those software fallbacks
14:43imirkin_: [not nouveau-specific btw... everything in mesa falls back on those]
14:46briocalter: it seems that configure fails to check many dependencies when cross-compiling
14:47imirkin_: make sure you told pkgconfig where to find things
14:47imirkin_: also your system may not be ready for cross-compiling
14:54briocalter: got some dependencies, compiled finished, steam loaded with correct libs this time
14:55briocalter: does steam passes the correct libs to games, or do I have to set them manually?
15:00karolherbst: Karlton: do you want to test this patch and tell me if the memory clock is nearer to the listed one? https://github.com/karolherbst/nouveau/commit/6500f51f2e1c532abcf146d0c18f3e231289ad92
15:01karolherbst: and if anything in stability changes
15:07karolherbst: librin: does mesa work for you now?
15:10karolherbst: RSpliet, imirkin_: do you think its worth to check also for P=2 in the PLL when fN teaking works perfectly?
15:13karolherbst: but I think the blob doesn't tweak fN if "close enough already"
15:13librin: korolherbst I tried with various --with-sha1=[something] variations, and for those that passed configure, it still wouldn't build
15:14karolherbst: librin: you have to enable shader-cache
15:14librin: didn't try rebuilding w/out osmesa again, though
15:14karolherbst: but there is a fix by imirkin_ now, but I don't htink its in the tree yet
15:14karolherbst: osmesa isn't the problem
15:15imirkin: briocalter: not sure what your question is
15:15karolherbst: librin: do you has disable-shader-cache to configure?
15:15imirkin: librin: i sent a patch, but you can also remove --disable-shader-cache
15:16librin: Yes, --disable-shader-cache is set
15:16librin: trying with --enable-shader-cache now
15:16librin: brb 10 mins
15:20Karlton: karolherbst: k, i'll reboot
15:20karolherbst: ohh wait
15:20karolherbst: there is a issue
15:20karolherbst: minor though
15:20karolherbst: I return the wrong value now
15:23Karlton: so it should still work?
15:23karolherbst: I have a fix ready in a few seconds
15:24karolherbst: Karlton: https://github.com/karolherbst/nouveau/commit/7332ae48cbf5a9154bf93e6425c5d095644cc12c
15:31librin: karolherbs, imirkin, I managed to build it with --with-sha1=libgcrypt and --enable-shader-cache
15:31imirkin: you could leave the --with-sha1 thing alone
15:31librin: and glxgears run now
15:31imirkin: it auto-detects something
15:31imirkin: out of a long list of libraries
15:31Karlton: karolherbst: strange stuff happend
15:32Karlton: gk104.c:44/magic() timeout
15:33imirkin: Karlton: which gpu do you have (pci id and subsystem pci id)
15:33imirkin: Karlton: lspci -nnv -d 10de: should tell you
15:35Karlton: karolherbst: dmesg: http://sprunge.us/GhdJ
15:37Karlton: imirkin: I don't thing I have pciutils installed or whatever the package is :D
15:38imirkin: lspci might not be in your path though
15:38imirkin: it's in /usr/sbin for me
15:38karolherbst: Karlton: uhh
15:38karolherbst: you shouldn't use my branch
15:38karolherbst: its dangerous (tm)
15:39imirkin: only the commits in your branch? :)
15:39karolherbst: I have a hack for my card in there
15:39imirkin: as opposed to all the other things in your branch :p
15:39karolherbst: and other stuff not tested enough
15:39RSpliet: how odd... my fork isn't dangerous at all.
15:39RSpliet: not until I make it compile
15:39imirkin: RSpliet: perhaps you haven't stuck it in your eye
15:39karolherbst: thre is good stuff on my branch though
15:41karolherbst: I have an idea about overclocking though: adding a new "fake" 0xfe pstate (like the booted 0xff one) and have a nice interface to configure it as you like with two "safety" modes: 1. only values according to boost table allowed. 2. all values allowed
15:41Karlton: imirkin: it's: GeForce GTX 650 Ti Boost Superclocked [3842:3658]
15:42karolherbst: 6GHz mem clock
15:42karolherbst: 5GHz is "stock"
15:42Karlton: yeah it's the OC version
15:42karolherbst: its a "normal" GeForce GTX 650 Ti Boost
15:43karolherbst: mhh stock nouveau can have a difference of 600MHz in the mem clock in the worst case scenario :/
15:44karolherbst: ohh wait
15:44karolherbst: my gpu is also overclocked already :O
15:45karolherbst: stock is 797 but my have 862
15:46karolherbst: now that I think about that, that 997MHz was pretty "cool" with that card
15:46lucas__: ok, running csgo with nouveau git freezes the system when loading a map, any workarounds?
15:47karolherbst: briocalter: does dmesg say something?
15:48Karlton: karolherbst: so do I apply your commit over the gddr5 branch?
15:48briocalter: kernel: nouveau E[ PFIFO][0000:02:00.0] write fault at 0x0000301000 [PTE] from GR/GPC2/GPCCS on channel 0x007f6da000 [Xorg]
15:48karolherbst: briocalter: which pstate are you on?
15:49karolherbst: what is inside your pstate file?
15:49karolherbst: Karlton: ohh wait
15:49karolherbst: Karlton: my master is also hackish :D
15:49karolherbst: I will create a new branch for ya
15:50Karlton: lol, whatever works best xD
15:50karolherbst: Karlton: https://github.com/karolherbst/nouveau/commits/gddr5_test
15:51Karlton: okay, and that has the latest commit in it?
15:51karolherbst: you can simply use the brach if you want
15:52briocalter: cat /sys/class/drm/card0/device/pstate shows nothing, where is it?
15:53karolherbst: briocalter: if you didn't enable it with pstate=1 it isn't there
15:53karolherbst: execpt you use my branch
15:53karolherbst: which you shouldn't ;)
15:53briocalter: ok, rebooting
15:53karolherbst: nahh wait
15:53karolherbst: dmesg should tell us this too
15:55briocalter: grepping pstate, nothing
15:55karolherbst: is there something pstate related in dmesg?
15:55karolherbst: its a little table
15:55karolherbst: skeggsb: there is no pstate table in your master branch for me, is this intentionally?
15:55karolherbst: in dmesg
15:56briocalter: nothing =/
15:56karolherbst: do you use nouveau 1.3 already?
15:57karolherbst: meh, k, then eable the pstate file
15:57briocalter: ok, brb
15:58Karlton: karolherbst: the clocks are closer now :D "0f: core 549-1293 MHz memory 6008 MHz AC DC *" "AC: core 1293 MHz memory 6007 MHz"
15:58karolherbst: okay, nice
15:59karolherbst: then it seems to work somehow
15:59karolherbst: you could do some stability tests now if you wnat
15:59karolherbst: you card is pretty overclocked :/ its a bit too high if you ask me
16:00briocalter: karolherbst, http://pastebin.com/8Tacwxq4
16:01karolherbst: briocalter: okay, seems okay
16:01karolherbst: Karlton: 980 is stock clock
16:01karolherbst: but you have 1293
16:01karolherbst: this is a bit intense
16:01RSpliet: karolherbst: nah, that's pretty normal
16:01karolherbst: core clock?
16:01RSpliet: cherrypicking the best chips
16:01karolherbst: yeah, well
16:01karolherbst: 1GHz is pretty high already
16:02karolherbst: at least for 6xx cards
16:02RSpliet: yes, I'm not shocked though...
16:02karolherbst: it still could be a voltage problem he has
16:02karolherbst: maybe voltage too low?
16:04karolherbst: RSpliet: do you know the kepler voltage reg?
16:04RSpliet: nope,never had a good look at anything newer that Tesla
16:05karolherbst: at least I know he has no PWM voltage thingy as I have
16:05karolherbst: Karlton: nvapeek 0x20344 was empty for you, right?
16:05karolherbst: I guess so
16:05RSpliet: (ergo: the old-school way?)
16:05karolherbst: yeah old school
16:05karolherbst: never touched the old-school way
16:06Karlton: karolherbst: yes
16:06Karlton: I loaded flightgear but it loaded very slowly and then hung
16:06karolherbst: Karlton: it could be, that the core voltage is too low for you :/
16:06karolherbst: ohhh wait, we could try something
16:07karolherbst: I will push a lot more stuff into a branch and then we retry with lower core clocks
16:07karolherbst: if you are up to
16:07Karlton: sure :D
16:08karolherbst: Karlton: do you have some voltage error in dmesg?
16:08karolherbst: when changing to 0f pstate
16:09karolherbst: Karlton: please use this branch now:https://github.com/karolherbst/nouveau/commits/karlton_test
16:09Karlton: karolherbst: no
16:10karolherbst: the file locations are different and there will be something new as well, you should compile on that branch and then reboot
16:11karolherbst: RSpliet: by the way, the pstate table says that 405MHz is the lowest clock, but boost table says 135MHz and the blob also uses the latter
16:11karolherbst: any good idea to solve this?
16:11karolherbst: nouveau uses 405 obviously
16:13karolherbst: RSpliet: lowest cstate is also 405
16:14RSpliet: no idea
16:14karolherbst: ohh my boost table is messed up anyway
16:15karolherbst: I think this is a vbios issue
16:15RSpliet: I just wrestled my way through a pile of compiler errors... time for phase two: nullptr derefs
16:15karolherbst: I already was there
16:15karolherbst: ohh by the way
16:15karolherbst: I may have something
16:15RSpliet: it's a good motivation to push early, push often etc etc
16:15karolherbst: RSpliet: https://github.com/karolherbst/mesa/commit/858ad081bd709727fd07a196db9fe9593cb39c3a
16:16karolherbst: does this patch looks okay to you?
16:16karolherbst: I got some memory coruption inside the hi/lo list
16:16karolherbst: Karlton: ready?
16:17Karlton: karolherbst: is /sys/class/drm/card0/device/pstate suppose to be missing?
16:17Karlton: okay, ready then
16:17karolherbst: its there now
16:18RSpliet: karolherbst: idk, I don't know what hi and lo are (apart from dlls)
16:18RSpliet: and what their scope is
16:18karolherbst: I see
16:18karolherbst: I got issues only if the first RA try failed
16:18karolherbst: the lists got a bit messed up then
16:19Karlton: karolherbst: oh perhaps I need kernel debugging on? xD
16:19karolherbst: only debugfs mounted
16:19Karlton: its not mounted :/
16:19karolherbst: mount /sys/kernel/debug
16:20karolherbst: if that doesn't work try mount -t debugfs none /sys/kernel/debug
16:21Karlton: karolherbst: okay, that worked
16:21RSpliet: karolherbst: if I understand it correctly; the GCRA object is re-used when the first RA try fails...
16:21karolherbst: RSpliet: yes, but some memory inside that list got overwritten with 0x0
16:22karolherbst: which lead to the strange effect, that the memory corpution didn't trigger with valgrind
16:22karolherbst: Karlton: okay there should be a pstate and cstate file now?
16:23Karlton: karolherbst: yes
16:23karolherbst: then go to 0f pstate
16:23karolherbst: and give me the content of cstate
16:23RSpliet: right, mmm... imirkin probably knows better, but after failure it's going to retry with different constraints. I'd personally prefer to do that upon initialisation rather
16:23RSpliet: and I think there are initialiser macros for DLLs
16:24imirkin: what would i know better?
16:24karolherbst: imirkin: the fix you told me about
16:24karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/858ad081bd709727fd07a196db9fe9593cb39c3a
16:24RSpliet: imirkin: whether this makes sense: https://github.com/karolherbst/mesa/commit/858ad081bd709727fd07a196db9fe9593cb39c3a
16:24karolherbst: it was imirkins idea ;)
16:24karolherbst: I just thought you were more into RA than imirkin is
16:24imirkin: yes, that makes sense to me
16:24RSpliet: actually no, I'm just the reclocking chap
16:25imirkin: otherwise hi/lo refer to nodes you just deleted
16:25Karlton: karolherbst: http://sprunge.us/LFLY
16:26RSpliet: imirkin: are there no initialise macro's for these lists?
16:26karolherbst: Karlton: k, mhh let us just try lower core clocks
16:26karolherbst: echo 10 into cstate
16:26imirkin: RSpliet: mmmmaybe. they are somewhat custom lists
16:26karolherbst: then cat pstate to verify that the core clock is lower
16:26imirkin: RSpliet: since the classy thing is for everyone to create their own custom list impl
16:27imirkin: instead of reusing one thing among everyone
16:27karolherbst: everyone knows best
16:27RSpliet: that's why we have so many awesome bikesheds in this world
16:28karolherbst: but lists are the lesser problem
16:28karolherbst: there is much worse
16:28karolherbst: Karlton: I hope your kernel didn't segfault :/ these commits are really badly tested
16:29imirkin: karolherbst: did that patch help anything?
16:29Karlton: karolherbst: it didn't segfault
16:29karolherbst: imirkin: yeah
16:29imirkin: karolherbst: excellent
16:29karolherbst: but not with the other segfault
16:29karolherbst: as I said, I had two issues
16:30imirkin: can't win 'em all
16:30karolherbst: I know
16:30imirkin: at least not with a single patch
16:30karolherbst: Karlton: oaky
16:30karolherbst: Karlton: and core clock is much lower now?
16:30karolherbst: should be something around 750MHz
16:30Karlton: yeah, AC: core 757 MHz
16:30karolherbst: then try to play something
16:31karolherbst: imirkin: I think the other fix will go away when I schedule a bit smarter
16:32Karlton: karolherbst: flightgear is working so far
16:32karolherbst: imirkin: have a hacky fix for it though
16:32karolherbst: Karlton: nice
16:32karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/206fd758836dd2459a137befc17c57d982f813f4#diff-70ffabf33cc5a58af0db0774e917b125L1726
16:32karolherbst: and below
16:32karolherbst: with that it kind of works
16:34karolherbst: I know
16:34imirkin: the fact that reg.id == -1 is really bad
16:34karolherbst: I think it tries ti spill stuff inside the merge instructions
16:34karolherbst: but the core isn't written against that
16:34karolherbst: Karlton: if you want, you can slowly increase the core clock until it crashes
16:35karolherbst: just increase the umber you echo into cstate
16:35karolherbst: you should get how to use that interface
16:35karolherbst: sooo big conclusion: memory clock isn't the only reasons 0f fails, but core clock or core voltage as well :/
16:37Karlton: karolherbst: should I just increment by 1 while flightgear is running?
16:37karolherbst: Karlton: yeah
16:37karolherbst: Karlton: I have an asumption though
16:37karolherbst: Karlton: 25 will work fine
16:37karolherbst: somehwere after 26 it will hang
16:37Karlton: okay ...
16:38karolherbst: there is this big gap between 25 and 26 which worries me
16:39karolherbst: its also near the "stock" 650 clock, 24
16:39karolherbst: and 25 is unusually high
16:39karolherbst: I meant 25 is fine, but 26 is a bit high
16:40Karlton: sucks that flightgear is cpu bottleneck with cpu0 at 100% xD
16:41karolherbst: Karlton: you could build your mesa with -O3 and debug stuff disabled
16:41karolherbst: could help
16:41karolherbst: Karlton: at which value are you currently?
16:42Karlton: 17 and smooth
16:43imirkin: Karlton: it definitely can spill merges, and it should def handle it
16:43imirkin: er, karolherbst --^
16:45Karlton: going to 25...
16:48karolherbst: Karlton: 25 or 26?
16:49Karlton: karolherbst: yeah 26 was the killzone
16:49karolherbst: so you should have a voltage problem too
16:49karolherbst: I guess mupuf is the guy for that
16:50RSpliet: well, I wouldn't count on that
16:50RSpliet: he's a bit busy I believe
16:50karolherbst: yeah I know :/
16:50karolherbst: but he said he may have time this weekend
16:50mupuf: I will, I have no plans...
16:50karolherbst: mupuf: Karlton has a core clocking instability
16:50mupuf: that;s a first in ... 3 months?
16:50karolherbst: these are his cstate: http://sprunge.us/LFLY
16:50mupuf: I guess the summer is over, right!
16:50karolherbst: up to 25 its stable
16:50karolherbst: 26 hangs card
16:50RSpliet: not for another three weeks
16:51karolherbst: mupuf: do you see this big core clock gap?
16:51RSpliet: two... and a little
16:51mupuf: RSpliet: it is over, here
16:52mupuf: saturday was the end. It is night at 9, it feels weird after having constant light during the summer
16:52karolherbst: Karlton: what you could do is, to ran at 0f pstate and 25 cstate and check how stable the gpu is in general
16:52karolherbst: does ot hang after an hour
16:52karolherbst: or a day
16:52karolherbst: or whatever
16:54Karlton: karolherbst: okay, I will do that after I go AFK for a few minutes
16:54karolherbst: no problem
16:54karolherbst: mupuf: it seems like we can't trust the cstate table fully with the voltage value
16:55karolherbst: but Karltons card is around 300MHz overclocked by producer
16:55RSpliet: what about comparing the PLL values?
16:55karolherbst: RSpliet: of the clock?
16:55karolherbst: never done that
16:55karolherbst: but do you think PLLs are the issue here?
16:56karolherbst: it really smells like a voltage issue
16:56RSpliet: it's a back-up plan
16:56karolherbst: yeah, right
16:56karolherbst: mupuf: how does one increase voltage through GPIOs on kepler?
16:56karolherbst: I mean with nvapoke
16:57karolherbst: ohh we could simply compare voltage on blob and nouveau
16:57karolherbst: should be easier than messing with voltage
17:19Karlton: karolherbst: okay, I am back at 25 again
17:31karolherbst: Karlton: okay, you can if you want just run the system at this speed
17:31karolherbst: ohh also
17:32karolherbst: what is the speed of your 0a pstate?
17:36Karlton: I think it reports the same as 0a: core 324-862 MHz memory 1620 MHz
17:37Karlton: pretty sure, I know the mem clock was the same
17:41karolherbst: there shouldn*t be any difference
17:41karolherbst: I just wanted to know if the 25th cstate is still faster
17:42karolherbst: its faster, so its okay
17:43Karlton: yesh 25th cstate at 0f is AC: core 953 MHz memory 6007 MHz
18:37briocalter: any idea what this could be? kernel: nouveau E[ PFIFO][0000:02:00.0] write fault at 0x0000301000 [PTE] from GR/GPC2/GPCCS on channel 0x007f6da000 [Xorg], trying to load a map on csgo with mesa git
18:37briocalter: would an apitrace help?
18:40karolherbst: briocalter: could be the same as Karlton, but with your low clock I hardly believe that
18:40karolherbst: there are many reasons this issue can happen
18:40karolherbst: you could try if another pstate helps
18:41briocalter: wouldn't it become more unstable?
18:41briocalter: I've seen other games hanging the card as well
18:42karolherbst: briocalter: deoends
18:42karolherbst: the highest is currently unstable on gddr5
18:42karolherbst: but something lke 0a should be fine
18:42karolherbst: maybe the boot configuration of the card is just messed up
18:42karolherbst: and setting to lowest pstate already helps
18:43karolherbst: are there any other "issues" in dmesg?
18:45briocalter: none related to gpu
18:45karolherbst: then you could try to set a pstate explicitly
18:46karolherbst: 07 or 0a should usually work nicely
18:46karolherbst: maybe 07 is also strange for you
18:46briocalter: should I mess with voltage? On boot, GPU voltage: 987500uv
18:46karolherbst: no, its fine
18:46karolherbst: if you set the pstate, the voltage should be set to the right value
18:54karolherbst: Karlton: how is it going until now?
18:56briocalter_: same thing, kernel: nouveau E[ PFIFO][0000:02:00.0] write fault at 0x0000301000 [PTE] from GR/GPC2/GPCCS on channel 0x007f6da000 [Xorg]
18:57briocalter_: fps has gone up on the game menu
18:57briocalter_: but still freezing when loading a map
18:57Karlton: karolherbst: no problems so far
19:01marcosps1: hi guys :)
19:02karolherbst: briocalter_: okay, so the issue is most likely something else
19:02briocalter_: karolherbst, anything that I can do to investigate this further?
19:03karolherbst: I have no other clue
19:03karolherbst: you could try with newest software though
19:03karolherbst: newer noveau DDX, newer mesa, newer kernel
19:03karolherbst: Karlton: okay, nice
19:03briocalter_: got kernel 4.1.6, mesa git
19:04karolherbst: briocalter_: have no idea otherwise
19:05karolherbst: briocalter_: you could try to set to lowest settings and check if one specific combinatio of settings triggers it
19:05briocalter_: sad that the error message doesn't help
19:05karolherbst: marcosps1: hi
19:05briocalter_: karolherbst, I'm on all low already
19:07briocalter_: a bug report on valve won't help, I guess it won't help on mesa either
19:07karolherbst: the pain is, its really hard to tell
19:07karolherbst: maybe there are other games with a smiliar issue?
19:08marcosps1: imirkin: around?
19:09briocalter_: yea, I could gather some games that hangs as well, but they all have non-helpful messages on dmesg
19:10karolherbst: briocalter_: would be nice to have a game which only hang with a special configuration
19:10briocalter_: I see
19:10briocalter_: will try to find one
19:13marcosps1: Guys there is anybody here who can tell help me on envydis? I need to verify how to check if the operation is s double immediate in nvc0 emitter..
19:15marcosps1: Right now I'm hitting an assert becouse the oce only validates int, long and float, and I need to adapt it to double. imirkin said to me that I can use envydis to check how the encoder works, but, quite frankly, envydis is confusing for a newcomer :)
19:48karolherbst: this sucks
19:48karolherbst: if (req_speed > max_speed); req_speed = max_speed; ....
20:19briocalter: karolherbst, got dota2 hanging on mesa git as well
20:19briocalter: some different errors now http://pastebin.com/gzPNwGtV
20:21briocalter: karolherbst, got dota2 hanging on mesa git as well: http://pastebin.com/gzPNwGtV
20:30marcosps1: briocalter, karolherbst: Is Dead Island a game who needs OpenGL 4 to run...? If this is true, so I'll try to cross compile mesa to 32bit, since the game in steam is a 32bit one :P