00:02imirkin: anyone around with a kepler and debug mesa build?
00:02imirkin: (and piglit)
00:04karolherbst: imirkin: usually me
00:04imirkin: karolherbst: mind doing NV50_PROG_DEBUG=1 bin/fbo-stencil blit GL_DEPTH32F_STENCIL8 -fbo -auto
00:04imirkin: and pastebinning the output?
00:04karolherbst: okay, wait a moment
00:04karolherbst: imirkin: current mesa master?
00:05imirkin: doesn't really matter
00:05karolherbst: I see
00:05imirkin: something from the past 3 months or so might be nice
00:11karolherbst: ohh my, forgot to build my mesa with debug... will change that
00:18karolherbst: imirkin: https://gist.github.com/karolherbst/b91c9de1e10e30dc948e
00:19imirkin: karolherbst: i assume it passed?
00:19imirkin: you didn't have that last line...
00:19karolherbst: I would have complained otherwise
00:20imirkin: exxxxtremely odd
00:20karolherbst: what are these "empty" binaries by the way?
00:20karolherbst: I sometimes saw them but never figured what they are for
00:20imirkin: one of them is the tcp
00:21imirkin: another is, apparently, an empty frag shader
00:21imirkin: dunno how that happens
00:21karolherbst: I saw that sometimes too
00:22karolherbst: but is there any issue?
00:22imirkin: it does look as though it tries to draw with it
00:23karolherbst: I find the resulting FRAG a bit odd
00:24imirkin: it's a blit shader
00:24karolherbst: I mean, I don't see why there should be another bb?
00:24imirkin: for some reason i have to shift the stencil value over 24 bits on fermi
00:24imirkin: the end stuff is always in a separate bb
00:24imirkin: so that it's possible to jump to it
00:24karolherbst: ohh okay
00:25karolherbst: and what does "-> BB:1 (tree)" stand for?
00:25karolherbst: I think I have to somehow learn what this representation means :)
00:26imirkin: there is an outbound edge to BB:1
00:26imirkin: and it's a tree-type edge
00:26imirkin: the idea is that you build up an MST of the cfg
00:26imirkin: and all the edges that belong to the MST are tree edges
00:27imirkin: the rest are forward, back, or cross edges
00:27imirkin: unfortunately nv50 ir doesn't really keep to these proper definitions
00:27imirkin: but on the bright side, very little relies on edge type
00:28karolherbst: somehow I get the feeling I should learn a bit more about compilers and stuff
00:28imirkin: and i get the feeling that fermi and kepler represent Z32_S8 differently in memory
00:29karolherbst: does the test fail on fermi?
00:29imirkin: and i fixed it by up-shifting the stencil value
00:29imirkin: by 24
00:29karolherbst: sounds annyoing
00:30karolherbst: is it the first tgsi or the second?
00:30karolherbst: I meant, is it the vert or the frag program=
00:30imirkin: is what?
00:31karolherbst: which causes the issue
00:31imirkin: that's where the sampling is done
00:31karolherbst: I also have no clue about how OpenGL works
00:31karolherbst: just so that you know
00:31imirkin: a 3d-engine-based blit is basically texturing the source rect over the destination rect
00:32imirkin: everything i know about (modern) GL, i learned through hacking on nouveau
00:32karolherbst: just a question: does fermi has something like texbar or is tex synchron there?
00:33imirkin: no texbar on fermi
00:33imirkin: no sched either
03:12pmoreau: Let's learn what EXT_TAG is, now that I found it in the PCI spec. :-)
03:39karolherbst: pmoreau: yay :)
03:40pmoreau: So: if ext_tag is disabled, the number of "outstanding requests per function" should be limited to 32, so disabling bits 6 and 5 means only 4:0 are set => max value = 31
03:41pmoreau: ext_tag disabled means 5-bit tag field, and ext_tag enabled => 8-bit tag fields
03:44karolherbst: pmoreau: and what kind of outstanding requests?
03:45pmoreau: those "that require a completion for that requester" :D
03:46karolherbst: ahh this part
03:46karolherbst: ohh right, I remember now
03:47karolherbst: you can do like two kinds of requests on the bus
03:47karolherbst: one where you care if the request was sent and a one where you not care
03:49karolherbst: pmoreau: there is this nvkm_pci_init function inside nvkm/subdev/pci/base.c
03:49pmoreau: Yep, I edited my patch and put it in it
03:49karolherbst: do you have a check with pci_is_pcie ?
03:50pmoreau: And it is run when the card is resumed, which is great! :)
03:50pmoreau: I don't
03:50karolherbst: this function is called for like every card
03:50karolherbst: even nv04 based ones
03:51karolherbst: I don't know how the stuff works on AGP cards bridged on pcie
03:51pmoreau: Oh right, I should check that
04:32pmoreau: Sorry skeggsb for the double mail... I had forgotten I change my e-mail address, so I could cancel while it was waiting for moderation, but the new one is greylisted... --"
04:39pmoreau: Oh, cool, the new address did work in the end. :)
05:07pmoreau: l1k: Just tested your branch: I got a lot of "BUG: scheduling while atomic: modprobe/488/0x00000002"
05:07pmoreau: Paste incoming
05:19pmoreau: l1k: https://phabricator.pmoreau.org/P20
05:20pmoreau: CPU usage for Xorg is still at 100%. I'll try to get some info, but with all the "BUG: scheduling while atomic", it will be somewhat more difficult.
05:22l1k: pmoreau: OMG sounds awful, will have a look right away...
06:24l1k: pmoreau: most likely this is because I changed vgasr_mutex to an rwlock, which is a spinlock. the messages should disappear if you remove the read_lock() and read_unlock() in vga_swichteroo_lock_ddc() / _unlock_ddc() / _get_ddc() / _put_ddc() / _get_aux() / _put_aux(). this issue never showed up on my machine probably because it has more CPUs (8 hyperthreaded cores instead of 2 physical on your machine). looks like I need to change from rwlock to somethin
06:24l1k: else, question is what. I need something with the semantics of rwlocks which is not a spinlock.
06:24l1k: pmoreau: in any case thanks for testing and reporting this.
06:26pmoreau: You're welcome
06:28pmoreau: I have some logs while running X
06:28pmoreau: Just need to truncate them a bit
06:39pmoreau: l1k: https://phabricator.pmoreau.org/P21
06:41pmoreau: Meh... Not really readable. But this nouveau_connector_detect are happening really often
06:46karolherbst: anybody want to review/test my pcie stuff? (working on kepler+ currently)
06:49mupuf: karolherbst: sure
06:49mupuf: I can do that today
06:49karolherbst: mupuf: commits are here: https://github.com/karolherbst/nouveau/commits/pcie_speed
06:49mupuf: btw, header + 5 (32 bits) is apparently the frequency of the PWM we should set
06:50mupuf:is figuring out the formula as we speak
06:50karolherbst: in the table?
06:50mupuf: voltage table, yes
06:50karolherbst: the value is 03 for me
06:50mupuf: I said 32 bits :p
06:51mupuf: 03 88 2a 11 --> 288 MHz
06:52karolherbst: yeah, that makes sense
06:52mupuf: it seems dody though, it is SUPER fast
06:52karolherbst: a little
06:52mupuf: and apparently, the duty is not allowed to go over 0xff
06:52mupuf: err, dv
06:52mupuf: the blob says fuck after that
06:54karolherbst: mupuf: maybe its header +6 and the 03 is another flag?
06:54karolherbst: this 03 bugs me
06:54mupuf: I am sure of it, changing the value as a 32 bit integer changes the div linearly
06:55karolherbst: I see
06:55karolherbst: still, this 03 bugs me :D
06:55mupuf: yeah, I know :D
06:55mupuf: but it is ok :p
06:56mupuf: funny thing is, if the frequency really is in Hz, then we would need an input clock at 27.616 GHz
06:57mupuf: the 27 here is important, because 27 MHz is the frequency of the crystal
06:57mupuf: so there is a factor of 1000 here that I cannot explain
06:57mupuf: so, maybe the unit is simply mHz
06:57mupuf: but who would do that? That is ridiculous
06:57karolherbst: but why 27GHz?
06:58karolherbst: I mean, where does the 27 come from
06:58mupuf: oh, When I ask for a frequency of 108300000 (no unit), I get div 0xff
06:58mupuf: so, 108300000 * 255 = input frequency
06:58karolherbst: ohh * 0x60, got it
06:58mupuf: and that is WWAAAAYYY too big
06:59karolherbst: ohh well
06:59mupuf: 0x60 * 288000003 = 27 648 ..... again
06:59mupuf: it really is linear
06:59mupuf: this 648 is weird
07:01mgottschlag: mupuf: http://www.digikey.de/product-detail/de/ABM3B-13.824MHZ-B2-T/535-9119-1-ND/675636 <- might be a standard frequency
07:02mgottschlag: that's a crystal of half that frequency
07:03mupuf: mgottschlag: yes, it is indeed standard
07:03mupuf: but we never had this precision before in the computation
07:03mupuf: let me check
07:03mgottschlag: ah, okay
07:04mupuf: yeah, we always used 27MHz
07:04mupuf: well, maybe there is a separate crystal
07:05mgottschlag: but at least 27.648 is plausible
07:05karolherbst: mupuf: is the stuff inside the chip or on the board?
07:05mupuf: the fact that 27.648MHz is a standard frequency will be enough for me :)
07:05mupuf: on the board, likely
07:05mupuf: it is possible that the voltage regulator would be providing this freq
07:05mgottschlag: crystals are usually discrete
07:05mupuf: you know, I am tempted to open the case of the maxwell and have a look
07:05karolherbst: I could look on my card too
07:05karolherbst: its a MXM card, so
07:06karolherbst: I don't have to open anything :D
07:06karolherbst: no thermal paste ....
07:06karolherbst: I dunno
07:06karolherbst: maybe its on the top side, then I would see that
07:06mgottschlag: usually on the opposite side from the chip
07:07mgottschlag: because the wires should be as short as possible
07:07mgottschlag: (but not necessarily)
07:08mupuf: karolherbst: don't do it on your board
07:08mupuf: worst case scenario for me, I do not have a maxwell but I still have a ton more gpus :p
07:09mupuf: for now, I will say that the value is stored in mHz
07:09mupuf: and the input clock is 27.648 Mhz
07:10karolherbst: I just wanted to check if there is somethinng on the top side
07:10mupuf: maybe the 03 actually means something though
07:10karolherbst: didn't intented to remove the heatsinks again
07:10mupuf: hence why they would store as mHz
07:12mupuf: no changes
07:12mupuf: I will need more evidence to consider this again
07:12RSpliet: mupuf: wait... is this serious; 27.648mHz == 27 miHz :-D
07:13mupuf: RSpliet: What the heck is happening to you :D?
07:14mupuf: shit, you are right :D
07:14karolherbst: mupuf: you should rather ask what the nvidia engis are doing
07:15mupuf: well, it would seem that the crystal is 27 MiHz
07:15mupuf: RSpliet: freaking good catch :D
07:15karolherbst: I always thought, that somebody at nvidia intentionally lays traps inside the bios or somewhere, just to screw with nouveau devs
07:15mupuf: sometimes, I think the opposite :p
07:15mupuf: But I doubt they care about us
07:15RSpliet: mupuf: not that it *actually* makes sense to multiply by 1024 :-D
07:16mupuf: sometimes, they simplify the design of stuff
07:16mupuf: well, it makes it easy to compute time in decimal
07:16mupuf: you can use a divider by 2
07:16mupuf: it is common in watches
07:17mupuf: well, two more fields and we should be done with the REing!
07:18mupuf:is very hopeful, too much for reality probably
07:18karolherbst: which are missing?
07:18mupuf: well, we know how to compute divs
07:18mupuf: but not how to compute duty based on the wanted voltage
07:19mupuf: are we having fun yet? :D
07:19karolherbst: ohh, I think its something linear to the clock at least, doesn't have to be directly, but who knows
07:20mupuf: right now, I have two fields, set to 0.6V
07:20mupuf: and changing them changes the duty
07:20karolherbst: ohh right, these
07:21mupuf: if we had a linear thingy, we would get 0.6V and 1.2V, probably
07:21mupuf: and then interpolate for the duty
07:21mupuf: but no, we get something else
07:40mupuf: what the heck
07:40mupuf: good that I wrote a program to iterate through a lot of the value for offset 18
07:40mupuf: it is linear ... but not really :D
07:41mupuf: there are saw-tooth
07:41mupuf: I am testing more values
07:41mupuf: and we will see!
07:47mupuf: What the flying fuck?
07:48karolherbst: ? what did you found?
07:48mupuf: this saw-tooth function really is weird
07:49mupuf: I mean, it keeps going from value a to value a + 10
07:49mupuf: once every two times
07:49mupuf: looks like there are more than one value in this number
07:50mupuf: but ... but ... I keep putting smaller and smaller increments, but I keep getting this saw-tooth
07:50mupuf:is happy he went to bed 12h and did not start ooking into this
07:53mupuf: I wonder if it is a bug or not
07:59mupuf: ok, so it may be because I was going too fast :D
08:00mupuf: now, I reset the value after the blob finishes
08:00mupuf: but it would seem like the original value set by the bios is taken into consideration in the computation
08:02karolherbst: that would also fit with my observation
08:19tobijk: do we have fixes for xf86-video-nouveau to build against xserver 188.8.131.521?
08:34mupuf: karolherbst: http://fs.mupuf.org/mupuf/nvidia/UN18_UNK22_duty.png
08:34mupuf: if this is not linear, then I am a monkey :D
08:34pmoreau: Nice graphic! ;)
08:35mupuf: pmoreau: my drawing skills are impressivem right?
08:35imirkin: tobijk: what's the build error?
08:36pmoreau: mupuf: Absolutely amazing!
08:36imirkin: mupuf: it's really your patience in collecting data that's the amazing bit
08:37mupuf: imirkin: bash scripts FTW
08:37mupuf: I still hate bash though
08:38mupuf: and then 2 for loops outside
08:38mupuf: or just one, depends on what you want to do
08:39mupuf: I just love nvafakebios :p
08:39mupuf: it was one of my first tool
08:39mupuf: xexaxo used to do it by hand IIRC
08:39mupuf: and I was waaaaayyyy too lazy for that
08:40mupuf: same for getbios
08:43l1k: pmoreau: Xorg is constantly calling DRM_IOCTL_MODE_GETCRTC, I have no idea why. xf86-video-nouveau only calls this once in src/drmmode_display.c:drmmode_crtc_init(), there's no loop that would explain why this is called over and over again. so it looks to me like the ioctl calls are not originating from xf86-video-nouveau but something else. I don't know what that could be.
08:46mupuf: funny how forgetting a 0 leads to an instant crash :p
08:48pmoreau: l1k: Could it be due to the reprobe?
08:49RSpliet: I used to do it by hand yes...
08:49RSpliet: you learn important lessons from doing so
08:50RSpliet: like... how important it is to write tools
08:51RSpliet: even if they are disposable toys
08:55tobijk: imirkin: look at the end here: https://build.opensuse.org/build/home:tobijk:X11:XOrg:Unstable/openSUSE_Factory/x86_64/xf86-video-nouveau/_log
08:56tobijk: some glamor related stuff
08:56imirkin: i know how to fix THAT problem!
08:56imirkin: (i.e. remove glamor)
08:56imirkin: ben said he was cool with my patches
08:56l1k: pmoreau: if these errors do not show up without my patch set, then I would guess that Xorg or the desktop environment gets confused because it is now seeing connectors with modes on two GPUs while without my patch set it was only seeing that on one.
08:57tobijk: imirkin: heh, then do it and when you are at it, release 1.0.12 :)
08:59tobijk: imirkin: did you find time to see what was wrong with the patch i (re)posted yesterday?
08:59imirkin: tobijk: you didn't repost it... you provided a link to it :p
09:00imirkin: that's a great way to get me to forget about a patch... use email.
09:01tobijk: mhm i have remvoed my email conversations, i'd be nice if you could find it
09:02tobijk: for that patch then
09:02l1k: pmoreau: what panel modes does the VBIOS contain on the two cards? are there any modes at all? because you wrote that without the patch set, the screen turns black if you switch. this means that one of the cards is using the wrong mode. either it has none or it is not the proper 1440x900.
09:03l1k: pmoreau: the difference is that if you apply the patch set, the inactive card will see the proper mode, either by asking gmux to switch the DDC lines or by using the other card as a proxy.
09:03pmoreau: l1k: The screen doesn't turn back without the serie, but it has the default 1024x720 or whatever default resolution in console mode; with X, it gets the correct mode.
09:04l1k: hm, I'm wondering where X gets the proper mode from.
09:06pmoreau: Let me check in the VBIOS
09:07l1k: if you boot with drm.debug=0xf it will also report the modes it found
09:09l1k: in the log you posted it seems that the 9600M GT is recognized first, then the 9400M. so the panel is probably initially switched to the 9600M GT on boot
09:11pmoreau: Right, but the 9600M GT goes like: no connector found, going to default
09:12imirkin: joi: doing some, uh, testing? :)
09:12joi: yeah ;)
09:13imirkin: joi: i kinda like the nouveau version better :)
09:14joi: that was also my impression when I compared those screenshots
09:14imirkin: does it happen *without* the patch as well?
09:14imirkin: i.e. is it a bug in my patch, or just a bug
09:15imirkin: coz there's a bit of dodgy stuff going on in that patch... it's not quite right
09:16tobijk: imirkin: there you gp :P
09:16imirkin: tobijk: thanks
09:17joi: heh, I wanted to compare with software rendering but it's half an hour and it's still on loading screen...
09:17tobijk: joi: hope you are running it with 640x480 or such low resolution :D
09:18imirkin: joi: yeah don't worry about that... but do try it without my patch. and yeah, lower res makes tests go much faster.
09:19night199uk: my custom UEFI GOP driver powers up my monitor finally :-)
09:19night199uk: though ‘mode not supported'
09:20imirkin: night199uk: progress :)
09:20night199uk: hehe, yeah
09:20imirkin: night199uk: i assume you're just doing VGA or DVI right?
09:20night199uk: DVI right now
09:20night199uk: but I can plug in via HDMI instead
09:20night199uk: actually good point, let me try HDMI
09:20imirkin: no, DVI is easier.
09:20night199uk: oh yeah?
09:21imirkin: you have to write more registers for hdmi
09:21night199uk: well, in theory all the code is there
09:21night199uk: i’m just bug fixing now
09:21imirkin: did you just import nvkm?
09:21night199uk: its a reverse of the nvidia gop driver
09:22night199uk: i just use nouveau for a lot of ideas & guidance :-)
09:23night199uk: do you have any ideas which regs are mainly involved in DVI?
09:23night199uk: i need to start looking now how to troubleshooting this ‘mode is not supported'
09:23night199uk: (from my samsung monitor)
09:23night199uk: ideally if i knew what the monitor thought it was receiving it was be easier to find the erroneous code on the nvidia side
09:23imirkin: yes, that would be ideal
09:24night199uk: i’m sure it won’t be that simple
09:24imirkin: is there an efi log you can log to?
09:25night199uk: i can dump all the reg writes/read if it would make sense to you and you be interested in a look
09:25imirkin: you should (a) make sure you read the EDID correctly
09:25imirkin: and (b) print out what timings you're programming
09:25night199uk: EDID is read correctly, but the timing calcs are incredibly complex right now
09:25night199uk: and I’m not sure i know where they all are yet
09:25imirkin: they should be very simple
09:25night199uk: unfortunately not
09:25imirkin: "take timings from edid, add/subtract a couple things, program"
09:26night199uk: i wish
09:26night199uk: because in nvidia they translate between a few formats for expressing the mode timings
09:26night199uk: its a top half/ bottom half model - the top half of the driver reads the EDID and converts it into a modeline expressed in a similar format to an X86 modeline
09:27night199uk: and the bottom half takes that format and converts it back out into a different timing format
09:27joi: imirkin: your patch from bug 91890 do not affect Shadow Warrior
09:28imirkin: joi: ok, thanks for checking
09:28night199uk: imirkin: yes, something like this i expect :-)
09:28night199uk: imirkin: this looks very similar. let me take a look at this
09:28night199uk: and, when reversing a lot of those divides get optimized on intel so its much harder to work out what they really do
09:28imirkin: night199uk: the GF110_DISP_BLA thing is actually a misnomer. it starts with GF119, not GF110
09:28night199uk: sec, let me compare this to what I hae
09:29imirkin: dunno what GPU you have
09:29night199uk: do you know if there are names for the different mode timing formats?
09:29imirkin: not sure what a "mode timing format" is
09:29night199uk: I have GF108 here right now (fermi), and some others for later testing when this one works
09:29imirkin: ok cool, so you want the < GF110 path
09:29night199uk: well, by mode timing format i mean
09:30night199uk: in EDID we get vertical active, horizontal blanking, horizontal sync offset, et
09:30night199uk: i.e. something like, 640, 45, 22, etc
09:30night199uk: although i forget the real numbers
09:31night199uk: but in the driver internally they use/accept timings in more of an XF86 modeline format
09:31night199uk: i.e. front porch, back porch
09:31night199uk: so e.g. 640, 680, 701, etc
09:31night199uk: i’m not sure if there are better names for these
09:31imirkin: yeah dunno
09:31night199uk: i don’t fully understand them yet
09:31night199uk: there is not a really good document i found on how to translate between them
09:32imirkin: tbh i don't super understand what these things are either. i think they made a lot more sense with CRTs
09:32imirkin: but just add/subtract the right things and you're set
09:32night199uk: imirkin: that’s the theory i’m working on too :-)
09:32imirkin: the "mode" in nouveau code is a lot more like the xf86 modeline iirc
09:32night199uk: i really need an expert on these at some point though so i can rename my variables
09:32night199uk: from x1, x2, x3, x4 :-)
09:33night199uk: okay, so nouveau should have code to convert from edid format to xf86 modeline format?
09:33night199uk: that looks like what you have here, let me check it out
09:34imirkin: drm_edid.c or something like that
09:34imirkin: is the thing that processes the edid
09:34night199uk: yer? okay, so with those two I should have the same code from nouveau
09:35night199uk: actually that link you sent me the code looks a LOT like the reversed code i’m looking at ;-)
09:35imirkin: pmoreau: fyi, your patch ended up in spam for me
09:36imirkin: pmoreau: might want to check with skeggsb to make sure he got it
09:37pmoreau: imirkin: :( Could be due to the greylisting thing. Ben also got it from my old address, which didn't end up in spam, so it should be fine.
09:40night199uk: imirkin: btw, you remember ages ago i was asking about bit-banging i2c vs hardware i2c?
09:40night199uk: maybe not :-)
09:40night199uk: the uefi driver actually uses bit banging for everything except DP
09:40imirkin: night199uk: i barely remember what happened 2 minutes ago
09:41night199uk: it uses HW impl for DPAux only it seems
10:03l1k: pmoreau: oh, does it say "No connectors with modes found"? then it didn't find any valid modes in VBIOS. that's exactly the point, this means that without the patch set your desktop environment sees two GPUs but only one of them has an active connector. on the other hand, with the patch set applied, the desktop environment sees two GPUs, each with a connected panel. and this confuses it somehow.
10:03pmoreau: l1k: Ok. But then isn't it better without the patch?
10:05l1k: pmoreau: just echo OFF > /sys/kernel/debug/vgaswitcheroo/switch before starting X so that it doesn't see the other GPU. or maybe you have to amend the Xorg config so that it doesn't get confused.
10:06l1k: pmoreau: if it's the 9600M GT that's not seeing any modes, the gmux was initially switched to the 9400M on boot.
10:06pmoreau: l1k: Iirc, X will still probe the card even after echoing OFF. Yep, the 9400M is the one driving the screen.
10:07l1k: pmoreau: it would be interesting to know if this script works on your machine: https://raw.githubusercontent.com/0xbb/gpu-switch/master/gpu-switch
10:08l1k: pmoreau: if you invoke that with "gpu-switch -d" and then reboot, theoretically it should boot with gmux switched to the 9600M GT and then likely the 9400M will be the one that's not seeing any modes.
10:09imirkin: joi: btw, in your "testing", have you been reclocking your card? if not and you have gddr5, there are some patches available that improve things a bit, esp for optimus.
10:09pmoreau: Oh, interesting script! I have been relying on Mac OS to set which card to default to.
10:10l1k: pmoreau: you mean with GfxCardStatus?
10:10pmoreau: l1k: I'll try it somewhat later.
10:10l1k: pmoreau: sure, no hurry.
10:11pmoreau: l1k: Nop, by switching beteen : "better battery life" and "more performance" in Mac OS energy settings
10:11l1k: pmoreau: oh I see.
10:12l1k: pmoreau: the script sets an EFI boot variable which influences the gmux setting on the next reboot.
10:24joi: imirkin: I have gddr5 and reclocking to 0a usually works
10:25imirkin: joi: with karolherbst's stuff, 0f works for many people
10:25joi: 0f however usually hangs everything
10:25joi: where are these patches?
10:25imirkin: joi: https://github.com/karolherbst/nouveau/commit/173f1d7e09af8abce576e2c09190032c5e90bfd4
10:28joi: thanks, I need to update the kernel first (I'm on 4.1)
10:28imirkin: the new drm tree should build against 4.2 i think
10:40marcosps1: Hi guys :)
10:44marcosps1: imirkin: So, isnsCanLoad change is a different problem than emitter?
10:44imirkin: by the time things hit the emitter it's already set in stone
10:44imirkin: the emitter's job is just to encode the instructions as specified
10:44imirkin: it's the earlier code's job not to create impossible-to-emit instructions
10:47marcosps1: imirkin: Ok, I'll work in insnCanLoad right now and after I'll look again in again in emmiter
10:47imirkin: the whole thing with the 20 bits there is that a single instruction can't encode arbitrary immediates
10:48imirkin: only ones that only have non-0 values in the top 20 bits
10:48imirkin: so you have to check that the immediate falls into that category before propagating it to the op
10:48joi: imirkin: ha, so now someone should see how this trace renders under blob drivers...
10:48imirkin: and then, when you have, you need to then make sure to emit it properly
10:48joi: because I'm not so sure which one is the correct one
10:49imirkin: joi: well, i'm sure it's just a st/mesa bug
10:51imirkin: joi: well this is glennk's render: http://i.imgur.com/m45g6vn.jpg
10:52imirkin: i think it's pretty obvious that it's way over-saturated
10:53marcosps1: imirkin: Ok, I'll try to write some code inside insnCanLoad.
10:59imirkin: joi: hmmmm actually yeah. unclear whether the intel one is right either.
11:01glennk: could go for all three being wrong :-)
11:06imirkin: but no matter which way you slice it, the nouveau one is def wrong.
11:11imirkin: ERROR: no viable spill candidates left
11:11imirkin: that could be why it renders black
11:11imirkin: some shader somewhere in there is quite unhappy
11:12joi: fyi, nouveau:master does not build against 4.2 anymore
11:18marcosps1: imirkin: by printing i and ld inside LoadPropagation::visit does not call insnCanLoad for set (winch will have our double directly in the instruction), of course because this method only checks the ld calls.. So do I need to test the first 20 bits in isImmd64Load after merging the two immds...?
11:32imirkin: marcosps1: i'd rather not encode that knowledge there
11:32imirkin: other isa encodings may be possible in the future.
11:32imirkin: all of that specific knowledge should be in the target class
11:32joi: I built 4.2+drm-next and something is not quite right: http://paste.ubuntu.com/12298820/ - nouveau suspened & resumed 6 times during boot
11:33joi: skeggsb: ^
11:34imirkin: for luck :)
11:34joi: new stress testing framework in action ;)
11:36marcosps1: joi: I have the same ACPI warnings in my machine...
11:36marcosps1: But this happens since Linux 4.0 and Nvidia Optimus...
11:48marcosps1: imirkin: So, you suggests to create a new method in targ and call it when detecting a new OP_SET in LoadPropagation::visit...?
11:48imirkin: i suggest making insnCanLoad work
11:48imirkin: btw, this isn't just for OP_SET
11:49imirkin: it's for other opcodes too
11:49imirkin: that was just an example
11:49imirkin: i assumed you realized that...
11:53marcosps1: imirkin: Sorry. I'll try to verify if we have a double immd inside insnCanLoad and then do the needed checks there.
12:04imirkin: 266: mov u32 $r1073741823 $r4 (8)
12:04imirkin: i guess the register file is bigger than i thought...
12:05imirkin: karolherbst: looks like the same issue you've been trying to track down
12:05imirkin: i guess i've been suckered into messing with it :`(
12:11imirkin: i don't get it. i think a coalesce is failing
12:53imirkin: ohhhhkkkk.... i think i see what's going on here
12:53imirkin: the builtins clobber $r0..$r3
12:53imirkin: and the mov happens BEFORE the clobber
12:54imirkin: and there's no "constraint" move AFTER the clobber
12:54imirkin: and so when the RA tries to assign $r0..$r3 to the thing, it can't end up assigning r3 to the immediate
12:54joi: imirkin: 0f does not improve performance here (with gddr5 patch)
12:54imirkin: joi: does it actually up-clock? check pstate
12:54imirkin: (the AC line)
12:56imirkin: joi: hmm... is the game cpu-limited?
12:56imirkin: 60fps sounds like vsync?
12:56imirkin: you can force-disable it with vblank_mode=0
12:57imirkin: joi: there's an additional "cheat" to increase pcie to 8GT/s
12:57imirkin: i forget the exact sequence of register writes you need to do
13:02joi: imirkin: it does not seem to be cpu limited
13:03joi: 60 fps is an average (including loading), in game it's only 15fps
13:03imirkin: joi: yeah...
13:03imirkin: joi: i get about 0.0001fps on that trace :)
13:05joi: what? why?
13:05imirkin: because i have a GF108
13:06mupuf: karolherbst: boom! I think I got it
13:06joi: so how do I increase pcie speed?
13:06mupuf: super simple
13:06mupuf:is a dumbass
13:07mupuf: funny how after a few hours of not working on something, the solution comes in a few seconds and a few minutes of scripting to check the idea
13:08mupuf:was looking for something hard, but it was actually trivial
13:09mupuf: ok, 100% confirmed
13:12mupuf: div = 27648000/pwm_freq
13:12mupuf: voltage = base_voltage + range_voltage * duty / div
13:13mupuf: why did it take me so long to realize that the second was the range? no idea...
14:12joi: imirkin: setting pcie speed does not help :/ I see LnkSta changes to 8GT/s with karol's pcie_speed branch (and gddr5 patch), but for some reason FPS does not go up
14:14mupuf: joi: what benchmark are you trying?
14:15imirkin: joi: oh well. on the bright side i have a patch that fixes your issue.
14:15imirkin: joi: if you want a benchmark that responds to memory speeds, try glxspheres
14:18joi: mupuf: trace of Shadow Warrior and nexuiz
14:22mupuf: joi: ok, try glxgears :D
14:22imirkin: glxgears isn't memory or gpu-bound
14:22imirkin: it's call overhead
14:22imirkin: glxspheres is good though
14:23mupuf: imirkin: glxgears is often pcie-bound
14:23mupuf: and this is what he is testing, right?
14:23imirkin: is it?
14:23imirkin: i guess it might be lightly correlated to that
14:26imirkin: karolherbst: btw, i suspect my patch will fix your issues as well
14:26imirkin: karolherbst: but i need to think about a better way of doing it
14:28joi: glxgears, 07: 1500, 0a: 2885, 0f: 2930
14:28joi: so it's consistent with other results
14:30imirkin: very surprising
14:30imirkin: er. glxgears. try spheres :)
14:31joi: where's it?
14:33imirkin: i dunno where i got it from
14:33imirkin: it's not in demos =/
14:33martian67: is reclocking working on nv40? (geforce 7xxx/6xxx) ?
14:33imirkin: i think i got it from vogl
14:33imirkin: martian67: yeah, should work fine on all but a few odd boards
14:34imirkin: martian67: boot with nouveau.pstate=1
14:34martian67: why isnt it enabled by default?
14:34imirkin: martian67: and you should be able to control it from /sys/class/drm/card0/device/pstate
14:34imirkin: because it doesn't 100% work :)
14:34imirkin: although for nv40 it could probably be enabled
14:34imirkin: but people bitched about the file being in sysfs
14:35imirkin: so we have to move it to debugfs first, and the patch to do that hasn't materialized itself on its own
14:35imirkin: as a result it's in sysfs
14:35imirkin: and behind a flag
14:35martian67: i see
14:36specing: ^ this is so stupid
14:36specing: hiding control behind flags only changeable on boot
14:36mupuf: imirkin: I would not be so confident about nv40 reclocking :D
14:37specing: or tearing down all GUI and reloading nouveau module (if you ever manage to unload it)
14:37imirkin: mupuf: it works on all but a few boards
14:37mupuf: well, not sure it works on any of my nv40 boards
14:37imirkin: at least that's according to skeggsb. worked on the one or two i tried it on.
14:37mupuf: ack, he may have fixed it
14:38imirkin: this was a while back
14:38imirkin: perhaps it broke? :)
14:40mupuf: no, my memory dates by more than the while back you are refering to
14:47joi: imirkin: glxspheres: 140/273/283
14:47joi: again, consistent
14:47martian67: imirkin, out of curiosity why does reclocking say "stalled" here under nv40?
14:48martian67: or power management rather
14:48martian67: is the stalled bit that you hae to add a boot flag?
14:48imirkin: joi: gah! i give up. i'm guessing that it's not *actually* working =/
14:48imirkin: martian67: well, there's more to reclocking. like actually changing clocks based on load.
14:49martian67: ah yeah i suppose
14:58mupuf: and power gating
14:58mupuf: and clock gating
14:58mupuf: there is still heaps of fun to be had :D
14:59imirkin: mupuf: on that basis, nothing is ever done
14:59mupuf: right :D
14:59mupuf: well, not really
15:00mupuf: something is done when the checklist is full of ticks
15:01imirkin: mupuf: nah, you just add more columns
15:01mupuf: ah ah
15:27karolherbst: imirkin: there are also some with core instabilities :/
15:28imirkin: karolherbst: check if my patch helps your situation with the compiler
15:28imirkin: karolherbst: https://bugs.freedesktop.org/show_bug.cgi?id=91895#c8
15:33karolherbst: mupuf: base and range .... yeah, that makes sense somehow...
15:33karolherbst: awesome work
15:33karolherbst: imirkin: the game could be gpu core limited
15:33mupuf:is writing the code for nouveau
15:34mupuf: it should be ready some time during the week
15:34karolherbst: that's why there may be no perf increase at 0f
15:34karolherbst: mupuf: awesome, thanks
15:34karolherbst: imirkin: glxspheres is part of vgl
15:35imirkin: oh yeah, virtualgl
15:35karolherbst: also glxspheres isn't the best benchmark for core either
15:35karolherbst: its getting pretty fast pcie speed limited
15:36karolherbst: I think i can increase fps in it up to 700MHz core freq, after that, nothing changes
15:41imirkin: skeggsb: hm odd, someone's blaming 3d9e3921f4 for gk104 issues
15:43karolherbst: imirkin: seems you are right, need to check if something I did interferes
15:46imirkin: karolherbst: see if my patch helps. it fixed the issue in that shader
15:46imirkin: although that particular problem would only occur when you'd have external calls, e.g. for integer division
15:47karolherbst: mhh, I get a strange assertion now
15:48karolherbst: nouveau_compiler: ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp:1727: void nv50_ir::GCRA::resolveSplitsAndMerges(): Assertion `merge->getDef(0)->reg.data.id >= 0' failed.
15:48karolherbst: have to check if that's my fauilt somehow
15:48karolherbst: ohh right
15:48karolherbst: I added that
15:54karolherbst: okay, all better now
15:55karolherbst: I removed one of my patches
15:55karolherbst: I moved my func->orderInstructions(); up a bit
15:56karolherbst: I do it now before all that stuff gets added
15:56imirkin: ok good
15:56imirkin: those things it inserts aren't really meant to be moved around
15:57karolherbst: will cheack heaven now
15:59karolherbst: imirkin: any idea? ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp:1689: void nv50_ir::CodeEmitterNVC0::emitLoadStoreType(nv50_ir::DataType): Assertion `!"invalid type"' failed.
15:59imirkin: yeah :(
15:59imirkin: known issue.
15:59imirkin: i've been turning a blind eye to it
16:00imirkin: basically when a 3-wide texture result gets spilled
16:00imirkin: it goes boom
16:00imirkin: because there's no 3-wide store
16:02zat: anybody experiencing those PGRAPH engine fault on channel X crashes?
16:03zat: they happen about every 20 minutes, and force me to reboot
16:03imirkin: zat: a few people have reported stuff in bugzilla
16:03zat: hello imirkin, yes I have too
16:03imirkin: ah ok :)
16:04zat: I am out of ideas how to further debug though
16:04imirkin: zat: someone reported that reverting one of the commits helped
16:06zat: imirkin: have it at hand?
16:06zat: I could try and confirm
16:06imirkin: zat: https://bugs.freedesktop.org/show_bug.cgi?id=90276
16:07zat: imirkin: is there a way I can somehow restore the video without need for a reboot?
16:07zat: sorry for my newbieness but I have tried removing module nouveau and adding it again
16:08imirkin: zat: sorry, i don't actually know what the problem is
16:10mupuf: karolherbst: [ 1238.827549] nouveau 0000:01:00.0: volt: current voltage: 918750uv
16:11zat: imirkin: I mean, generally, is there a way to recover the video from a GPU lockup.
16:11imirkin: zat: in theory, sure. in practice, nouveau generally doesn't recover.
16:11mupuf: karolherbst: just need to parse the vbios now
16:12mupuf: and get rid of all the assumptions of gpios
16:12zat: imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=91119
16:12zat: that happens to me
16:13zat: but if you read the dmesgs, despite being triggered by the same action, the last lines look quite different to me.
16:13mupuf: this morphing table is annoying
16:16karolherbst: mupuf: alright, will test your stuff after its finished :)
16:18karolherbst: mupuf: so in theory, the "voltage" of a cstate is looked up in the voltage map table and the pwm will be set to a value which fits?
16:19mupuf: the parsing of the voltage table is currently simplistic
16:19mupuf: and it will require more REing
16:19karolherbst: I see
16:19mupuf: happy to help :D ?
16:19karolherbst: mhhh depends
16:19karolherbst: faking bios doesn't work here ;)
16:19mupuf: oh, right
16:19mupuf: you can't then
16:20karolherbst: mupuf: also regarding my gpu fan, I think my board reads the gpu core temp somehow and sets the fan speed
16:21karolherbst: maybe I will try to find how I can set the fan manually though :/
16:23mupuf: you can't
16:23mupuf: well, wait a sec
16:24mupuf: you said you have a MXM board?
16:24mupuf: that means pluggable, right?
16:24mupuf: so the heatsink of the gpu is not shared with the cpu ...
16:24karolherbst: (on a side note: I can also remove my cpu...)
16:24mupuf: and you say there is a fan?
16:24karolherbst: one cpu, one gpu
16:24karolherbst: but both are connected to the main board
16:25mupuf: ah, I see
16:25mupuf: then why do you even care?
16:25mupuf: you think nouveau has to control it through ACPI?
16:25karolherbst: mhh maybe
16:25karolherbst: I think the EC takes care of both currently
16:25mupuf: if so, I am sooooo glad I do not have one of those laptops!
16:25karolherbst: the main thing why I want to do that though ism that the cpu fan is too loud
16:25mupuf: how does it read the temperature of the gpu?
16:26karolherbst: don't know
16:26karolherbst: but it does
16:26mupuf: even on nouveau?
16:26karolherbst: when the gpu goes off, the fan goes off, when the gpu is under load, the fan speed sup
16:26mupuf: hmm, it may be linked to the power consumption :p
16:27karolherbst: don't think so
16:27karolherbst: it takes some time until it speeds up
16:27mupuf: then your bios is smart-enough to know how to read 0x20400, congrats!
16:28karolherbst: but I have a custom bios mod, where you have two possibilities to flash the EC: slow fans and fast fans
16:28karolherbst: still, the cpu fan is too fast in general
16:29karolherbst: ohh wait
16:29karolherbst: I have 9 cooling_devices and 2 thermal_zones
16:30karolherbst: ohh sad
16:30karolherbst: okay, the gpu one isn't there
16:41karolherbst: mupuf: maybe some of my 24 GPIOs take care of that :/
16:44mupuf: take care of what?
16:44mupuf: reporting the temperature?
16:44mupuf: there may be i2c output
16:44mupuf: nvidia exposes the temperature subsystem as an lm99
16:44mupuf: or close-enough
16:45karolherbst: mhh, I have a FAN_PWM gpio
16:45mupuf: that may be the reason why, to easily allow hooking up external fan control
16:45mupuf: kernel logs please
16:45karolherbst: there is nothing about that ;)
16:45karolherbst: or what do you need?
16:46karolherbst: dmesg is pretty big now, so :/
16:46mupuf: nothing about fan?
16:46mupuf: oh, right
16:46mupuf: it is hidden now
16:47karolherbst: also the cooling_devies have garbage values
16:47karolherbst: cur_state is 0 for the cpu fan
16:47karolherbst: the blob does some stuff with the PWM_FAN gpio though
16:50mupuf: karolherbst: have fun http://fs.mupuf.org/mupuf/nvidia/0001-WIP-volt-add-support-for-pwm-based-voltage-managemen.patch
16:50mupuf: I will rework the patch and split it into a mergeable series during the week
16:50karolherbst: ahh it downloads directly :D
16:51mupuf: yeah, I need to configure nginx to display the text files and not ask for a download
16:52mupuf: it is pretty untested
16:52mupuf: it does return a sensible voltage
16:52mupuf: but I did not try setting a voltage
16:52mupuf: be my guest :D
16:53karolherbst: return as in return or will something in dmesg show up?
16:53mupuf: in dmesg, when setting debug="vbios=debug"
16:53mupuf: err, volt, not vbios
16:54karolherbst: mupuf: you forgot volt/pwm.c
16:54mupuf: oh, fuck
16:54mupuf: let me add it :D
16:54mupuf: actually, no, it is secret sauce! I won't open source that :p
16:54karolherbst: will you give me the .o file?
16:55karolherbst: mupuf: by the way: will the patch display what it "would" write into the reg?
16:56mupuf: nope, feel free to change it to do that if you do not trust my math skills
16:56mupuf: (you should NOT)
16:56mupuf: patch updated
16:56mupuf: it should compile on top of master
16:56karolherbst: ohh you added the write already
16:57karolherbst: I thought you wanted to be safe and didn't do that, maybe I missunderstood you
16:57mupuf: skeggsb: I like the strong type checking of your new rewrite :)
16:57mupuf: I just did not test it :D
16:57karolherbst: mupuf: why not reading the crystal freq instead of hardcoding it?
16:57mupuf: read from where?
16:57karolherbst: I do it in my gddr5 patch
16:57mupuf: I know, but check the frequency
16:58mupuf: it is either 27 MHz or 25 MHz
16:58karolherbst: mupuf: subdev->device->crystal
16:58mupuf: or others, but that's old stuff
16:58mupuf: yes, but it is not 27.XXXX
16:58mupuf: it is 27
16:58mupuf: yeah, well, at this point, why not hardcode it?
16:58karolherbst: odd cards with different crystals :D
16:59mupuf: because this 1.024 has no hw signification
16:59mupuf: well, until we understand the difference, I would say, let's keep it like that
16:59mupuf: I will check if we need to update to set the crystal to 27.XXXX instead of plain 27
17:00karolherbst: okay, applies fine
17:00mupuf: compiles fine?
17:00mupuf: if it does, then my work here is done .... for the week end!
17:01karolherbst: will try it out now though :p
17:01mupuf: now keep on fixing PM for me :p
17:02karolherbst: I guess the pwm gets set at loading time, too?
17:02mupuf: I have code for the power sensor too that I need to finish
17:02karolherbst: seems to low
17:02mupuf: oh, I forgot the "0x80000000 |" in the write
17:02karolherbst: I get 0x1f in the reg
17:02karolherbst: no wait
17:02karolherbst: its fine
17:02karolherbst: so I can test it now .d
17:03karolherbst: mupuf: lowest value seems too low
17:03karolherbst: and highest clock, too
17:03mupuf: well, go fix the voltage mapping table then :p
17:03karolherbst: nouveau 0x31, blob 0x3e
17:03mupuf: oh, wait, you can't...
17:04mupuf: you can try to make a little sense of it though
17:04mupuf: as for me
17:04mupuf: sleep time!
17:05mupuf: I assume you added the "0x80000000 |" to the write to 20344, right?
17:05mupuf: otherwise, it will never actually be written to the reg
17:05mupuf: err, to the pwm controller
17:06mupuf: skeggsb: here we go, REing of the PWM-based voltage management: DONE
17:08karolherbst: mupuf: I did not, because I wanted to check whats getting written into the reg and the new module was already loaded
17:08karolherbst: mupuf: do you use the lower value of the upper value of the mapping table?
17:08mupuf: read the code in volt/base.c
17:09karolherbst: mupuf: ohh I see
17:09karolherbst: the lower value get used
17:10karolherbst: is a big difference for me here for the highest voltage entry: voltage_min = 900000, voltage_max = 1037500
17:11karolherbst: maybe I will investigate this a bit
18:40karolherbst: mupuf: seems like 0x1f isn't "too" low, will check if the stability is fine enough
18:40karolherbst: mupuf: also I think the blob uses a voltage between min and max according to temperature or something
20:15imirkin: karolherbst: btw, if you get a chance, mind trying to play back the trace at https://bugs.freedesktop.org/show_bug.cgi?id=91895 on the blob and seeing if you get something that looks like the nouveau/r600 or intel lighting... or neither
20:15karolherbst: imirkin: I have that game
20:16karolherbst: ui, also installed, nice
20:16imirkin: ok... and so what is it supposed to look like?
20:16karolherbst: will check
20:16karolherbst: everything looks super strange
20:16imirkin: nouveau, intel or blob?
20:16karolherbst: nouveau looks better
20:17karolherbst: but still
20:17imirkin: wait, it looks bad on blob?
20:17karolherbst: where did I say that
20:17imirkin: it's super-dark on intel and super-bright on nouveau
20:17karolherbst: I just compared intel and nouveau
20:17karolherbst: the brightness is fine
20:18karolherbst: fancy lightning effect
20:18karolherbst: gloom and stuff
20:18imirkin: [and unless you have that spilling fix for nouveau, you get a black gun/bodies]
20:18karolherbst: I see
20:19imirkin: so... is the nouveau screenshot "right"?
20:19karolherbst: I don't know yet, have to remember where this was in the game
20:19karolherbst: I played that on maxed out settings, so :/
20:19imirkin: just replay the trace on blob...
20:20imirkin: that should minimize any potential for differences
20:20karolherbst: but I think the nouveau thingy looks okay except the blackis stuff
20:20imirkin: really? it looks way over-saturated
20:21imirkin: but perhaps that's how the game is supposed to be
20:21karolherbst: as I said: fancy lightning effects
20:21karolherbst: and bloom
20:21imirkin: gloom to me means "darkness"
20:21imirkin: i.e. the intel screenshot
20:25karolherbst: if that game would load faster :D replaying the trace now
20:25imirkin: yeah, kind of annoying
20:25karolherbst: I tried to start it with intel, after 5 minutes still nothing
20:25imirkin: that's.... a bit overly slow
20:25karolherbst: its okay
20:26karolherbst: it takes a long time with the blob too
20:26karolherbst: the first time
20:27karolherbst: yeah, nouveau looks more like blob
20:27imirkin: same as, or more like?
20:27karolherbst: didn't stop the replay, will compare frames now
20:28karolherbst: yeah, pretty much the same
20:28imirkin: did you do dump-images?
20:29karolherbst: qapitrace and lookup state
20:29karolherbst: and just looked at the buffer
20:29imirkin: i mean, if it's close, it doesn't matter
20:29imirkin: but the blob one isn't darker or anything?
20:30imirkin: ok cool
20:30imirkin: so the intel one is the one that's way off?
20:30karolherbst: only the bodies and the pistol are different ;)
20:30imirkin: sure, but that's expected
20:30karolherbst: ohh wait
20:30karolherbst: even the bodies are wrong on intel
20:31karolherbst: but I think this is related to the light
20:31karolherbst: because the colors aren't strange
20:32karolherbst: I think this is the first level or something, there is no night
20:32imirkin: i've never played any version of that game, so i have no frame of reference
20:33imirkin: anyways, i mentioned the issue in #intel-gfx, hopefully someone will take a look
20:33karolherbst: I will test nouveau with your patch, too
20:33karolherbst: also I need to test nupufs pwm patch
20:33imirkin: patch to diff things
20:35karolherbst: nouveau runs the gpu at much lower voltage than the blob does, but I think high enough
20:35karolherbst: got the gpu to cool down to 34°C with nouveau
20:48karolherbst: imirkin: is something like that "expected" or "can't say anything" ? http://www.plotshare.com/sessions/220404211/Plot1.png
20:48imirkin: more like "don't know anything" :)
20:49imirkin: doesn't seem unreasonable though
20:49imirkin: more freq = more voltage.
20:51karolherbst: ohh well nice, memory coruption hit again? Don't know
20:52karolherbst: anyway, I tried to find some relation between the cstate frew and the voltage from the map table
21:10imirkin: mogorva: does the drirc thing work if you use 'wine' as the name of the executable?
21:10imirkin: if so, that'd be rather sad
21:24mogorva: imirkin, doesn't work, no matter what the executable is
21:24imirkin: could you hack mesa to print out what it *thinks* the executable name is?
21:25mogorva: albeit 'wine' is only a wrapper script
21:25imirkin: look for execName in ./src/mesa/drivers/dri/common/xmlconfig.c
21:25imirkin: in driParseConfigFiles - should be easy to print out
21:29karolherbst: imirkin: wine is a bit "strange" in this domain, usually the .exe file is the "name" of the executable
21:30imirkin: yeah, i think mogorva started with that
21:30karolherbst: procfs "comm" also says the exe name for me here
21:30karolherbst: and exe is wine-preloader
21:31karolherbst: and cmdline is the path to the .exe file
21:31imirkin: well, this thing uses program_invocation_short_name so it might just be wine-preloader =/
21:31karolherbst: would make sense
21:32karolherbst: top also says the exe file so yeah
21:33karolherbst: imirkin: usually the "wine" command quits and just forks wine-preloader somehow
21:33karolherbst: but in a strange way
21:33imirkin: not a whole lot of different ways available...
21:33imirkin: clone(), fork() and exec() are about it (plus their variants)
21:34karolherbst: as far as I know, the exe files aren't interpreted but rather nativly executed + hooks to deal with win32 behaviour
22:00noone_: what might be the cause of nouveau causing a hard panic on 7900 GS?
22:57mlankhorst: musca: indeed
22:57mlankhorst: mupuf_: *