00:57 pmoreau: imirkin: Hello! I don't see why this shader (https://phabricator.pmoreau.org/P14) produces this code (https://phabricator.pmoreau.org/P16)
00:57 pmoreau: Especially, why can't you load the imm value directly as a f32, and why isn't it done only once and then moved to each element of the vector?
01:36 RSpliet: pmoreau: it looks like a conversion from int to float
01:37 pmoreau: Right, but why? The immediate isn't given as an int in the GLSL code.
01:37 RSpliet: is there a mov imm f32 instruction in nouveau?
01:38 RSpliet: besides: is it not optimised away later on?
01:39 pmoreau: I'll have to check
01:41 RSpliet: I think the hwdocs is incomplete, you might have to decode the disassembler
01:42 RSpliet: and/or verify the mov f32 is a mov f32 and not a cvt that's being emitted :-P
01:43 pmoreau: Oh right, it is: NV50_IR_DEBUG_VERBOSE wasn't enough, I also needed NV50_IR_DEBUG_BASIC. ^^
01:43 karolherbst: I think I want to try to solve this buffer object oom issue in metro, any pointers where I should start with that?
01:46 RSpliet: I thought it just was NV50_PROG_DEBUG=1
01:48 pmoreau: It seems to be similar to having only NV50_IR_DEBUG_BASIC, and only shows the final state of the program.
01:49 pmoreau: NV50_PROG_DEBUG=7 is even better
01:50 pmoreau: I tend to forget about environment variables, and set the flags by hand in the code... Thanks for pointing this out. ;)
01:55 RSpliet: heh, I always freak out when I realise I didn't compile with debug enabled
01:56 pmoreau: ;)
02:42 gsedej: Hi. Trying NV40/G73. I get llvmpipe instead of novueau. dmesg looks "ok"
02:42 gsedej: what this means? fb: switching to nouveaufb from VESA VGA
02:44 gsedej: eh sorry, this is ok...
02:45 gsedej: is this ok in Xorg.0.log? (EE) Failed to load module "nvidia" (module does not exist, 0)
02:46 pmoreau: Well, if you don't want to use nvidia's driver, it is fine. :)
02:47 pmoreau: gsedej: Could you paste your dmesg and Xorg.0.log somewhere please?
02:48 gsedej: dmesg http://paste.ubuntu.com/12060601/
02:48 gsedej: xorg log http://paste.ubuntu.com/12060610/
02:50 gsedej: it does not work in clean 14.04 (no oibaf ppa)
02:50 gsedej: either
02:50 pmoreau: It's using the VESA module as it couldn't open /dev/dri/card0
02:51 gsedej: there is no /dev/dri
02:52 pmoreau: Maybe due to "[drm] Failed to open DRM device for pci:0000:04:00.0: -19"? I'll have a look what -19 corresponds to.
02:54 gsedej: llvm 3.6 is not inastalled, maybe an issue? installing...
02:54 gsedej: oh, libllvm is intalled
03:01 pmoreau: So, 19 is ENODEV
03:04 gsedej: which means?
03:05 gsedej: the card might have some HW issues
03:06 pmoreau: I find it weird you don't have any messages for fb allocation, but it could be the dmesg output is different on pre nv50 cards
03:07 pmoreau: ENODEV would be no device
03:08 gsedej: is there any other log?
03:08 gsedej: i can check
03:09 glennk: is modesetting enabled?
03:10 pmoreau: Should be: "modesetting: Driver for Modesetting Kernel Drivers: kms"
03:10 glennk: not seeing any kms stuff in the kernel log
03:12 pmoreau: If modesetting was disabled, Nouveau wouldn't output a single line
03:12 pmoreau: Just do nothing
03:14 pmoreau: gsedej: You could try to reboot and add drm.debug=0xf on the command line
03:15 glennk: not sure what this line means: nouveau W[ VBIOS][0000:04:00.0] 0x0000[ ]: init data not found
03:16 gsedej: i will try
03:16 pmoreau: No init scripts were found in the VBIOS maybe?
03:17 gsedej: (waiting for dist-upgrade to finish on this USB-based installation)
03:17 gsedej: maybe missing firmware?
03:19 pmoreau: nv4x shouldn't need any external firmware iirc, apart if you wanted video acceleration
03:19 pmoreau: s/apart/except
03:23 karolherbst: did you check LIBGL output already?
03:23 karolherbst: maybe the gl lib is just configured wrongly
03:23 karolherbst: LIBGL_DEBUG=verbose glxinfo
03:24 pmoreau: It should not cause drmOpen("nouveau") to fail, should it?
03:24 karolherbst: maybe the drm module is missing
03:24 pmoreau: It is found: Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
03:24 pmoreau: [ 22.712] (II) Module nouveau: vendor="X.Org Foundation"
03:24 pmoreau: [ 22.712] compiled for 1.17.1, module version = 1.0.11
03:24 pmoreau: [ 22.712] Module class: X.Org Video Driver
03:24 pmoreau: [ 22.712] ABI class: X.Org Video Driver, version 19.0
03:25 karolherbst: I meant the libdrm thingy
03:25 pmoreau: Ah
03:25 karolherbst: or does the DDx depend on it?
03:25 karolherbst: could be
03:25 karolherbst: but if X finds the card, this is usually a good sign
03:25 karolherbst: and usually a issue in userspace
03:26 karolherbst: "open /dev/dri/card0: No such file or directory" this is strange
03:26 pmoreau: If it was an ABI mismatch, there would have been a message saying so, right?
03:26 karolherbst: also "open /dev/fb0: No such file or directory"
03:26 karolherbst: these should be there
03:26 karolherbst: maybe udev is messing up?
03:27 pmoreau: I'm quite sure the failed open is due to "Failed to open DRM device"
03:27 pmoreau: I hadn't seen the /dev/fb0 missing
03:27 pmoreau: Ah, right
03:28 karolherbst: gsedej: are you there?
03:28 pmoreau: It is weird he doesn't have something like:
03:28 pmoreau: [ 334.673865] nouveau [ DRM] allocated 1920x1080 fb: 0x50000, bo ffff88020d517400
03:28 pmoreau: [ 334.673966] fbcon: nouveaufb (fb0) is primary device
03:28 pmoreau: [ 334.741070] Console: switching to colour frame buffer device 240x67
03:28 pmoreau: [ 334.742754] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
03:28 pmoreau: [ 334.742755] nouveau 0000:01:00.0: registered panic notifier
03:28 pmoreau: [ 334.753816] [drm] Initialized nouveau 1.2.2 20120801 for 0000:01:00.0 on minor 0
03:28 pmoreau: in his dmesg
03:28 karolherbst: mhhh
03:28 karolherbst: right
03:29 karolherbst: what is "vt.handoff=7" for?
03:29 karolherbst: I know its unrelated
03:29 pmoreau: https://help.ubuntu.com/community/vt.handoff
03:30 pmoreau: Doesn't say much
03:30 gsedej: i was away. LIBGL_DEBUG=vebose says opening driver swrast_dri.so and can't open conf file .drirc
03:31 pmoreau: http://askubuntu.com/questions/32999/what-is-vt-handoff-7-parameter-in-grub-cfg says a bit more
03:31 pmoreau: (I've got to run, I'll be back later)
03:32 gsedej: LIBGL_DEBUG glxinfo http://paste.ubuntu.com/12060812/
03:34 karolherbst: okay yeah, the issue is that there is no /dev/dri/card0 and /dev/fb0
03:36 gsedej: i will reboot with dri.debig=0xf
03:38 mupuf: imirkin: you found a bug in nvidia's implementation of image size :p
03:46 gsedej: hi! it was update problem
03:46 gsedej: after dist-upgrade it "works"
03:46 gsedej: i get 3D
03:46 gsedej: so very sorry for bugging you
03:47 gsedej: and thanks for support!
03:47 gsedej: (the HW indeed is buggy, after few sec of 3D rendering it freezes. It did wirk ok with software rendering)
03:48 RSpliet: gsedej: well, the hw is probably not buggy, but nouveau's support for this hardware
03:49 RSpliet: I think I have a G73 somewhere collecting dust
03:49 RSpliet: I recall Gnome shell working on it, but 3D support suffering from many bugs
03:50 RSpliet: but... I reckon the code is collecting as much dust as the GPU, and with mesa changing around it new bugs could be uncovered when time passes
03:50 RSpliet: someone is looking into NV4x support right now, feel free to file bugs
03:58 gsedej: RSpliet, i got GPU as "might not be working"
03:58 gsedej: after few reboots glmark2 ran trough
04:30 RSpliet: gsedej: if it's that random, I'd be interested what happens if you disable your second CPU code
04:35 imirkin: mupuf: oh?
04:36 imirkin: gsedej: someone else was having issues with MSI on nv4x's... try booting with nouveau.config=NvMSI=0
04:37 imirkin: gsedej: also based on your original dmesg, it didn't seem to be able to read its VBIOS properly, which would lead to tons of trouble
04:38 mupuf: imirkin: yeah, nvidia does what I did for imageCube, they also return the number of faces even though it is useless
04:38 imirkin: pmoreau: a mov is a mov is a mov is a mov. there is no "float" or "integer" mov. it just takes a 32-bit value.
04:38 imirkin: mupuf: ok. double-check the GL 4.3 spec
04:38 mupuf: I more than double checked
04:38 imirkin: mupuf: they could have changed it in the GL spec, i dunno
04:38 imirkin: ok
04:39 mupuf: ah, yeah
04:39 imirkin: from glsl 4.50: ivec2 imageSize (readonly writeonly gimageCube image)
04:39 mupuf: it was already there in the extension
04:39 mupuf: "Cube images return the dimensions of one face"
04:39 imirkin: well, things can change between ext and spec :)
04:41 mupuf: 4.3 and 4.4 are consistant with the ext
04:41 pmoreau: imirkin: Ah ok, so it's just a visual thing (`mov f32 [...]` vs `mov u32 [...]`)
04:41 mupuf: yep, same in 4.5
04:41 imirkin: mupuf: it's enough to just check the latest spec usually
04:42 mupuf: ack
04:42 imirkin: pmoreau: neat... "[PATCH v2 00/22] Enable gpu switching on the MacBook Pro"
04:43 pmoreau: Gonna read it, but I guess the concept is still the same as v1, which iirc doesn't work for my MBP as it is Nvidia+Nvidia, and not Intel+Nvidia as it is the case for the patches' author
04:43 pmoreau: But, I'll go through them again :-) and test them
04:43 imirkin: pmoreau: ah ok
04:44 pmoreau: I could be wrong though
04:44 imirkin: didn't realize the finer points :)
04:45 pmoreau: If you look on the cover letter, hardware tested is only Intel+Nvidia
04:47 imirkin: yea
04:47 karolherbst: is there a way to use nvidia-settings on reator?
04:48 karolherbst: would like to create a trace on a keple/maxwell card there regarding reclocking like the one I did yesterday
04:52 karolherbst: pmoreau: do you have a MBP where the intel gpu is only there in efi mode?
04:52 pmoreau: karolherbst: I have one which doesn't have any Intel GPU ;)
04:52 karolherbst: I see
04:53 pmoreau: Only one integrated Nvidia GPU and one discrete Nvidia GPU
04:53 karolherbst: okay
04:53 karolherbst: but are both there in legacy mode?
04:53 pmoreau: Absolutely no idea, I have always been using EFI mode
04:53 karolherbst: but I think mine was intel+amd, still in legacy mode only the amd one was there and the gmux defaulted to amd in efi mode
04:54 karolherbst: I had a lot of fun with this one, but you could check if you want, would be a interesting test case for the patches too
04:55 pmoreau: For me it defaults to what was configured in OS X: if I'm in battery mode, integrated is the default one, otherwise it's the discrete.
04:55 pmoreau: It looks like the mux state is kept across reboots in that case
04:55 karolherbst: never tested that this deeply, but I think after a reboot it always used the amd dedicated one
04:56 karolherbst: not sure though, it was like 2 years ago
04:56 pmoreau: :)
04:56 karolherbst: but I had a lot of fun writing into some regs and do everything in the right order to get anything usefull
04:57 pmoreau: Ah ah! My laptop is still broken though, due to some problems with the G96
04:58 karolherbst: the bad thing was: everybody on the internet said it wasn't possible to use the intel card with mine or at least there was no instructions how do to so. it was a big mess entirely
04:58 pmoreau: I have somewhat similar issues on a G84 card, which should be easier to debug (maybe)
04:59 karolherbst: mhh
04:59 karolherbst: luckily there is usually not much to debug
05:00 karolherbst: I mean, its pretty trivial whats going on there
05:00 pmoreau: This bug has been a problem from day 1 until last September on MBP5,X https://bugs.freedesktop.org/show_bug.cgi?id=27501
05:00 karolherbst: wait
05:00 pmoreau: Not always that trivial I would say
05:00 karolherbst: will check which one I had
05:01 karolherbst: MacBookPro8,2
05:01 pmoreau: You should check the serie that was just sent then! ;)
05:02 pmoreau: From the cover letter:
05:02 pmoreau: Tested-by: William Brown <william@blackhats.net.au>
05:02 pmoreau: [MBP 8,2 2011 intel SNB + amd turks pre-retina]
05:02 karolherbst: I don't have it anymore
05:02 pmoreau: Oh, too bad
05:02 karolherbst: temp sesor bricked
05:02 karolherbst: cpu clocked down to <1,2GHz
05:02 pmoreau: :/
05:03 karolherbst: yeah
05:03 karolherbst: was jumping between -256°C and 256°C
05:03 karolherbst: was no fun with fans at max speed
05:04 karolherbst: but I had to do basically this: unbind framebuffer device => unload radeon drm => change mux state => load intel drm => done? or bind fb device
05:05 karolherbst: but this one had on the fly switch support inside OS X
05:05 karolherbst: without reboot/relogin or anything
05:05 pmoreau: That's nice!
05:05 pmoreau: I don't have that on mine
05:05 karolherbst: there was also a nice tray application for that
05:05 karolherbst: where you could force one
05:06 pmoreau: gpu-switch or something similar?
05:06 karolherbst: and then you wondered why your DP port didn't work
05:06 karolherbst: gpu switch
05:06 karolherbst: I guess
05:06 karolherbst: ahh no
05:06 karolherbst: gfxCardStatus
05:06 pmoreau: Oh right, I had it installed at some point
05:07 karolherbst: but I don'T think there will be nice linux support for this anyway, because the entire GL stack has to somehow know this change
05:07 karolherbst: because you could also change while some GL stuff was running
05:10 pmoreau: Maybe you could delay the change until a frame is finished and sent to one GPU, and then do the switch?
05:10 karolherbst: nice, arch has it on its wiki: https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011)#EFI_Boot
05:10 karolherbst: the "set gfxmode=${GRUB_GFXMODE}" script below
05:11 karolherbst: but I somehow managed to do that with efi stub
05:11 karolherbst: and without using grub at all
05:12 karolherbst: I think it was with the 3.0 or 3.1 kernel bac then
05:12 karolherbst: seems a lot easier now
05:12 pmoreau: Seems like it was also a pain to get it working properly
05:12 karolherbst: yeah
05:12 karolherbst: but then it worked without problems :)
05:13 karolherbst: saw the note? "Boot into BIOS emulation mode. AMD card works, but intel card doesn't."
05:13 karolherbst: I don't know why, but even lspci won't display the intel card
05:13 karolherbst: I think this is some legacy mode stupidity
05:13 karolherbst: or to ennoy windows users?
05:13 karolherbst: I don
05:13 karolherbst: 't know
05:13 karolherbst: *anoy
05:14 karolherbst: ...
05:14 karolherbst: I don't care about spelling anymore now
05:14 pmoreau: :D
05:14 RSpliet: spelling is for bees
05:14 karolherbst: stupid n key
05:14 karolherbst: there is some dirt beneath it and I am to lazy to get it out
05:14 karolherbst: under the n
05:15 pmoreau: I like in the serie that they fix the default res of 1024x768 on the inactive GPU and put a proper one! \o/
05:15 karolherbst: :D
05:15 karolherbst: ohh wait
05:16 karolherbst: I still have a MacBookPro2,1
05:16 karolherbst: but this is like one gpu
05:17 pmoreau: How old is it now?
05:17 karolherbst: 9 years
05:17 karolherbst: 10.7 max :)
05:18 karolherbst: OS x
05:18 pmoreau: Still nice
05:18 karolherbst: ATI X1600 :D
05:27 pmoreau: ... Second time my dekstop decides to freeze completely...
05:27 karolherbst: mhh
05:27 karolherbst: freeze or kernel down?
05:28 pmoreau: What do you call kernel down?
05:29 karolherbst: like nothing happens anymore
05:29 karolherbst: not even ssh
05:29 karolherbst: or something
05:29 karolherbst: mhhh
05:29 karolherbst: strange
05:29 pmoreau: kernel down then :)
05:29 karolherbst: you could check /sys/fs/pstore
05:29 karolherbst: really strange
05:30 karolherbst: gddr5 0f pstate seems to work stable now
05:30 karolherbst: I don't know why
05:30 pmoreau: Did you change anything to get it to work?
05:30 karolherbst: no
05:30 karolherbst: nothing
05:30 karolherbst: just turned on card, load nouveau, launch games
05:31 karolherbst: and set pstate to 0f before
05:32 pmoreau: And you did measure a performance improvement, right?
05:50 karolherbst: okay, fresh reboot
06:01 pmoreau: I should find an easy way to extract all patches of a serie sent to a ML.
06:03 karolherbst: mhh
06:03 karolherbst: would it be possible to let a "echo 0a > pstate" exit even if the nouveau module encounters issues?
06:04 karolherbst: like gddr5 mem reclock is messed up and it won't get into 0a back again
06:06 karolherbst: for whatever reason, if I start a game with 0f it kind of works
06:06 karolherbst: but chaning pstates while its running always messes it up
06:08 mupuf: well, stable reclocking is a bitch
06:08 mupuf: it really is super hard!
06:08 mupuf: I had tons of problems with the nv50
06:25 karolherbst: yeah okay, but I always got the feeling, that gddr5 0f only works rarely
06:26 karolherbst: mhhh
06:26 karolherbst: there is still this annoying DRI_PRIME tearing issue
06:26 karolherbst: which gets worse with higher frame rates
06:28 karolherbst: wow
06:28 karolherbst: ffmpeg x11grab just halfs my fps ingame
06:29 specing: mupuf: my only problem with NV50 is that it needs reflows
06:29 mupuf: specing: tell me about it!
06:29 specing: in that case, lack of reclocking is actually a bonus
06:29 specing: back when I was still using nvidia blobs, I enabled overclocking and downlocked it
06:30 specing: though I believe nouveau idles at middle freq
06:30 karolherbst: http://www.filebin.ca/2BtCBZEe5tu2/out.mp4 if somebody wants to take a look
06:30 specing: would be great if it could drop to lowest
06:30 specing: and stay there
06:30 mupuf: specing: you can believe all you want, only checking is useful :p
06:30 mupuf: and no, it is likely at the max speed
06:30 mupuf: unless you have a laptop
06:30 specing: I believe my memory, I think it was 275
06:31 specing: I have a laptop
06:31 mupuf: then I agree
06:31 mupuf: :p
06:31 specing: 8600M GT was iirc 175, 275 or 474
06:31 specing: 475&
06:31 specing: MHz
06:31 mupuf: those are highly upclockable
06:31 mupuf: as in HIGHLY
06:31 specing: ?
06:31 mupuf: overclockable*
06:31 karolherbst: i the mp4 file you really see how old frame are inserted in between and that everything stutters a lot
06:31 mupuf: I got to 2x the core speed
06:32 mupuf: and 2x to memory speed
06:32 specing: can nouveau download liquid cooling as well??
06:32 mupuf: without changing the memory timings
06:32 mupuf: it was not so bad
06:32 specing: it idles at 72'C
06:32 specing: with 275
06:32 karolherbst: :O
06:32 mupuf: oh!
06:32 karolherbst: thats too much
06:33 specing: ambient is 34'C or so
06:33 mupuf: that's warm, even by nv50's standard
06:33 karolherbst: mine is idling at 50°C
06:33 specing: I got it to 106'C when I was still gaming on it
06:33 karolherbst: :/
06:33 specing: I had to go wash my left hand every 15 minutes or so
06:34 specing: was sweating like a maniac
06:34 karolherbst: mhh
06:34 karolherbst: ever checked the fan or something?
06:34 karolherbst: maybe thermal paste helps
06:35 specing: thermal paste is shit as I use some generic white goo
06:35 karolherbst: maybe there is only this rubber pad thingy
06:35 specing: but even before that it was high temp
06:35 karolherbst: I see
06:35 karolherbst: maybe the fan is shit as well
06:35 specing: RAMs and northbridge is rubber pad
06:35 specing: cpu and gpu are pasted, seperate heatsinks
06:36 karolherbst: seperated fans as well?
06:36 specing: nope
06:36 karolherbst: I see
06:36 karolherbst: shouldn't be an issue though
06:36 specing: just seperate grills one after another
06:36 karolherbst: mhh
06:36 karolherbst: sounds like bad design
06:36 specing: I think the cpu one is first
06:36 karolherbst: lenovo laptop?
06:36 specing: well its an OEM unbranded gaming laptop, what did you expect?
06:37 karolherbst: ahh
06:37 karolherbst: mhh
06:37 karolherbst: but these shouldn't be that stupid
06:37 karolherbst: seriously
06:37 specing: Compal iFL90 to be exact
06:37 specing: I don't think I have software control over the fan like I have on the thinkpads
06:38 specing: it seems on all the time though
06:38 karolherbst: mhh
06:38 specing: can I make nouveau use lowest clock?
06:39 karolherbst: usually the EC does the right think
06:39 karolherbst: yeah thorugh pstates I think, but I don't know if for this card
06:39 specing: how far can I downclock it while still being usable for 2D use and reducing power consumption?
06:39 karolherbst: mupuf: should pstate stuff work on NV50?
06:40 mupuf: specing: well, depends on your definition of 2D usage
06:40 specing: temp1: +71.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +110.0°C, hyst = +3.0°C) (emerg = +125.0°C, hyst = +10.0°C)
06:40 mupuf: browsers are demanding
06:40 mupuf: what you want is dynamic reclocking
06:40 specing: no I don't
06:41 mupuf: really? Why?
06:41 specing: dynamic reclocking -> big temperature swings -> [676056.784498] NVRM: GPU at 0000:01:00.0 has fallen off the bus.
06:42 specing: what I want is for it to stay at a near constant temperature
06:43 mupuf: well, you can set a lower high temperature
06:43 specing: otherwise it fails and I have to dissasemble the laptop, reflow the GPU and assemble it back
06:43 mupuf: and it would downclock your gpu
06:43 mupuf: if you set it to 75C, it will do a good job
06:44 specing: mupuf: but then it is only going to be limited on the upper side
06:44 specing: nothing preventing it from cooling to e.g. 65'C
06:45 karolherbst: it would be nice to know why the gpu is that hot
06:45 karolherbst: is it like always in use or anything?
06:45 specing: *shrug*
06:45 specing: I only firefox here
06:45 mupuf: because there is no power gating
06:45 mupuf: nor clock gating
06:45 specing: pretty much nothing else
06:46 karolherbst: I see
06:46 specing: I'm pretty sure that gpu accounts for 80% of said laptop power consumption
06:54 specing: it seems all dGPUs are ridiculously bad wrt. power management
06:55 specing: I have a GMA4500+radeon 3470 thinkpad and when I switch to discrete graphics in bios it is much much warmer than when on integrated
06:55 night199uk: hey
06:55 night199uk: long shot, but anyone around that can talk about reg 0x6194e8? :-)
06:59 glennk: GMA4500+radeon 3470, lol at that combination, what were the laptop hw designers thinking?
07:00 pmoreau: How often is the I2C PAD:X: supposed to happen?
07:01 specing: glennk: ?
07:01 specing: glennk: what is wrong with that combo?
07:02 pmoreau: It feels like it's polling everything 20ms, X is using 100% of one core and I get 4FPS on glxgears...
07:02 glennk: uh, the gma is faster than the 3450?
07:03 specing: glennk: LOL WHAT
07:03 specing: glennk: the GMA4500 can barely run enemy territory on low settings
07:04 specing: the radeon does ET on high and can actually run SpringRTS
07:10 sooda: hm. anyone comfortable with the notify mechanism in nvkm? i'm wondering why struct nvkm_client has just a small static array of those notify objects...
07:12 sooda: even nouveau_fence_context_new (called for each channel) creates a new one for every opened channel, so those should run out quickly
07:13 imirkin_: sooda: only skeggsb i'm afraid
07:13 sooda: :(
07:13 imirkin_: sooda: but every fd open is a separate client
07:13 sooda: i heard some rumors here about a week ago that he went out for vacation?
07:13 imirkin_: sooda: and normally there aren't that many contexts
07:14 sooda: hm
07:14 imirkin_: sooda: indeed. i don't think he's back.
07:14 sooda: dang
07:14 imirkin_: but if he is, he's def asleep
07:14 sooda: i just got back a week ago and sent some patches for review, bad timing :P
07:15 sooda: but yeah, you've got a point that each fd shouldn't normally have that many open. i'm just having problems since i ran out of them due to that error notifier addition (by me) with a stress test that apparently opens several.
07:16 imirkin_: well, crashing nouveau is no rocket science
07:16 sooda: 8)
07:16 imirkin_: anything with 'stress' in the name should do it ;)
07:16 specing: will nouveau take the kernel with it?
07:17 glennk: specing, eh, sorry, mixed up gma 4500 and hd 4500, rather different beasts those two
07:17 specing: glennk: well, I'm sure a 2015 radeon can smash the hd4500 just as easily as a 2008 radeon can smash a 2008 GMA
07:18 specing: +- one year
07:19 imirkin_: specing: hard to tell if it takes the pci bus with it or the kernel... end result is the same
07:20 specing: well I hope firefox and terminal doesen't stress it too much
07:23 imirkin_: firefox certainly can once you get into webgl things
07:23 glennk: specing, well a intel hd 4600 mobile and a r5 m230 end up in approximately a washout between the two
07:41 karolherbst: specing: I am pretty sure that the performance gab is smaller for low end gpus
07:41 karolherbst: as it was 5 years ago
07:42 karolherbst: but if you compare some high end amd gpus for >300$ with a intel gpu then of course the amd is faster, but that's not because amd is generally better or intel generally worse
07:42 specing: *shrug*, I currently only buy >5 year old gear
07:42 karolherbst: mine intel hd 4600 is pretty powerfull
07:42 karolherbst: it can compete with my GTX 770M at 0a pstate pretty well
07:43 karolherbst: with the nouveau driver
07:43 karolherbst: I think intel hd 4600 == 730M == 640M ?
07:43 karolherbst: something around that
07:45 karolherbst: so saying intel gpus are slow and weak is like saying mesa is still software only ;)
07:48 karolherbst: I really want this anoying DRI_PRIME issue fixed, because then I could use nouveau for some games instead of blob :D
08:01 specing: karolherbst: which games work and which do not?
08:11 marcosps: imirkin_: around? :)
08:11 imirkin_: ya
08:12 marcosps: imirkin_: I beleive I fixed the problems in TESS_EVAL and TESS_CTRL
08:12 imirkin_: awesome
08:12 imirkin_: send a patch
08:12 imirkin_: see http://mesa3d.org/devinfo.html for the proper way to do it
08:12 marcosps: imirkin_: do you want to take a look? http://pastebin.com/NDCK1U0p
08:14 imirkin_: marcosps: is that seriously it?? i wonder if the tgsi_text change needs to be more involved =/
08:14 imirkin_: marcosps: i suspect that ctx->implied_array_size != 0 needs to be true
08:15 imirkin_: marcosps: it's probably set based on a property for GS, and it needs to be set to 32 for tess ctrl/tess eval
08:16 marcosps: imirkin_: OK so... I'll try to figure out how this is set :)
08:16 marcosps:is anxious to send the first patch to nouveau/mesa...
08:17 imirkin_: take your time :)
08:17 marcosps: imirkin_: BTW, I already tested the GEOM shader too, and this also needs a tweak to work :)
08:18 imirkin_: no. geometry shaders work fine now.
08:22 marcosps: imirkin_: So may I had missing something...
08:22 imirkin_: marcosps: show me a geometry shader that doesn't work fine now
08:22 imirkin_: perhaps i'm missing something
08:24 marcosps: imirkin_: sorry, my shader is invalid here...
08:24 marcosps: I just copied a shader from out tests directory...
08:42 marcosps: imirkin_: in parse_property I don't see anything related to tess ctrl/ tess eval. So, shoulD I change in that place? Also, this 32 is a hardcoded value for tess_{eval,ctrl} ?
08:42 marcosps: imirkin_: please tell me if I'm annoying you right now :)
08:43 imirkin_: yeah, 32 is the right value for tess eval/ctrl... for GS it's specified as part of a shader property, but for tess it's trickier to determine the right value
08:44 imirkin_: basically just set ctx->implied_array_size = 32 in the translate() funtion based on ctx->processor
08:45 karolherbst: mlankhorst: ping, I just heard you did something about DRI_PRIME synchronisation? I might want to help with that, because I have some issues there http://www.filebin.ca/2BtCBZEe5tu2/out.mp4 and https://imgur.com/ld8ei8t
08:54 imirkin_: marcosps: did that make sense to you?
08:56 marcosps: imirkin_: yes, I'm testing the change now...
08:56 imirkin_: cool!
08:57 marcosps: imirkin_: more or less like it: http://pastebin.com/REhmEZUa ?
08:57 imirkin_: marcosps: precisely
08:57 marcosps:is getting a warning about using plain 32 in implied_array_size
08:58 imirkin_: errr what
08:58 imirkin_: int implied_array_size : 5;
08:58 imirkin_: genius
08:58 imirkin_: thanks, premature optimization
08:58 imirkin_: bump it up :)
08:58 marcosps: imirkin_: I never guessed how this ": something" works in structs...
08:59 imirkin_: 5 bits
08:59 imirkin_: with a *signed* type, no less
08:59 marcosps: Hum, nice :)
08:59 imirkin_: make it unsigned implied_array_size : 5 -- that should be enough to hold 32 i think
09:00 imirkin_: err... not. my brain is mush. needs to be : 6
09:01 marcosps: imirkin_: ok, I'll change and try again...
09:02 marcosps: imirkin_: the warning is gone :)
09:02 marcosps: imirkin_: It's working!
09:02 imirkin_: awesome
09:02 mupuf: marcosps: what is?
09:03 mupuf: tesselation on ... ?
09:03 imirkin_: mupuf: fixing tgsi_text parsing of tess programs
09:03 marcosps: mupuf: It's a small goal for the project, but I big one to at least :)
09:03 marcosps: *to me at least
09:03 marcosps: imirkin_: what can be a nice comment for the implied_array_size assigment?
09:03 mupuf: karolherbst: serious sam 3 :p
09:04 marcosps: mupuf: serious sam 3 uses it?
09:04 mupuf: I see you have very high fps, like I did last time I checked
09:04 mupuf: marcosps: tesselation? No idea. I was talking to karolherbst
09:04 imirkin_: marcosps: meh. dunno. i'd just leave it uncommented.
09:05 mupuf: imirkin_, marcosps: seems like a good thing
09:05 marcosps: mupuf: sorry to annoy you :) And thanks!
09:05 marcosps: imirkin_: ok, I'll commit and send to ML...
09:05 mupuf: marcosps: no worries,
09:11 marcosps: imirkin_: along witht the binary code, tess ctrl shows more information: http://pastebin.com/YQWdhuC5
09:12 imirkin_: marcosps: hehehe
09:12 imirkin_: so close ;)
09:12 imirkin_: i guess it manages to add a whole new dimension? impressive.
09:14 marcosps: imirkin_: So, my patch needs more work?
09:15 imirkin_: yeah...
09:15 imirkin_: heh
09:15 imirkin_: it should print the same thing as input
09:15 imirkin_: i wonder if the implied_array_size handling is off
09:15 imirkin_: i forget how GS works
09:17 marcosps: imirkin_: Hum.. I'll try to verify this new problem at night! Thanks a lot for all the help!
09:29 night199uk: hrm
09:30 night199uk: is there a repo of valid register traces from any cards anywhere?
09:30 night199uk: or does anyone have a register trace from a gf108?
09:31 imirkin_: night199uk: https://github.com/envytools/envytools/tree/master/rnndb/
09:31 mupuf: night199uk: register trace?
09:31 imirkin_: or you mean mmio traces?
09:31 mupuf: you mean mmiotrace?
09:31 night199uk: mmiotrace i guess
09:31 night199uk: yeah
09:31 night199uk: the reads/writes performed on init, etc
09:31 mupuf: we have one repo for that, but it is kept private to protect the privacy of contributors
09:32 night199uk: ahhh
09:32 night199uk: would it have a gf108 trace in it at all that you’d be privy to vet/share plz?
09:32 mupuf: We could send you a few of them
09:32 mupuf: I think I have a trace of a gf108
09:33 mupuf: just remind me in an hour, I am still at work
09:33 night199uk: have my uefi vbios mostly complete now :-)
09:33 night199uk: okay
09:33 mupuf: already?
09:33 mupuf: Very nice!
09:33 night199uk: yeah
09:33 night199uk: i’m just testing
09:33 mupuf: no modesetting though, right?
09:33 night199uk: modesetting is there
09:33 night199uk: not tested yet
09:33 mupuf: AHAH
09:34 night199uk: 99% of the code is done
09:34 night199uk: its basically just testing now
09:34 mupuf: fixing, not testing :p
09:34 night199uk: well, fixing, yer :-)
09:34 night199uk: should at least work on gtx6xx kepler/fermi
09:34 night199uk: then will start to work on gtx9xx
09:41 night199uk: and
09:41 night199uk: qq
09:41 night199uk: what is MXM?
09:41 imirkin_: a way that some laptop gpu's plug in
09:41 imirkin_: sorta acpi-ish iirc
09:41 night199uk: just alternative to PCIE?
09:42 imirkin_: mmmm... not sufficiently sure to answer, sorry
09:42 imirkin_: it has some ACPI-ish implications
09:42 imirkin_: but i also think it might be a connector type
09:42 night199uk: :-)
09:42 night199uk: np
09:42 night199uk: thats close enough - it’s just laptop/mobile, right?
09:43 imirkin_: yeah
09:43 imirkin_: it's so that they can make a single laptop motherboard
09:43 imirkin_: but be able to plug diff gpu's in
09:50 karolherbst: mupuf: yeah serious sam 3 is the picture and borderlands presequel is the video
10:05 mupuf: really? Never seen borderlands before then
10:16 gsedej: imirkin, your solution seemd to work, (... MSI on nv4x's... try booting with nouveau.config=NvMSI=0)
10:16 imirkin_: gsedej: awesome
10:17 gsedej: but I still feel like "random". each reboot lasted longer. I only tested for cca 30 min
10:17 imirkin_: hm?
10:17 gsedej: the GPU was givet to me as "might faulty"
10:18 imirkin_: well, at least the boot you showed, it wasn't able to read its PROM, which happens before we try to enable MSI
10:19 gsedej: the boot i showed was bad update. After i did dist-upgrade it worked
10:19 imirkin_: no, it has nothign to do with update
10:24 gsedej: I don't know how, but i rebooted few times without update, and didn't help, but then I just dist-upgrade and it works
10:24 imirkin_: probably a poweroff? dunno.
10:25 gsedej: i didn't poweroff just restart after dist-upgrade
10:27 gsedej: anyway, was there some progress with GM108? https://bugs.freedesktop.org/show_bug.cgi?id=89558
10:27 imirkin_: no, it's waiting on ben to analyze the trace
10:28 imirkin_: which in turn is probably stuck behind his mega-rewrite-the-everything-again work
10:32 karolherbst: mupuf: its also a dlc and very different than everything before in the scenery
10:32 karolherbst: its inside a claptraps "mind" if you are aware of what it is ;)
10:32 karolherbst: the little yellow robot
10:37 karolherbst: specing: generally most of the games work
10:38 karolherbst: specing: anything special I should check?
10:40 specing: idk
11:11 night199uk: mupuf: ping
11:13 night199uk: “mupuf: just remind me in an hour, I am still at work”
11:13 night199uk: :-)
11:14 mupuf: night199uk: i'm eating now, give me a sec
11:14 night199uk: sure, np
11:21 gsedej: wow, developer replying during meal. this is dedication! :D
11:26 pmoreau: mupuf: Ping, don't forget to add my SSH-key please. :-)
11:27 mupuf: pmoreau: ah, right
11:27 mupuf: ssh key for the vbios repo?
11:27 pmoreau: Yes please
11:28 Yoshimo: dedication is needed, the phoronix article that a 980ti is the best for linux gamers is a bit far from the truth right now
11:38 karolherbst: Yoshimo: I don't even come close to the bioshock infinite performance :D
11:38 mupuf: pmoreau: should be done
11:40 Yoshimo: karolherbst: i would love to try nine, but neither my fermi nor my maxwell card have reclocking, so it ain't fun at all
11:46 karolherbst: I see
11:46 karolherbst: usually nine is in a not that good state as you may expect
11:46 karolherbst: I tried like 15 games and it worked like for 3 or 4 of them
11:47 Yoshimo: but it is not even worth trying and hoping to help with bug reports, if you get 7fps
11:47 Yoshimo: with nouveau
11:48 imirkin_: Yoshimo: no bug reports = bugs don't get fixed
11:49 Yoshimo: yea, but i won't try if performance is unplayable
11:50 imirkin_: ok. then don't be surprised if bugs don't get fixed ;)
11:52 karolherbst: Yoshimo: tropcio 4 runs pretty smoth on ultra settings
11:52 karolherbst: thats like the only thing I use nine for because it doesn't work with the blob for whatever reasons
11:52 karolherbst: *reason
11:53 karolherbst: but bioshock infinite runs pretty nicely on nouveau nethertheless
11:54 Yoshimo: which card? my tries with nouveau were not ending well
11:54 karolherbst: GTX 770M
11:54 karolherbst: 0a pstate is nice if you don't use full hd
11:54 karolherbst: 0f is pretty good
11:57 Yoshimo: 980 and a 560ti here
11:58 karolherbst: ...
11:58 karolherbst: okay, sleeping while ouveau is doing stuff over DRI_PRIME => no good idea
11:59 karolherbst: https://gist.github.com/karolherbst/4b11e24952856b78b1be
11:59 karolherbst: ahh wait
11:59 karolherbst: this is my bricked bash, which tries to write something into the pstate file :/
11:59 karolherbst: but can't because the driver was unloaded in between and stuff
12:00 karolherbst: at least I know where it hangs now :)
12:01 karolherbst: mhhh
12:01 karolherbst: CPU load seems to matter for nouveau performance a lot
12:03 karolherbst: okay the tearing stuff seems to happen for like everything
12:03 karolherbst: but the frame ordering is only weird for some games
12:04 karolherbst: Yoshimo: bio infinite ultra fullhd: 13-24fps
12:05 imirkin_: fullhd = 1080p right?
12:06 karolherbst: yeah
12:12 karolherbst: imirkin_: what would be the best way to debug performance? look at how shaders get compiled on blob and how on mesa or just look at the mesa shader and search for optimizations opportunities?
12:13 mlankhorst: karolherbst: just replace shaders with nops and see what the fps is :-)
12:13 karolherbst: :D
12:13 karolherbst: mlankhorst: did you see my poke about DRI_PRIME frame issues?
12:13 imirkin_: karolherbst: well, you could try to see where the time is going... executing shaders? if so which shaders?
12:14 karolherbst: I see
12:14 imirkin_: then you could look at those shaders and see if the compiler is doing something ridiculously bad
12:14 imirkin_: and/or manually rewrite them to see if you can do better
12:14 imirkin_: we don't really have good mechanisms for doing any of that
12:14 imirkin_: [or bad ones for that matter]
12:22 RSpliet: rofl... een hosting toko die op z'n homepage een form heeft waarop je hun domein kan kopen
12:24 imirkin_: and once again for those of us whose dutch is on the weak side?
12:24 RSpliet: oh sorry, translated that means "whoops, wrong IRC channel"
12:25 imirkin_: ;)
12:25 RSpliet: love your understatement btw
12:26 mupuf: hehe
12:26 imirkin_: google translate doesn't like 'toko'
12:38 karolherbst: :D
12:39 karolherbst: if you are creative enough you can understand it with english knowledge
12:43 karolherbst: whats the best way to see current gpu usage with nouveau?
12:44 imirkin_: step 1: implement a mechanism for seeing current gpu usage
12:44 imirkin_: step 2: use said mechanism
12:45 karolherbst: I saw that intel-gpu-tools have a nouveau flags
12:47 imirkin_: i was wholly unaware of that
12:48 RSpliet: karolherbst: do you not have German roots?
12:49 karolherbst: yeah I have, why?
12:51 RSpliet: that helps a lot more in understanding Dutch than knowing English ;-)
12:51 karolherbst: :D
12:51 karolherbst: yeah I know
12:51 karolherbst: best if you know both
12:52 RSpliet: it is, German is basically just a mix of Dutch and English... ;-)
12:52 karolherbst: I always get the feeling that dutch is a funny mix out of english and german/friesian
12:52 karolherbst: :D
12:52 karolherbst: this is another way to put it
12:53 karolherbst: but I thing friesian is pretty close to dutch in general
12:53 RSpliet: blame the Germanic people
12:53 RSpliet: it is... officially it's a language, but it's more like the most far-out dialect "we" have
12:53 karolherbst: yeah how could the split up and let so many different languages come up
12:54 RSpliet: arbitrary pride has a strange effect on people
12:54 karolherbst: in my entire youth I was north of hamburg, so I kind of understand dutch just like this
12:55 RSpliet: ah yes, you'd easily end up with Frysians
12:56 karolherbst: which rarely happened though
12:56 karolherbst: too near to the city I guess
12:56 RSpliet: it's not a big thing
12:58 RSpliet: where'd you move after your youth btw? :-)
13:00 karolherbst: it kind of depends, but the I lived in hamburg and kind of move to Göttingen now
13:00 karolherbst: I am not that old, that I can say my youth is completly over ;)
13:00 RSpliet: hehe, fair enough... looks like there's some great hiking areas around, not?
13:01 karolherbst: I guess so, don't really now what there is much around going on
13:01 karolherbst: but usually I would always assume there are
13:02 RSpliet: this assumption is shattered the minute you go look for it around Rotterdam :-P
13:02 karolherbst: ahh the nouveau flag for intel-gpu-tools is for prime testing :/
13:02 karolherbst: too bad
13:02 karolherbst: :D
13:03 karolherbst: ground too wet?
13:04 RSpliet: no altitude
13:05 karolherbst: mhh
13:05 karolherbst: I mean okay without that its not that much fun, but you could go hiking without altitude
13:05 karolherbst: if there are forests
13:06 RSpliet: not really
13:06 karolherbst: yeah I know :/ I was in the netherlands once, was nice though
13:07 RSpliet: there is nature around, just not in South Holland
13:07 karolherbst: north east looks nice
13:07 karolherbst: allthough more like centre
13:08 karolherbst: really? two national parks and an airbase in between?
13:09 karolherbst: okay north east and the middle look good
13:09 RSpliet: generally if you want nature, you need to stay out of the "Randstad" (the triangle Amsterdam, Rotterdam, Utrecht)
13:16 MichaelLong: I live next to the province of limburg, nice region
13:40 aschmack: Hello, I am experiencing some hangups with the nouveau driver. I am running CentOS 7 and working on updating a piece of legacy software to use DRM/KMS instead of the old /dev/fb0 interface. So the program does the following:
13:40 aschmack: oops
13:41 aschmack: 1) allocates a VT, switches to it. 2) gets DRM master, sets mode to 800x600 3) catches VT_RELDISP and resets the mode before switching out of the VT
13:41 imirkin_: aschmack: is the failure nouveau-related
13:41 imirkin_: or are you just seeing it on nouveau because that's what you happen to be using
13:41 aschmack: it didn't happen when not running nouveau
13:42 imirkin_: i.e. does it fail on radeon or intel
13:42 aschmack: no
13:42 imirkin_: ok cool
13:42 imirkin_: that gives some credence to your app not being entirely wrong :)
13:42 imirkin_: what gpu are you using btw?
13:42 aschmack: so when switching back to X on exit, the display is frozen on the last frame that was showing before it started
13:42 aschmack: a geforce 8400
13:43 aschmack: http://pastebin.com/pMsUR3NB
13:43 imirkin_: G84 or G98?
13:43 aschmack: gt210?
13:43 imirkin_: GT218, hah. none of the above.
13:43 aschmack: here is lspci, dmesg, and /var/log/messages
13:43 imirkin_: yay for marketing names!
13:43 aschmack: i also experienced once where the display deactivated and wouldn't come back
13:44 imirkin_: is this an optimus setup?
13:44 aschmack: no
13:44 imirkin_: oh joy. kernel 3.10
13:44 aschmack: bad kernel?
13:44 imirkin_: just... extremely old
13:45 imirkin_: although i'm rather confused...
13:45 imirkin_: your backtrace indicates it's in nouveau_pmops_runtime_suspend
13:45 imirkin_: but iirc nouveau didn't gain runpm until 3.12, and it was super-buggy there but iirc fixed in 3.13 or so
13:46 aschmack: backported? i'm not sure, this is a pretty much stock CentOS 7.1.1503 system
13:46 imirkin_: is there a chance you could try this on not-a-franken-kernel?
13:47 aschmack: try possibly, but it can't be the solution, unfortunately. We're using CentOS for "stability's" sake
13:48 imirkin_: well, the situation is that nouveau is wildly understaffed, so if it's not broken on whatever the latest upstream kernel is, it'll be difficult to get anyone to care
13:48 imirkin_: however it's a good thing to check so that you can complain to the centos people
13:49 aschmack: will do then
13:53 imirkin_: aschmack: btw, i note you also have an AST chip on there? that might help trigger a bug that i remember the 3.12 kernel had wrt runtime pm
13:54 imirkin_: aschmack: you could try building the kernel without runtime pm, or boot with nouveau.runpm=0
13:55 imirkin_: [would be good to double-check that they indeed backported the feature... does modinfo nouveau list runpm as a parameter? that should have been new in 3.12]
14:04 pmoreau: Is there an instruction to pretty-print/print a drm_crtc/nv50_head, or which information should I display to identify/separate two crtcs?
14:05 pmoreau: Apparently, on my G96, calling nv50_crtc_disable a first time is fine, but the second time everything goes wrong.
14:06 pmoreau: I'd like to know if it's called twice on the same, or if they are different, which one is which
14:06 aschmack: imirkin_ i'm taking off for today, but i'll be sure to try those tomorrow
14:06 aschmack: if you remember that bug please PM it to me
14:22 imirkin_: pmoreau: which data structures exactly?
14:23 pmoreau: drm_crtc
14:24 imirkin_: nv50_head->base.index
14:25 pmoreau: Cool, thanks!
14:27 pmoreau: I'll confirm using the index, but I think it is doing: 1) cursor_hide, 2) cursor_show_hide, 3) crtc_disable, 4) crtc_disable, with things breaking between 3 and 4.
14:38 pmoreau: And... I was wrong: first disable is on crtc 0, while the second one is on crtc 1.
18:08 marcosps1: imirkin: around?
18:09 marcosps1: imirkin_: about that I said to you some hours ago, it was just the debug information... now tess ctrl and tess evl is working as expected