03:15 karolherbst: imirkin: by the way: I have to schedule the NOPs last
03:15 karolherbst: then it works
05:56 adakite: Hi, where can I get the OpenCL support statement?
06:12 karolherbst: adakite: what do you mean by that?
06:19 karolherbst: mupuf: if you want you can tell me what you need for the pwm thing and then I could try to somehow make a sense off all the values.
06:19 mupuf: karolherbst: if only I knew
06:19 karolherbst: :D
06:19 mupuf: I will have a look at it tonight
06:19 karolherbst: did you see my graphs by the way?
06:20 karolherbst: the blob seems to behave a bit odd
06:20 mupuf: yes, very odd
06:20 karolherbst: I mean, I see how the blob does it, but still
06:20 karolherbst: its pretty clear
06:20 karolherbst: I think the blob just doesn't care about the changed max clock and has some kind of table internal? max clock = some voltage and lower clocks are calculated from it?
06:21 karolherbst: this could explain this somehow
06:23 mupuf: I still have not figured out for sure which section is the the critical path for the voltage
06:24 karolherbst: k
06:25 karolherbst: this 0x340 reg is somehow strange
06:25 karolherbst: was it also 0x60 for you?
06:26 karolherbst: ohh wait, I have an idea
06:36 karolherbst: mupuf: didn't saw this funny line "MMIO32 W 0x020340 0x00000060 PTHERM.PWM_VID_DIV <= 0x60"
06:37 mupuf: yes, it is always 0x60
06:37 karolherbst: I mean the blob writes it
06:38 mupuf: I have been trying to find the divisor in the vbios
06:38 karolherbst: it does it actually pretty frequent
06:39 mupuf: if you see a write different than 60, then that will be interesting
06:39 karolherbst: yeah, searching for it
06:39 mupuf: nouveau writes both the PWM div and duty every time :p
06:39 karolherbst: blob does the same
06:41 karolherbst: sadly it seems to be always 0x60 :/
06:43 karolherbst: I should don't care about the pwm value for 135MHz :/ this destroys all my ideas :D
06:44 karolherbst: mhhh
06:45 karolherbst: "600000 + 10176 * PWM_VALUE" this somehow fits
06:47 karolherbst: mhh, but seems wrong
11:33 karolherbst: what do you guys thinkg about the idea adding some "real-live" tgsi shaders from games into some kind ot test suite or would that may cause copyright issues?
12:23 karolherbst: imirkin: the merge instructions are getting strange. merge->defs[0].value.reg.data is the thing which is like always broken
12:23 karolherbst: for all merge it is -1
12:29 karolherbst: but its also -1 for working shader :(
13:10 imirkin: karolherbst: merge is when you make a bunch of distinct values into a single (up-to) 4-wide value
13:10 imirkin: karolherbst: there's shader-db, i need to spend some time integrating with it
13:10 imirkin: the mesa infra for it has been recently very much improved, but i haven't taken the time to update nouveau to work better with it
13:10 imirkin: there are also private repos of all the various shaders a particular game uses
13:10 imirkin: but ... they're prviate. however those shaders are easy to generate, just need the software
13:10 imirkin: perhaps mupuf can set up a repo for us
13:14 karolherbst: imirkin: still didn't figure out what the real issue is, currently I think about some compiler issue maybe? don't know. basically I get something like 0x3fffffff = -1 * MIN2(4, 8) ?
13:14 karolherbst: have to take a deeper look again
13:15 imirkin: more like
13:15 imirkin: (u32)-1 / 4
13:18 karolherbst: the issue manifest somewhere in "unsigned int reg = regs.idToBytes(v_);"
13:18 karolherbst: reg is 4294967292
13:19 karolherbst: idToBytes is return v->reg.data.id * MIN2(v->reg.size, 4);
13:20 karolherbst: v->reg.size is of type "char" internally anyway, so mhh
13:20 imirkin: which should be 0xfffffffc
13:21 karolherbst: input v->reg.data.id: -1 v->reg.size: 8 (castet to int)
13:21 karolherbst: output: reg: 4294967292
13:22 karolherbst: MIN2(8, 4) should be 4 right?
13:23 karolherbst: despite the fact, that id shouldn't be -1 at this point and it never is for working shader, the result is still, mhh dunno, is it right?
13:38 mupuf: imirkin: do you want a shaderdb repo? I can definitely make one right now
13:39 karolherbst: sounds good
13:39 karolherbst: I have some shaders I would like to put in there, because they fail while doing istruction reordering :)
13:40 karolherbst: imirkin: did you see my comment about those NOPs? I schedule the last, becaue scheduling first didn't work, just want to know if its fine that way or if this shows a serious issue I have
13:42 mupuf: karolherbst, imirkin: nvidia_shaderdb
13:42 mupuf: usual url
13:43 karolherbst: it's empty :O
13:43 karolherbst: ;)
13:43 mupuf: karolherbst: fill it :p
13:43 karolherbst: mhh
13:43 karolherbst: I have only tgsi shader though ;)
13:44 mupuf: the repo is accessible by me, mwk, skeggsb, xexaxo, RSpliet, imirkin, pmoreau and you. If someone needs access to it, I can provide it.
13:44 karolherbst: would be nice to think about directory and name conventions, so that we could write a simple script to iterate over everything and check for regressions
13:44 karolherbst: or stuff
13:44 mupuf: I agree
13:45 mupuf: I am working for intel on QA stuff right now
13:45 mupuf: and I have nouveau in mind too
13:45 mupuf: I wouldn;t mind a fully automated system where the only thing I need to do is pop some gpu in
13:45 karolherbst: mhh
13:45 mupuf: and it could be tracking performance of some benchmarks too
13:46 karolherbst: why should we depend on a gpu?
13:46 karolherbst: ahh I see
13:46 mupuf: hehe
13:46 karolherbst: but I was thinking more about just compiling
13:46 karolherbst: just compile for every possible chipset
13:46 karolherbst: :)
13:46 mupuf: the compilation part is definitely gpu-independent
13:46 karolherbst: yeah
13:46 mupuf: but instruction count does not tell the full story!
13:46 karolherbst: right
13:46 karolherbst: and this is not deterministich anyway :)
13:47 mupuf: and it would be nice to be able to run shaders compiled by nvidia vs ours
13:47 mupuf: and optimise them based on that
13:47 karolherbst: yeah
13:47 karolherbst: that would be awesome
13:47 mupuf: it is very difficult though
13:47 karolherbst: mhhh
13:48 karolherbst: I think matching the binaries might be tricky
13:48 mupuf: you need to recreae the entire pipeline for the shader you want to check
13:48 mupuf: anyway, I have to film a cycling competition tomorrow morning, so I guess I will hit the bed now!
13:48 karolherbst: k
13:49 karolherbst: mupuf: does envytools work on windows?
13:49 karolherbst: somehow
13:49 mupuf: yes, thnaks to hakzsam
13:49 karolherbst: mhh
13:49 mupuf: nva works on windows
13:49 karolherbst: was thinking about playing with voltage there
13:49 karolherbst: and read the PWM out
13:50 karolherbst: or are there linux tools for the nvidia blob and voltage regulating?
13:51 karolherbst: the thing I try to figure out now, is what voltage gives a specific pwm value, but somehow the blob doesn't tell me the voltage, or I don't know any way to do that
13:53 mupuf: oh, you want to run the modified version of nouveau on windows :D
13:53 mupuf: Sounds like FUN :D
13:53 karolherbst: why?
13:53 karolherbst: there are many gpu tweaking tools out there on windows
13:53 mupuf: how the heck are you going to read the frequencies otherwise?
13:53 karolherbst: they should always give you requencies and voltage stuff
13:53 mupuf: ok, have fun!
13:54 mupuf:goes to bed
13:54 karolherbst: thanks
13:54 karolherbst: I don't like windows, so I may not do it anyway :/
14:28 imirkin: mupuf: awesome thanks
15:34 karolherbst: ohh, now I get an access denied :(
16:01 karolherbst: awesome, look what I've found: "16 (bit 4) - Enables overvoltage using nvidia-settings CLI options. Available since version 346.16 for the Fermi architecture and newer."
16:09 karolherbst: imirkin: "Attribute 'PCIEMaxLinkWidth' (pingu:8.0): 16." found in nvidia-settings, allowed is 1-16 :)
16:10 karolherbst: also funny how this value is encoded actually: "Attribute 'PCIEMaxLinkSpeed' (pingu:8.0): 8000."
17:03 imirkin: skeggsb: any idea why the nv34 decided to use TV-1 for its fbdev/fbcon output and not the connected DVI port? [worth noting that there's no tv output, at least not on the back of the card]
17:24 obimod: anyone know what's wrong here? https://gist.github.com/obimod/22e0821dfe35c558e80c
17:24 obimod: receiving "(EE) no screens found(EE)"
17:25 obimod: the goal is to end up using `xinit fluxbox` or `xinit xmonad` or `xinit xfce` etc.
17:26 obimod:bangs head against desk
17:27 imirkin: obimod: errr... i don't think that's quite right
17:28 imirkin: obimod: does it work without an xorg.conf at all?
17:28 obimod: imirkin: should i delete it and try xinit?
17:29 imirkin: obimod: move it out of the way
17:31 obimod: :) fluxbox seems to have popped up
17:31 obimod: or not fluxbox
17:31 obimod: but some window system
17:32 obimod: or no, it's fluxbox, pretty sure
17:32 obimod: other monitor doesn't show though
17:33 obimod: imirkin: so yes, it works without the config but two side by side monitors is the goal
17:35 imirkin: well, you can use xrandr
17:37 obimod:checking it out
17:38 obimod: imirkin: replacement for xinit or is it a post-launch tool?
17:42 imirkin: post-launch tool
17:42 imirkin: make sure you can get it to work with xrandr
17:49 obimod: imirkin: it's not showing the different outputs, only has one output that it calls "default" via "defailt connected 1024x768+0+0"
17:50 obimod: imirkin: i've installed xserver-xorg-video-nouveau, shouldn't that enable it to show the different output options?
17:51 imirkin: obimod: pastebin dmesg
18:20 obimod: imirkin: nouveau: E[ DEVICE][0000:06:00.0] unknown chipset
18:20 imirkin: obimod: not a good start :)
18:20 obimod: imirkin: nouveau E[ DRM] failed to create 0x80000080, -22
18:20 imirkin: if it's a GM204 you need pretty new kernel
18:20 imirkin: and note that you won't get any accel, no matter how new the kernel
18:20 obimod: nouveau: probe of 0000:06:00.0 failed with error -22
18:21 obimod: yup, it is GM204
18:21 imirkin: btw, pastebin means e.g. hastebin.com or pastebin.com or one of the other similar sites
18:23 obimod: imirkin: http://fpaste.org/261078/
18:25 imirkin: yeah, you're gonna need something a lot more recent than 3.16
18:25 imirkin: initial support landed into 3.19
18:26 imirkin: but that only gets you modesetting
18:26 imirkin: also, how is your 2560x1440 screen connected?
18:26 imirkin: it'll only work right now if it's via DP or DVI, not with HDMI
18:27 obimod: yup, HDMI. the other one is via DP
18:27 obimod: I can grab a DP cable for it
18:27 imirkin: but note again, no acceleration
18:27 obimod: imirkin: so i have to rebuild the kernel?
18:28 imirkin: or you can get a prebuilt one from your distro
18:28 obimod: maybe something like this? apt-get -t experimental install linux-image-3.10-rc5-686-pae
18:28 imirkin: anyways, with HDMI you can only get up to 165mhz of pixel clock... there's a patch to increase it, but not upstream yet
18:28 imirkin: 3.10 is older than 3.16
18:29 imirkin: you want 3.19 or newer
18:29 obimod: whoops
18:29 obimod: gotchya
18:29 obimod: dang they hae 4.1 out
18:29 obimod: linux-image-4.1.0-1-amd64
18:30 imirkin: sounds good. but note that i have no clue how debian stuff works. i'm sure there are helpful guides online though.
18:31 obimod: https://wiki.debian.org/HowToUpgradeKernel :)
18:31 obimod: imirkin: thanks a lot for this... should have talked with you sooner
18:39 SolarAquarion: who's in control of doing the PRIME development stuff
18:43 imirkin: no one
18:45 obimod: imirkin: omg soooo much better
18:45 obimod: imirkin: wow! it's like a new machine!
18:47 imirkin: obimod: note that there's no 2d or 3d acceleration
18:47 obimod: imirkin: even with 4.1?
18:49 imirkin: even with the patches destined for 4.3
18:49 imirkin: starting with GM200 nvidia hw only takes signed firmware
18:49 imirkin: so there's not a whole lot we can do
18:50 imirkin: we could try to use theirs, but we've had trouble even retrieving it since they changed the way that the firmware is accessed to a much-more-difficult to trace mechanism
18:59 obimod: yuck
19:02 obimod: what are the negatives with using proprietary drivers?
19:03 SolarAquarion: imirkin, well "set DRI_PRIME 1" which is the way to do DRI_PRIME=1 in fish
19:03 SolarAquarion: doesn't work
19:03 imirkin: obimod: none
19:03 imirkin: SolarAquarion: as in... setting the variable doesn't work, or it doesn't do the things you expect?
19:04 SolarAquarion: imirkin, setting the variable doesn't work
19:04 imirkin: well... i dunno how to do it in your shell :)
19:06 SolarAquarion: imirkin, it's set variable number
19:11 imirkin: SolarAquarion: well, if you're looking for help, you need to provide more info
19:13 SolarAquarion: imirkin, how do i provide more help?
19:13 imirkin: like... you could make a mention of what's not working the way you expect it to
19:14 SolarAquarion: imirkin, changing the light on the power button
19:14 SolarAquarion: in zsh/bash where i can do DRI_PRIME=1/0
19:14 SolarAquarion: it changes colors
19:15 SolarAquarion: the red color is when the nvidia one is the one providing the Graphics
19:15 SolarAquarion: White when the intel chip is
19:15 imirkin: i feel like the support guy at http://static.fjcdn.com/large/pictures/b2/82/b282e9_1905246.jpg
19:19 babai: lol
19:20 imirkin: SolarAquarion: if your issue is with how to operate your shell, you need to seek help in a different channel
19:20 imirkin: gr. why do people do this. ./test-distrib: ./test-distrib: cannot execute binary file -- am i seriously the first person cross-compiling emacs?
19:20 SolarAquarion: hmm
19:20 SolarAquarion: weirdl
19:20 SolarAquarion: ok
19:22 karolherbst: :)
19:22 karolherbst: imirkin: mhhh well crosscompiling binaries is usually mhh not done?
19:24 imirkin: ahahahahahhahahha
19:25 imirkin: well this doesn't _quite_ work on BE
19:26 karolherbst: for what are you trying to compile by the way?
19:27 imirkin: ppc64
19:27 karolherbst: ohh, mhh
19:27 karolherbst: I guess you set host and all that crap?
19:28 imirkin: yeah, the whole thing built and then it has a thing at the end
19:28 karolherbst: :D
19:28 karolherbst: I can figure what it is I guess
19:29 imirkin: that's like "oh, you're cross-compiling? that's too bad, i have a thing here that'll prevent it from completing"
19:29 karolherbst: mhh
19:29 karolherbst: I think a compiled binary is just executed, but this is somehow strange?
19:29 karolherbst: because it should be compiled for the host system
19:30 imirkin: skeggsb: you may be interested in this: https://drive.google.com/file/d/0B5tpwkyyHkokRGgzdU1INnUzYk0/view?pli=1
19:30 imirkin: that's what i get when loading the new nouveau on the nv34 in the powermac
19:30 imirkin: (a) the colors are wrong and (b) the letters are wrong!
19:31 imirkin: [and it obviously all works fine in the OF console]
19:31 karolherbst: :D
19:31 karolherbst: should I decipher that for ya?
19:32 imirkin: just have to swap every group of 4 chars
19:32 karolherbst: yeah
19:32 karolherbst: endian problem?
19:32 imirkin: now to figure out where the code's messing it up
19:32 imirkin: yeah. it's a ppc64... BE
19:32 karolherbst: yeah
19:53 karolherbst: imirkin: I found something out about that -1 issue: its common for some ops to have a -1 there, but I doubt it should happen for merges
19:53 imirkin: are you looking at srcs/dsts wrong?
19:54 karolherbst: no, its okay. with working shaders, id is never -1
19:54 karolherbst: but wiht the failing one it is
19:54 karolherbst: I never explicitly looked for that, so I missed the point, where the merges are handled
19:55 karolherbst: it only occures, when spilling failed
20:27 karolherbst: mhh slowly I don't get what happens ... this is really painful to understand what's going on there :/
20:27 imirkin: want to hunt for BE issues in vt.c/fbcon.c?
20:28 karolherbst: kernel?
20:28 imirkin: yea
20:28 karolherbst: mhh, if you hunt for my issue :p
20:28 imirkin: heh
20:29 karolherbst: I think somebody with a good knowledge about RA/post-RA needs to look over it maybe
20:29 karolherbst: I mean, the issue is pretty clear to me now: MERGE instructions doesn't get their reg stuff set
20:30 karolherbst: I guess the compiler wants to spill regs there, but it can't
20:30 karolherbst: but I will have a look over these files
20:30 karolherbst: but I will likely not find anything
20:33 karolherbst: imirkin: do you want to mess around with insert_char in vt.c?
20:33 karolherbst: sounds like fun
20:33 imirkin: ;(
20:34 karolherbst: this issue looks strange
20:38 karolherbst: imirkin: could you try to print some bigger UTF-8 chars into the screen and check what happens?
20:38 imirkin: bleh, i don't even want to think about that
20:39 karolherbst: if this is messed up, then I have an idea whats going on
20:40 karolherbst: for example: if you print a lot of 2byte wide UTF-8 chars, are only group of 2 chars strange?
20:40 karolherbst: instead of 4
20:40 karolherbst: allthough, mhh
20:40 karolherbst: this should mess up the screen
20:40 karolherbst: at least the row
20:41 imirkin: this isn't a utf issue
20:42 karolherbst: I know, but maybe an array is just wrongly read, don't know
20:42 karolherbst: parsing UTF-8 is not that easy if you have to check endianess and stuff
20:42 karolherbst: or an array of "letters"
20:42 imirkin: why?
20:42 imirkin: also this all works properly with of
20:42 karolherbst: because UTF-8 chars aren't encoded in one byte, but one byte +
20:43 imirkin: perhaps something's not done in the switch to nouveau
20:43 karolherbst: ohh, okay
20:43 karolherbst: are you using nouveaufb?
20:43 imirkin: yes.
20:44 karolherbst: does it look better with another one, like , don't know what do you use as a generic fb on ppc?
20:44 imirkin: OF :)
20:44 karolherbst: I see
20:44 imirkin: but nvidiafb works too
20:44 karolherbst: mhh
20:44 imirkin: or at least did on 4.1
20:44 karolherbst: okay, then it should be a nouveaufb issue
20:44 imirkin: i guess i should check on the 4.3-pre thing
20:44 karolherbst: I don't think ppc64 will break just because of kernel update
20:45 karolherbst: others would complain pretty early, too
20:46 imirkin: yeah nvidiafb still works
20:47 karolherbst: which nouveau source are you using exactly? 1.3 already or still 1.2.2?
20:48 karolherbst: not that the cleanup just missed something, dont know
20:49 imirkin: i'm using the very latest
20:49 imirkin: nouveau's been broken on ppc for quite a while btw
20:49 imirkin: since 3.19 i think
20:49 imirkin: when the vbios stuff got broken
20:50 karolherbst: mhh
20:50 karolherbst: was it an mac os x only issue, that nvidia card needed a different vbios?
20:51 karolherbst: or gpus in general
20:51 imirkin: and it's def in the nouveau fbcon code... if i run it with nofbaccel=1 it works
20:51 imirkin: all GPUs with vbios in OF
20:51 imirkin: or at least a lot of them
20:52 imirkin: nothing to do with OSX
20:52 imirkin: everything to do with macs
20:52 karolherbst: I see
20:53 karolherbst: I had a pretty fun time reflashing one gpu once...
20:54 karolherbst: where is the fbcon source for nouveau?
20:55 karolherbst: ohh found it
21:29 imirkin: hmmm... well if i'm right this was broken since the dawn of time
21:38 mupuf: imirkin: I fixed Karol's access
21:39 imirkin: good morning :)
21:50 imirkin: hmmmm
21:50 imirkin: this was working so well but it's broken again
21:50 imirkin: i guess nvidiafb fixed something that nouveaufb misses? grrrr
21:52 mupuf: imirkin: thanks :)
21:53 mupuf: imirkin: did you see that hakzsam has been successful at reverse engineering a ton of new events from the new nvidia profiling tool?
21:53 imirkin: i think i might have been aware of that
21:53 mupuf: it is using the same ioctls as cupti
21:54 mupuf: so it is just a matter of running the same system he developped for cupti .. except manually because the gui cannot be scripted
21:57 imirkin: =/