02:02 gryffus: karolherbst: I'm running a 4.4.rc7 kernel right now and i can sure test some patches. I'm building git Mesa with d3d9 patches in my Open Build Service repository: https://build.opensuse.org/project/show/home:gryffus:nine So i can also add kernel with some custom patches, without problem :)
02:07 karolherbst: gryffus: nice
02:10 karolherbst: gryffus: desktop gpu?
02:11 karolherbst: gryffus: anyway, that's the patch: https://github.com/karolherbst/nouveau/commit/940452c592a94bf9216c1ef9c066f931459d497b
02:11 karolherbst: it doesn't reclock the memory, so performance gains should be rather small
02:11 karolherbst: but there
03:17 gryffus: karolherbst: yeah, it's the desktop version (GeForce GT 440 - GF106), Ok, i will test the patch and let you know
03:18 karolherbst: with 4.4 you also have to boot with nouveau.pstate=1
03:20 gryffus: karolherbst: i know that, also, is it better to use your whole fermi branch, or just the patch you sent me?
03:20 karolherbst: the patch is enough
03:21 karolherbst: the branch also does some memory stuff afaik
03:22 gryffus: karolherbst: i will try both then :)
03:24 karolherbst: well it won't work
03:25 karolherbst: neither for ddr3, nor for gddr5 cards
03:31 gryffus: oh, ok... So only the patch. Fine :)
03:34 karolherbst: RSpliet: so I could start unigine heaven with engine reclocked in 0f pstate :)
03:34 karolherbst: checking how much perf this gives me though
03:34 karolherbst: but on my card, memory 07: 405MHz, 0f: 900MHz, so there isn't much to get anyway
03:35 karolherbst: and core: 270/475
03:35 karolherbst: crappy card
03:36 KhazAkar: Hi all! Where I can find actual clock state of my Quadro NVS 160M?
03:37 karolherbst: that's a G98 right?
03:38 KhazAkar: G98M
03:38 karolherbst: well reclocking should work
03:38 karolherbst: I think
03:39 karolherbst: no idea about GDDR3
03:39 karolherbst: but you could just try it out
03:39 KhazAkar: I know,but I want to find actual state of clocking under /sys
03:40 karolherbst: /sys/class/drm/
03:40 karolherbst: and then you need to select the right card
03:40 karolherbst: device/pstate
03:40 karolherbst: if you booted with nouveau.pstate=1 that is
03:40 KhazAkar: Btw - I will use that card for Blender and Wings3D under Nouveau. // I have only that nVidia,because it's Dell Latitude E6500 :D
03:41 karolherbst: mhh, with engine reclocking: I got 6.4 instead of 5.1 fps
03:41 karolherbst: that's something
03:41 karolherbst: :D
03:42 KhazAkar: And I have a problem with It - when I close a lid,then wait ~minute and open - screen don't want to start. I need to fast close and open lid.
03:43 KhazAkar: And nouveau don't like my Ambient Light Sensor :C
03:45 karolherbst: and in a gpu core only benchmark I got nearly the same perf increase ratio as the ratio between clocks, nice
03:46 karolherbst: KhazAkar: nobody likes those yet
03:46 karolherbst: these aren't usually handled outside the video driver, because why should every video driver implement something like that?
03:46 karolherbst: your sensor just might be not supported yet
03:46 KhazAkar: But I like it - specially on night. Not supported yet? For keyboard it works,but not for screen
03:47 karolherbst: KhazAkar: can you manually change the brightness?
03:47 karolherbst: because it might be that the userspace doesn't support it too or whatever reasons there might be
03:47 KhazAkar: Sure,I can manually do it,but It's strange that only for keyboard it works,but not for screen.
03:49 karolherbst: why?
03:49 karolherbst: could be two different sensors
03:49 karolherbst: or something totally different
03:49 KhazAkar: There is only one sensor - for keyboard and screen
03:49 KhazAkar: In GRUB and BIOS it works flawlessly
03:50 KhazAkar: BTW - Can I report problem with graphics on my Quadro under Blender? :D
03:50 karolherbst: of course
03:50 karolherbst: and can you change brightness manually?
03:51 KhazAkar: Yes,I can change it manually. // On blender,the cube have visual,but not real tris cut.
03:52 KhazAkar: Under Wings 3D no problem with it,but it works sluggish
03:54 KhazAkar: Related scren for problem under blender - http://imgur.com/Qhap3Bo
03:57 KhazAkar: And how to make that voltage mod for my GTX760 in my PC? Because I have only 966 MHz on clock,but performance under wine - brilliant! ~200 FPS in FHD display with gallium-nine and forced DRI3 :D
03:57 KhazAkar: Playing Dark Sector,full details
03:59 karolherbst: KhazAkar: you would need special patches, but if you don't want to recompile your module just for that, it's not worth the effort
04:01 KhazAkar: I just want the best performance using nouveau,so recompiling module don't make me scared. :P
04:01 karolherbst: it is really just like 5% ;)
04:01 KhazAkar: Better 5% than nothing ;)
04:02 KhazAkar: I'm just waiting to possibility to use OpenCL with my Quadro and GTX card using Nouveau for GPGPU for Scilab etc :D
04:06 KhazAkar: Btw - I just made simple thing in Wings3D,then it works really slow - only 18 polygons made it sluggish.
04:08 KhazAkar: Sorry - 10 polygons.
04:08 karolherbst: nope, OpenCL shouldn't work _yet_
04:09 KhazAkar: So how about my problem with Wings3D? I more like Wings than Blender... :D
04:10 karolherbst: did you create a bug on bugzilla?
04:11 KhazAkar: Not yet. I reported a bug in bugzilla ~ year ago,when Anaconda in Fedora installer don't wanted to install fedora. :P
04:19 KhazAkar: And - how to check the clocks? I have nouveau.pstate=1,but I don't see any option about clocks under /sys/class/drm/card0
04:22 karolherbst: device
04:22 karolherbst: pstate
04:22 KhazAkar: Thanks ;)
04:24 KhazAkar: So I need to manual reclock my card?
04:25 karolherbst: yeah
04:27 karolherbst: gryffus: any luck yet?
04:30 KhazAkar: After change from 05 to 07 state Wings3D can handle even 6144 polygons,not 10 :D
04:30 karolherbst: :D
04:30 karolherbst: so it's better I guess
04:34 KhazAkar: Hi again. 0f pstate don't like my Quadro card - purple glitches and GPU hang
04:35 karolherbst: okay, but 07 kind of works
04:36 KhazAkar: Yup,07 works good. 6144 polygons instead of 10 is better :D
04:36 KhazAkar: s/is/are
04:36 karolherbst: can you give me the content of your pstate file then?
04:36 karolherbst: it shouldn't be that much of a difference actually
04:36 karolherbst: but who knows
04:37 KhazAkar: Wait a while :P
04:38 KhazAkar: http://wklej.org/id/1904443/
04:38 karolherbst: you could also try out 03 :D
04:39 KhazAkar: No no no - I don't want to have sluggish simple cube in Wings3D :D
04:39 karolherbst: :D
04:40 KhazAkar: BTW - There're any patch to have better Tesla reclock? :P
04:40 karolherbst: depends
04:40 karolherbst: which kernel are you on?
04:40 KhazAkar: 4.4.0 siduction.
04:41 karolherbst: don't think so, but I will check
04:41 KhazAkar: Thanks :P
04:42 karolherbst: nope
04:42 karolherbst: there isn't anything
04:42 KhazAkar: Yh,for 4.3 it is?
04:42 karolherbst: in 4.4 there were some gddr3 fixes
04:43 karolherbst: RSpliet: ^^
04:43 karolherbst: KhazAkar: anyway, you should make a mmiotrace with the blob
04:43 karolherbst: and mark the time where you reclock to full
04:45 KhazAkar: Ok,but not now,but if It will take a very little amount of time... :D
04:46 karolherbst: thanks
04:48 KhazAkar: A ExpressCard device shouldn't be a problem?
04:49 karolherbst: don't think so
04:49 siducer240_: HexChat lagged :P
04:52 karolherbst: hakzsam: which gpus are plugged in on reator?
04:54 gryffus: karolherbst: i must rebase it against suse 4.4 kernel, getting Hunk #2 succeeded at 195 (offset -3 lines).
04:54 karolherbst: that line doesn't matter
04:55 hakzsam: karolherbst, d9, but I'm using it right now sorry :/
04:55 karolherbst: hakzsam: k, I want to check there later if engine reclocking works
04:55 hakzsam: sounds good
04:55 karolherbst: it works on my nvc1, so chances are it works on other fermis as well
04:55 gryffus: karolherbst: yeah but Open Build Service does not allow me to continue building when some patch hunks are rejected
04:55 karolherbst: ...
04:55 karolherbst: gryffus: you could then just modify the patch and fix the lines :D
04:56 hakzsam: karlmag, yep, but you need to double-check ;)
04:56 karolherbst: but
04:56 hakzsam: err
04:56 hakzsam: karolherbst, ^
04:56 karolherbst: gryffus: offset doesn't mean rejected
04:56 karolherbst: hakzsam: yep, the expected performance improvements is there though
04:57 karolherbst: pixmark_piano speeds up like the core ratio and unigine like 33% of that
04:57 karolherbst: so it isn't as usefull as working full reclocking, but it could help some
04:58 hakzsam: yes, but the fps for heaven is still slow
04:58 karolherbst: its a crappy card
04:58 karolherbst: 630M, seriously
04:58 karolherbst: but I will test with blob :D
04:58 hakzsam: :)
04:59 karolherbst: blob seems to be around 15 fps in the first scene
04:59 karolherbst: as I said: crappy card
04:59 karolherbst: :D
05:00 hakzsam: yeah, but this is a huge performance increase
05:00 hakzsam: 6->15 :D
05:00 karolherbst: yeah well :D
05:00 hakzsam: :)
05:00 karolherbst: it was 5.1 -> 15 before
05:00 karolherbst: now it is like 6.4 -> 15
05:00 hakzsam: it's better I agree
05:00 karolherbst: pixmark piano should be close though
05:01 karolherbst: blob: 210 ms
05:01 karolherbst: before 800ms, now 500ms
05:01 karolherbst: ;)
05:01 hakzsam: karolherbst, anyway, wait for skeggsb's feedback for that series
05:01 hakzsam: nice
05:01 karolherbst: yeah
05:02 karolherbst: pixmark_piano does like no memory operation
05:02 karolherbst: it's just a shader heavy 4k instruction shader
05:03 hakzsam: okay, that explains your gain
05:03 karolherbst: yep
05:03 karolherbst: and verifies it works good enough :)
05:04 karolherbst: hakzsam: I bet other problems might be voltage related
05:04 karolherbst: like we see it on kepler
05:04 hakzsam: well, bbl, I tend to do work at work :)
05:05 karolherbst: mupuf: for my nvc1 the voltage map table is interessting: "-- ID = 7, link: ff, voltage_min = 1062500, voltage_max = 1062500"
05:06 mupuf: karolherbst: remember, min and max are wrong here
05:06 karolherbst: right
05:06 karolherbst: but they are the same values anyway
05:06 mupuf: need to have a look at what the gk20a does
05:07 karolherbst: maybe if we know what the blob uses we would know it for this special case
05:07 karolherbst: I mean we would know what to do
05:07 mupuf: I doubt it is
05:11 gryffus: karolherbst: oh, sorry, bad paste... It was Hunk 1, not 2, anyway i was able to get it to apply, with enabled fuzz, so it applied with: Hunk #1 succeeded at 187 with fuzz 2 (offset -3 lines).
05:12 gryffus: karolherbst: building it here: https://build.opensuse.org/build/home:gryffus:nine:playground/openSUSE_Factory/x86_64/kernel-default/_log
05:12 karolherbst: airlied: want to take a look at this? http://lists.freedesktop.org/archives/nouveau/2016-January/023779.html
05:17 pmoreau: karolherbst: Why would you get a compile error if you do not specify parameter name?
05:17 karolherbst: no idea
05:17 karolherbst: but kbuild did
05:17 karolherbst: got a nice message from the kbuild test robot
05:18 pmoreau: Weird…
05:18 karolherbst: ">> drivers/gpu/drm/nouveau/nouveau_debugfs.h:37:29: error: parameter name omitted"
05:19 karolherbst: I bet they treat warnings as errors or something
05:19 karolherbst: they also send the config file
05:19 RSpliet: karolherbst: yeah, I wouldn't be surprised if it fails for random cards... I only had a very small set of them to test with
05:19 karolherbst: RSpliet: I am sure it fails as randomly as on kepler
05:19 pmoreau: Well, I usually get: "warning: parameter defined but unused"
05:20 karolherbst: pmoreau: well it is the opposite case ;)
05:20 RSpliet: karolherbst: well, <G21x we're quire certain we pause the engines the right way
05:20 karolherbst: ohhh
05:20 RSpliet: because HWSQ is easier than SEQ in that regard
05:20 karolherbst: you meant the tesla thing
05:20 karolherbst: k..
05:21 karolherbst: yeah no idea then, I think the mmiotrace will tell us what nouveau did wrong
05:21 RSpliet: but that doesn't mean there are problems with the implementation I haven't see because my sample set is too small
05:21 pmoreau: karolherbst: I know, but they can't treat warning as errors, otherwise you would end up with infinite loop: have to put a name to silence error 1, but have to remove it to silence error 2…
05:21 pmoreau: Or they don't have error 2 enabled
05:22 RSpliet: an obvious problem is the "don't touch certain bits if the VBIOS indicate they never change" thing that we have for kepler, but none of the previous gens
05:22 karolherbst: anyway, I try to get this error myself
05:22 karolherbst: pmoreau: I think the best way is to specify the parameter name and then do (void)...
05:27 karolherbst: yeha lol
05:27 karolherbst: pmoreau: I don't get this error
05:27 karolherbst: ohh right
05:27 karolherbst: I fixed it :D
05:27 karolherbst: yep
05:27 karolherbst: I get an error
05:37 pmoreau: Interesting
05:37 karolherbst: pmoreau: well you need to disable DEBUG_FS to hit it :/
05:39 karolherbst: pmoreau: I think I might create a travis-ci build bot at least for my github repository then with different kernel configs
05:39 karolherbst: and if everybody likes it, we could add it to bens repository
05:39 pmoreau: Nice! :-)
05:40 karolherbst: thing is, I have no idea how to make a portable kernel config file, but I bet we could just use defaults except for stuff we care about
05:40 karolherbst: like DEBUG_FS
05:45 karolherbst: RSpliet: it is the only error I hit
05:46 karolherbst: I think, will verify it
05:58 karolherbst: yeah, it is the only error
06:02 karolherbst: RSpliet: https://travis-ci.org/karolherbst/nouveau/builds
06:02 karolherbst: :D
06:02 karolherbst: pmoreau: we could also automatically upload the binaries somewhere
06:02 karolherbst: or the kernel
06:02 karolherbst: but I don't think this makes much sense
06:07 hakzsam: I'd prefer jenkins :-) because I already know it
06:07 karolherbst: :D
06:09 karolherbst: I think this is a complete list of options nouveau checks: https://gist.github.com/karolherbst/7f63f1ae867cddd94b92
06:11 hakzsam: git grep CONFIG_ will tell you that
06:12 karolherbst: yeah I greped
06:12 hakzsam: looks fine then
06:16 karolherbst: travis is just slow as hell :/
06:17 karolherbst: a year ago you have to wait like a minute that your build starts, but now...
06:42 travis-ci: karolherbst/nouveau#5 (master_karol_no_touchy - 57cc11a : Karol Herbst): The build was fixed.
06:42 travis-ci: Change view : https://github.com/karolherbst/nouveau/compare/996d1908ec9f...57cc11a3c468
06:42 travis-ci: Build details : https://travis-ci.org/karolherbst/nouveau/builds/102113784
06:43 karolherbst: mhh
06:46 travis-ci: karolherbst/nouveau#6 (master_karol_no_touchy - 989aea7 : Karol Herbst): The build was broken.
06:46 travis-ci: Change view : https://github.com/karolherbst/nouveau/compare/57cc11a3c468...989aea7420d6
06:46 travis-ci: Build details : https://travis-ci.org/karolherbst/nouveau/builds/102114657
06:53 gryffus: karolherbst: is Unigine OK for benchmark? Or what do you use? I was looking for glmark and it's a little bit unmaintained
06:54 karolherbst: unigine is fine
06:54 karolherbst: just test each pstate and see how the performance changes
06:54 gryffus: ok
06:55 RSpliet: gryffus: any game that runs is a benchmark :-P you'll even find some interesting differences where in some games we approach the blobs perf by 90% in the highest pstate, where in others we barely hit 50%
06:57 karolherbst: what kind of sorcery is this... if [[ ! -d linux.git ]]; then git clone git://people.freedesktop.org/~airlied/linux linux.git --depth 1 --bare; else git --work-tree=linux.git fetch origin; fi
06:57 karolherbst: but linux.git doesn't exist
06:58 RSpliet: how is that sorcery? it just says "if the linux.git dir doesn't exist, clone it from Dave"
06:58 gryffus: Yeah but i would rather test some openGL bench/game and openarena seems a too lowend to me. And most of my other games are directx , so the bottleneck would be wined3d or nine IMHO
06:59 RSpliet: gryffus: mmm yeah, but Steam does have a lot of native-ish games that make for good comparison
06:59 karolherbst: RSpliet: yeah, but after that, linux.git doesn't exist
06:59 gryffus: steam uses wine AFAIK
06:59 RSpliet: karolherbst: then your git clone fails
06:59 karolherbst: gryffus: no?
06:59 gryffus: so they could be directx also
06:59 karolherbst: gryffus: there is like native steam since quite some time
07:00 RSpliet: gryffus: depends on the game, but the source engines are native
07:01 gryffus: Eh... I thought that only native thing on steam (apart from some already native games) is the (crappy) steam client itself...
07:01 gryffus: so they actually really port game engines?
07:01 karolherbst: gryffus: well there are eon based games
07:02 karolherbst: eon is also kind of wine, but different
07:02 gryffus: karolherbst: they were native even before steam
07:02 karolherbst: but most of the ports are real
07:02 gryffus: well, "native"
07:02 gryffus: ok that is new for me
07:02 karolherbst: they run like crap though
07:02 karolherbst: the eon based ones
07:02 karolherbst: and then there is stull like borderlands which runs good
07:03 karolherbst: RSpliet: https://api.travis-ci.org/jobs/102118303/log.txt?deansi=true ...
07:03 karolherbst: git clone linux.git fails
07:03 karolherbst: for whatever reasons
07:03 RSpliet: gryffus: yeah, once they had the source engine ported, the rest was a relatively straighforward job it seems (judging by the rate they kept churning out new titles on Linux)
07:04 karolherbst: ohh I think something is odd with the cache
07:05 RSpliet: karolherbst: your clone command is faulty
07:05 RSpliet: and does not correspond with the one in the if statement
07:05 karolherbst: why is that faulty?
07:05 gryffus: Well, the source engine is also another story. It has been created with linux / portability in mind... So porting was not really a hard work. It already ran on wine with native FPS before steam
07:06 karolherbst: gryffus: yeah, because there was an opengl backend
07:06 RSpliet: karolherbst: oh, hmm, you tried to check out your cloned bare repository, no that's not going to work
07:06 karolherbst: RSpliet: it works locally
07:06 gryffus: karolherbst: yep
07:06 RSpliet: why didn't you just try "git clone git://people.freedesktop.org/~airlied/linux linux.git --depth 1 --bare" remotely unconditionally and see why that fails?
07:07 gryffus: so the steam games are really a linux binaries? Without any wine code?
07:07 karolherbst: RSpliet: well I could simply not caching the stuff, right
07:07 RSpliet: I didn't inspect them, but to the best of my knowledge the Source games are linux binaries
07:07 gryffus: Last time i checked (few months) there was not a single game which ran better in steam than in wine
07:08 gryffus: in regards of FPS
07:08 gryffus: so i just gave it
07:08 karolherbst: depends on the games though
07:08 gryffus: *up
07:08 karolherbst: but there are really bad ports, that's right
07:08 gryffus: also the client is insane
07:08 gryffus: (steam client)
07:09 gryffus: and it's packaging is even worse
07:09 karolherbst: why is that?
07:09 karolherbst: it's better than uplay/origin
07:09 karolherbst: :D
07:09 karolherbst: or do you mean the linux packaging part?
07:09 gryffus: if you compare it to origin, yes :)
07:09 gryffus: linux packaging, yes
07:09 karolherbst: ohh right, yeah well
07:10 gryffus: static, embedded libraries, that's Windoze habbit
07:10 karolherbst: I have the steam runtime disabled
07:10 RSpliet: comparing it to Windows isn't fair, because then you have a good running application running on a pile of stinking rot... I'd rather have the application be sub-optimal
07:11 gryffus: i.e. Blizzard's Battle.net client (Blizzard games were also always opengl / linux / wine friendly) works much better, is faster even if it's not native
07:12 RSpliet: sorry, I'll stop my infantile jokery
07:12 gryffus: :D
07:15 gryffus: RSpliet: you maybe misunderstood me. I have the same opinion as you. But steam comes with bunch of linux libraries embedded in the huge pack, just for the slow client, i would like to use my system ones, which i know are (mostly) without backdoors etc...
07:15 karolherbst: gryffus: and this you can do
07:15 karolherbst: just disable the steam runtime
07:15 RSpliet: gryffus: I think the libraries shipped are an image from Ubuntu, in a frustrating attempt to guarantee compatibility
07:16 karolherbst: yeah, they have to ship a steam os SDK somehow
07:16 RSpliet: (which ironically break compatibility with Fedora Mesa, as their stdlibc++ is incompatible with the GCC version used to compile Mesa on Fedora)
07:16 gryffus: RSpliet: Very frustrating, at least for me. I like it even less if i know there are from *buntu
07:16 gryffus: xD
07:17 karolherbst: RSpliet: which isn't really their fault though, because games should ship all libs which aren't inside the steam_runtime
07:17 gryffus: karolherbst: disable steam runtime? Do you mean the whole steam app/shop? Or there is a possibility for steam binary to use system libraries?
07:17 karolherbst: it's maybe not a brilliant design decision, but the incompatibility only exists, if games link against something outside the steam_runtime or bundled stuff
07:18 karolherbst: I think it was STEAM_RUNTIME=0 or STEAMRUNTIME=0
07:18 RSpliet: karolherbst: mesa-libGL? sounds like a bad idea to assume the OSS drivers in the presence of nvidia's/catalyst's libGL
07:18 karolherbst: mhhh right, mesa should be system provided :/
07:18 karolherbst: then it is a bad design decision :D
07:21 gryffus: anyway, about borderlands 2 , it uses Unreal engine which was already present for Linux, so again, what really Valve ported?
07:21 gryffus: :x
07:22 karolherbst: who said valve ported anything?
07:23 gryffus: dunno, it was my conclusion when you told me that the steam does not use wine
07:23 karolherbst: yeah well
07:23 karolherbst: but valve doesn't develop those games
07:23 karolherbst: the publisher uploads there stuff on steam
07:24 gryffus: yeah, so the publishers are responsible for the porting. That makes sense, that some of the games are really a (semi)wine based
07:26 gryffus: So if valve is responsible only for the client, i would consider it fail, from design / tech PoV. But i sure appreciate the huge impact on people (mainly game publishers) view on Linux gaming
07:27 gryffus: huge/important/visionary/whatever
07:29 gryffus: karolherbst: anyway, the build is nearly finished, so let's go for testing :)
07:30 duelle: Hi there, a few days ago I created a bug report against xorg-server. Someone added a comment, stating that the issue might be related to the nouveau driver. Do I have to edit the bug accordingly or is this a thing that someone should do who has more insight in the whole projects and their relations? Here's the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=93670
07:33 hakzsam: karolherbst, are you sure that your debugfs patch really fix the build when CONFIG_DEBUG_FS is disabled?
07:36 karolherbst: hakzsam: yes
07:36 karolherbst: why?
07:45 hakzsam: karolherbst, right, my first comment was wrong
07:54 grazzolini: hi there, anyone can get vdpau working on an optimus setup? I have the firmwares installed, but everything I run anything with DRI_PRIME=1 I get segfaults
07:54 karolherbst: grazzolini: dri2 or dri3?
07:55 karolherbst: because it won't work with dri2
07:55 karolherbst: I meant
07:55 grazzolini: karolherbst: it doesn't matter
07:55 karolherbst: it won't work wiht dri3
07:55 karolherbst: dri2 should work
07:55 grazzolini: karolherbst: I couldn't make it work with either
07:55 grazzolini: karolherbst: I'll try again with DRI2, since mesa got updated recently.
08:02 pmoreau: duelle: You could change the component of the bug report to the Nouveau DDX. Apparently the fix is known, someone just need to apply it and check it.
08:21 grazzolini: karolherbst: I just tried with DRI2, same issue. if I run DRI_PRIME=1 vdpauinfo, it segfaults.
08:26 duelle: pmoreau: Ok, thanks. Then I will change it accordingly.
08:34 karolherbst: gryffus: and?
08:35 karolherbst: grazzolini: mhh no idea then, maybe it is best if you create a bug or you could check LD_DEBUG=libs or the backtrace
08:35 karolherbst: maybe it is something obvious
08:38 karolherbst: anybody experience with kernel .config file crafting?
08:39 gryffus: karolherbst: just installed, rebooting now
08:39 karolherbst: nice
08:39 grazzolini: karolherbst: yeah, I'm trying a lot of things here. but I'm starting to think it has something to do with my system's ABI change (archlinux)
08:39 karolherbst: ohhhh
08:39 karolherbst: grazzolini: check LD_DEBUG=libs then
08:40 karolherbst: it will tell you if library loading fails
08:40 karolherbst: and why
08:40 grazzolini: karolherbst: because when I do a strace, it's segfaulting on libc6
08:40 karolherbst: well
08:40 karolherbst: this happens sometimes
08:40 karolherbst: like memcpy
08:42 grazzolini: karolherbst: it is happening only when I call using DRI_PRIME=1. on the intel card it isn't happening. with the LD_DEBUG, the last lib being called is libvdpau, but the one before is libstdc++. I'm pretty sure there is a problem with the ABI change and some packages not being rebuilt
08:43 karolherbst: or run it inside gdb and get the stacktrace
08:43 grazzolini: karolherbst: but, just to be sure, if I call only DRI_PRIME=1 with vdpauinfo it should use the nvidia card, right?
08:43 karolherbst: this ABI change should produce already loading errors
08:43 grazzolini: karolherbst: assuming I have the firmware installed and everything else correct
08:54 karolherbst: .... "/bin/sh: 1: bc: not found" ....
09:04 mwk: huh, the float min/max instructions actually convert denormals to 0...
09:05 mwk: I would've thought that min(a, b) is always either a or b
09:07 karolherbst: mhh
09:07 karolherbst: weird
09:07 karolherbst: current stage of the travis-ci stuff: https://travis-ci.org/karolherbst/nouveau/builds/102149897
09:07 mwk: I wonder what min(-0, -0) is
09:07 karolherbst: :D
09:08 mwk: will find out soon enough
09:08 karolherbst: +0
09:13 gryffus: karolherbst: http://paste.opensuse.org/67921781
09:13 karolherbst: nice
09:13 gryffus: i think the bottleneck is not the GPU in this case, probably mem clock?
09:14 karolherbst: 03 is just super slow :D
09:14 gryffus: yeah, but the default is 07
09:14 karolherbst: yeah
09:14 karolherbst: you could try other tests
09:14 karolherbst: some might be not that much memory limited
09:14 gryffus: well this is openarena
09:14 karolherbst: yeah openarena has issues
09:14 gryffus: i used this demo: http://dri.freedesktop.org/wiki/Benchmarking/
09:15 karolherbst: unigine heaven is a good benchmark generall
09:15 gryffus: anholt.cfg
09:15 karolherbst: or try out if some games run better
09:15 karolherbst: it is good to know that the highest pstate runs stable though
09:15 gryffus: that's for sure
09:16 karolherbst: if the perf is only better for like 20% of all fermi gpus, but it breaks nowhere, it's fine :)
09:17 gryffus: where do you download unigine benchmarks? I cannot find download for unigine valley on their site
09:20 karolherbst: https://unigine.com/en/products/benchmarks/heaven
09:20 karolherbst: for example
09:24 gryffus: hmm maybe i'm blind but i don't see a download there
09:24 gryffus: i will download it from 3rd party, but i don't like doing that :(
09:25 grazzolini: gryffus: http://uk1-dl.techpowerup.com/Benchmarking/Unigine_Heaven-4.0.run
09:26 gryffus: yeah, that's 3rd party :))
09:31 mwk: FWIW 0 is different enough from -0 for min/max
09:33 karolherbst: nice: https://travis-ci.org/karolherbst/nouveau
09:34 karolherbst: mwk: yeah but for floating point +0 and -0 are always different :O
09:34 karolherbst: or do you also mean semantically
09:39 RSpliet: karolherbst: if you could, would you mind testing whether "my branch" didn't break Kepler reclocking? In particular, I wonder whether I didn't make a mistake moving the test patterns from gk104 to gf100
09:39 karolherbst: RSpliet: you mean this one? https://github.com/karolherbst/nouveau/commit/f454e46b9780cf605b31720cd7c61efb57528779
09:39 RSpliet: yes
09:41 karolherbst: any wishes for the CI nouveau thingy? like it should always compile against current drm-next or anything else?
09:42 karolherbst: uhhh, I think I made a mistake
09:42 RSpliet: what do you wish to gain from CI?
09:47 pmoreau: RSpliet: Running automated tests would be one thing
09:48 RSpliet: pmoreau: on what? drm-next is only going to contain nouveau updates every X months
09:48 RSpliet: Bens tree is a better candidate, if he doesn't keep too much local for long times now that the holiday season is over :-)
09:49 pmoreau: I thought he meant compiling Ben's tree against the kernel source from drm-next
09:50 pmoreau: (with "against" == "using")
09:52 karolherbst: RSpliet: seems to still work
09:53 RSpliet: karolherbst: thanks, that's very good to know!
09:55 karolherbst: RSpliet: https://github.com/karolherbst/nouveau/commit/b41e93ff5bd42125ecb872e32a9a51ee6772e44a
09:55 karolherbst: that's the script
09:55 karolherbst: I just pull drm-next
09:55 karolherbst: nouveau gets pulled into .
09:55 karolherbst: and then I just replace drm-next nouveaus with mine
09:56 mupuf: karolherbst: very nice!
09:56 mupuf: but it won't run automated test
09:56 mupuf: aside from building
09:56 mupuf: so, I would say it is of limited interest
09:56 mupuf: since Ben actually compiles his work
09:56 karolherbst: yeah, it is mainly for automated compile testing
09:56 mupuf: and I never had a build issue on nouveau
09:56 karolherbst: mupuf: he doesn't for different configs appearantly ;)
09:56 mupuf: mainly? Can it be anything else?
09:57 mupuf: yeah, I have seen that
09:57 mupuf: but Intel and oracle are doing some fuzzing
09:57 mupuf: don't worry too much about those
09:57 mupuf: build errors are simple to fix
09:57 karolherbst: yeah I know
09:57 mupuf: detecting the other types of errors is much more important
09:58 karolherbst: right
09:58 mupuf: centralising piglit reports and comparaisons would be a good start
09:58 karolherbst: ohhh right
09:58 mupuf: to do what ilia used to do on his fd.o account
10:00 karolherbst: RSpliet: what do you mean with that commit? https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/d230af49bd0e25271161a9622337b01443214ec0
10:00 mupuf:is currently testing the auto-bisect of real mesa issues
10:01 mupuf: stuff I already bisected a while back ... sort-of manually (ezbench was used for the data collection)
10:01 mupuf: but I still had to supply the good and bad commits
10:02 mupuf: now, any perf change above a certain threshold are automatically bisected
10:02 karolherbst: nice
10:03 RSpliet: karolherbst: I thought you might say that ;-)
10:03 karolherbst: :D
10:03 RSpliet: I don't have a lot of time to explain the details, but I'd say, study it and see how it change the readout of the current clock
10:04 karolherbst: ohh you mean what the pstate file tells us for example
10:04 RSpliet: the biggest change is in interpreting (ssrc & 0x100) where we previously didn't
10:04 RSpliet: but if we write, this does mean you have to verify that ssrc & 0x100 is set correctly as well
10:05 RSpliet: the bigger take-away message though is that I'm very reluctant to accept a patch that enables a feature proposed by one who doesn't know the underlying mechanism inside out
10:06 RSpliet: nothing personal, just rigor
10:06 karolherbst: yeah, I understand
10:06 karolherbst: I was just thinking it would be better to catch issues earlier
10:06 karolherbst: just to get a feeling how good that works in general
10:06 karolherbst: or how bad
10:07 RSpliet: I agree on that bit! but right now I don't think you're in a position to debug issues that may arise, because you don't *really* know what it is that you're testing
10:08 RSpliet: it's easy to get overwhelmed with feedback, better guard yourself for that situation with understanding
10:08 RSpliet: esp if time soon becomes scarse :-)
10:08 RSpliet: who k-lines gnurou?
10:09 mwk: RSpliet: I guess spammers got ahold of irccloud.com gateway and they banned the whole webchat
10:09 mwk: happens sometimes
10:10 karolherbst: RSpliet: well not for me I guess :D
10:10 karolherbst: orr
10:10 karolherbst: maybe it will
10:10 karolherbst: mhh
10:10 karolherbst: right
10:16 karolherbst: RSpliet: ahh now I understand, I should check if nouveau sets the clock according to the changes you made reading it out?
10:21 RSpliet: karolherbst: yes, and in the process learn as much as you can about the clock registers ;-)
10:21 karolherbst: ohh I already did this for the memory pll on kepler ... well sounds like fun actually
10:22 RSpliet: they're pretty similar in a lot of ways you will find :-)
10:22 karolherbst: the read_pll function ...
10:22 karolherbst: totally remembered me of the kepler one
10:26 RSpliet: Ben wrote all of that upon one of the previous rewrites, so yes, the code looks remarkably similar
10:33 RSpliet: karolherbst: on a brighter note, I am happy to hear the clock changes work as you expected, at least that means it doesn't need *that much* work :-)
10:37 karolherbst: RSpliet: right
10:38 mwk: what the...
10:38 mwk: it seems they could decide on flag-setting behavior for slct instruction
10:39 mwk: it sets the zero flag when input is 0 or 0x80000000, otherwise it sets the sign flag if high bit is set, otherwise it sets no flags
10:39 mwk: some weirdo mix of FP and integer flag-setting behavior s
10:42 karolherbst: RSpliet: I think I will code that stuff in bash again or C and then I read out all clocks on blob 07/0f and check if nouveau prints the values close to what the vbios says
10:42 karolherbst: RSpliet: anything wrong with that?
10:42 karolherbst: or did you do that already?
10:43 RSpliet: karolherbst: I think Ben probably did something like that a while ago
10:46 karolherbst: well then I think I will ask him if he is there this night, if not then I will see if I can verify that stuff this week
10:48 karolherbst: hakzsam: are you done with reator?
10:49 hakzsam: karolherbst, yes, but I would like to work again on reator later in case of you won't use it for long time :)
10:49 karolherbst: nah, just checking how engine reclockings works on the fermi card
10:49 hakzsam: have fun
10:51 karolherbst: GT 610...
10:51 karolherbst: meh
10:51 karolherbst: I was hoping for a faster card :D
10:52 karolherbst: ohhhh
10:52 karolherbst: whats up with that vbios
10:54 RSpliet: karolherbst: here's some counter-questions for you:
10:55 RSpliet: can nouveau test whether a generated clock configuration is valid? what does it do when it detects an invalid configuration?
10:55 karolherbst: mhhh good question actually
10:55 karolherbst: I think for kepler it either generates a valid one or none at all
10:55 karolherbst: or at least nouveau thinks that way
10:57 karolherbst: mhhh
10:57 karolherbst: nouveau doesn't compile on the reator kernel :/
10:57 karolherbst: hakzsam: what do I have to do?
10:57 karolherbst: or did I miss something
11:06 KhazAkar: Hi all! I think I have a solution for 2+ monitors using only one gpu
11:07 karolherbst: RSpliet: well an invalid configuration of the PLLs for gddr5 reclocking on kepler just made it run really unstable, allthough the clock was the right one
11:07 karolherbst: RSpliet: so what do you mean by a non "valid" configuration
11:09 KhazAkar: Idk if it can be made,but under Windows works Just fine
11:10 KhazAkar: Simulate/Program it.
11:11 KhazAkar: Like Windows
11:14 KhazAkar: I know It sounds strange,but I thinked about making PLL from driver-level state
11:16 KhazAkar: And search for additional help using fccID
11:17 KhazAkar: And If somebody want,I can help from "electronics" side.
11:19 ijwyn: hey everyone, I need some help with a serious issue here as I'm getting a lot of system-wide crashes and my log files constantly show 'nouveau' in the last lines
11:19 ijwyn: I've pasted stuff from 5 crashes and some additional information here:
11:19 ijwyn: http://pastebin.com/rqw8f9Ct
11:19 ijwyn: on a side note, I'm on Fedora 23 with KDE 5.14
11:23 KhazAkar: That problem exist on other DE? Name of card?
11:25 pmoreau: ijwyn: Do you have a full log using 4.2?
11:26 ijwyn: pmoreau: I only have what I pasted, but can try to get more... how would I go about it?
11:28 pmoreau: You said the system was still logging, so you could simply grab the whole log of the last boot
11:28 pmoreau: Which card do you have?
11:29 ijwyn: pmoreau: oh, you want to see the boot stuff too? sure, I can post that
11:29 ijwyn: do you mean video card? give me a sec
11:30 pmoreau: Exactly :-)
11:31 KhazAkar: Yh :P
11:35 ijwyn: pmoreau: ok, here's what came right after that, ie the reboot
11:35 ijwyn: http://pastebin.com/41nJMyzQ
11:35 ijwyn: as for the graphics card, it's onboard chip on my motherboard which is an MSI Z97 PC Mate
11:36 ijwyn: brand new, too
11:38 hakzsam: karolherbst, paste compilation errors?
11:38 pmoreau: Thanks
11:40 KhazAkar: It's not Intel integrated with cpu?
11:40 karolherbst: hakzsam: it seems to be drm updates :/ currently finding those commits
11:40 hakzsam: karolherbst, it cannot find <drm/drm.h> right?
11:40 karolherbst: no, just drm-next updates ben didn't pull yet
11:41 hakzsam: ah okay
11:41 karolherbst: I think I made it though
11:41 pmoreau: ijwyn: :-/ There is no error in that log…
11:41 ijwyn: ouch
11:42 pmoreau: Was there some GF108 fixes that went into 4.3+?
11:42 karolherbst: pmoreau: hdmi stuff
11:42 karolherbst: or was that for 4.4?
11:43 ijwyn: pmoreau: and yet everytime there's a crash the last lines in the log are nouveau-related... you think it could be something else regardless?
11:43 pmoreau: No, most likely Nouveau-related
11:44 pmoreau: Validating bo list failing on KDE rings a bell
11:44 ijwyn: ok
11:44 pmoreau: Could you try 4.4?
11:44 karolherbst: RSpliet: on the nvd9: glxspheres64: 193 fps on 07, 246 fps on 0f :)
11:45 karolherbst: hakzsam: I am done
11:45 karolherbst: seems like engine reclocking also works on the reator nvd9
11:46 karolherbst: but those are all low end gpus :/
11:47 ijwyn: pmoreau: 4.4 of what? the package I have is xorg-x11-drv-nouveau-1:1.0.12-1.fc23.x86_64 and I don't see any other listed in apper...
11:47 karolherbst: RSpliet: can you tell me when your patch is important? I mean in which situation, like is there a high clock needed, or some special clock or something?
11:47 karolherbst: ijwyn: kernel
11:47 ijwyn: oh
11:47 airlied: karolherbst: I think arnd posted a patch to dri-devel, I'll pull in
11:48 karolherbst: airlied: yeah, I know
11:48 ijwyn: I just checked, but it doesn't look they have that one available yet in the Fedora repositories, I already have the latest up on there (4.2.8)
11:49 KhazAkar: Always you can compile it :p
11:49 ijwyn: *shudders at the thought*
11:49 karolherbst: airlied: thanks
11:49 ijwyn: I've had issues with compiling in the past, so I'm a bit reluctant, especially for something as sensitive as the kernel...
11:49 karolherbst: airlied: and there is also a trivial pcie fix
11:50 karolherbst: airlied: http://lists.freedesktop.org/archives/nouveau/2016-January/023772.html
11:50 ijwyn: I'm seeing 4.3 is available on rpmfind, though... think that one would help?
11:50 pmoreau: airlied: Is there a way to get 4.4 (or at least 4.3) without compiling on fc23? Moving to rawhide maybe?
11:50 ijwyn: 4.3.3 to be more specific
11:51 pmoreau: ijwyn: It has the patch from https://bugs.freedesktop.org/show_bug.cgi?id=92504, which might be related, so worth a try
11:51 ijwyn: I do see a Rawhide package for it, but not sure if I can install that on my system
11:52 ijwyn: pmoreau: ok, yeah, I guess it can't hurt in any case ;-)
11:52 hakzsam: ijwyn, this commit should fix your issue https://github.com/skeggsb/nouveau/commit/6252ca2b03bb316483810582e0baf537fcdc1ecb
11:52 hakzsam: ijwyn, you need 4.3
11:53 pmoreau: hakzsam: Same as what I pointed out ;-) Good to get some confirmation though :-)
11:53 airlied: pmoreau: kojipkgs.fedoraproject.org/packages/kernel
11:53 airlied: might be some built in there
11:54 pmoreau: Whoah, there is even a 4.5! :-D
11:54 ijwyn: hmm, won't install 4.3.3 because of dependency issues, figures
11:54 KhazAkar: karolherbst mmiotrace would take a long time to end this?
11:55 KhazAkar: To end* w/o "this"
11:55 karolherbst: depends
11:55 karolherbst: but usually not
11:55 pmoreau: airlied: Thanks for the pointers!
11:56 KhazAkar: Ok,so I can do it now and send you a log with mmiotrace of highest clock setting and some 3d modelling,ok?
11:59 karolherbst: KhazAkar: depends, currently I think we only need some SEQ scripts out of them, but this can actually wait
11:59 karolherbst: and I don't think it will be done this month
12:01 KhazAkar: No problemo,The 07 with 6144 poly is better than 05 with 10 poly :D
12:02 karolherbst: ohh right, this was with G98
12:02 karolherbst: then we would actually need a mmiotrace I guess
12:02 karolherbst: RSpliet: or what do you say about it?
12:03 KhazAkar: Like I said - I will make it + with 3D modelling to exposure handling the clock if you want :p
12:03 karolherbst: Quadro NVS 160M right?
12:03 KhazAkar: Yup
12:03 karolherbst: RSpliet: its a g98m gddr3 card
12:08 KhazAkar: I have another idea. Mayby nouveau branch for Quadro cards only?:D
12:09 KhazAkar: To handle quadro-specific things
12:12 RSpliet: karolherbst: Sorry, I'm a bit low on time currently
12:13 RSpliet: KhazAkar: I'd be quite happy to look into it in the not-very distant future, but unfortunately I too have to strike a balance between work, life and nouveau
12:13 RSpliet: a balance easily blurred in the academic world ;-)
12:15 KhazAkar: Like me - I'm too a student,Electronics and Telecommunication. I can help only with mmiotrace and checking patches,but not write those,because I'm newbie with C :P
12:15 RSpliet: KhazAkarL I am going to need both an MMIOTrace of the official driver changing clocks back and forth a few times and a copy of your VBIOS
12:16 RSpliet: the wiki has some information on how to obtain those, and otherwise there's loads of people here to help you with it
12:16 KhazAkar: Ok,Now I will make mmiotrace with max performance state + some 3d modelling,ok?
12:16 RSpliet: 3d modelling is not required, I would like to see a trace of the official driver hitting all performance states though
12:17 KhazAkar: Ok,no problem. Just Say if something is needed
12:17 RSpliet: (play around with nvidia settings, in particular playing switching between the "max performance" and "adaptive" policies is a good way to get the blob to change it's clocks)
12:17 RSpliet: well tht
12:17 RSpliet: I have to go though
12:17 RSpliet: bbl
12:18 RSpliet: and, just to clarify, trace of nouveau is not what I'm after; I can reproduce that from your VBIOS ;-)
12:22 KhazAkar: I cannot make mmiotrace, because /sys/kernel/debug/tracing/current_tracer doesn't exist :(
12:23 KhazAkar: Whole tracing folder doesn't exist
12:24 pmoreau: You need to mount debugfs
12:25 KhazAkar: Mounted
12:29 KhazAkar: It's mounting automatically on my laptop
12:29 KhazAkar: But nothing about tracing
12:31 KhazAkar: Even with that I cannot help,eh :(
12:31 pmoreau: Do you have `CONFIG_MMIOTRACE=y` set in your kernel's config?
12:32 KhazAkar: Idk,becsuse It's default kernel in distro which I'm using
12:32 KhazAkar: Probably not
12:33 pmoreau: You could have a look at /proc/config.gz
12:34 KhazAkar: Ok,So I need to reboot my machine
12:38 KhazAkar: Now I cannot reboot my notebook after installing blob,yh
12:39 mwk: I wonder if I missed any funny special cases in that code
12:39 KhazAkar: How to disable blob in kernel parameters on grub?
12:40 mwk: although the testcases are reasonably good, they exercise every combination I can think of
12:40 mwk: well, time for fmul, let's see what the sat modifier is all about
12:59 mwk: imirkin_: yep, hwtest confirms fmul.sat ignored on G98
12:59 imirkin_: mwk: cool :)
13:00 imirkin_: iirc rendering in portal did too :)
13:00 mupuf: imirkin_: so you had to generate code to saturate the result then?
13:01 imirkin_: mupuf: more like not fold the separate sat into the fmul :)
13:01 mupuf: ah, I should have guessed there would be a sat instruction :p
13:01 imirkin_: mupuf: well, there's a f2f convert instruction which can saturate an input
13:01 mupuf: is the backend SSA btw?
13:02 imirkin_: mupuf: yep
13:02 mupuf: ok, cool, so you can detect a fmul + f2f then
13:02 imirkin_: mupuf: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp#n1469
13:03 mupuf: lovely
13:10 mwk: so that leaves... mul-add, quadop, and short/immediate forms
13:13 imirkin_: mwk: are you also checking flags state?
13:13 mwk: imirkin_: yep
13:13 mwk: pretty boring, except for slct
13:13 mwk: which has really weird rules btw
13:15 mwk: I'm not checking allowable input files in this round, though
13:15 mwk: ie. whether shared/attr/const/whatever are allowed
13:15 imirkin_: right
13:17 mwk: I can't wait till I get to port this to Fermi
13:17 mwk: it should be much more useful there
13:17 ijwyn: alrighty, I managed to upgraded to kernel 4.3.3 and rebooted... crossing fingers now!
13:17 ijwyn: *upgrade
13:17 ijwyn: thanks for the help, everyone
13:18 imirkin_: mwk: are you planning on updating the isa docs?
13:18 mwk: imirkin_: certainly
13:18 imirkin_: cool :)
14:16 danofsatx: any tips on getting steam to work with nouveau?
14:16 imirkin_: danofsatx: perhaps you can elaborate as to the issues you're seeing?
14:16 danofsatx: http://fpaste.org/310472/45272340/
14:17 danofsatx: sorry, wasn't quick enough with the fpaste ;)
14:17 imirkin_: do you have 32- and 64-bit nouveau_dri.so?
14:17 danofsatx: When I attempt to start it, that's all I get.
14:17 mwk: imirkin_: you wouldn't happen to know anything about rounding modes for the fp32 mul-add insn, would you?
14:17 KhazAkar: Hi again. I can give only vbios on the current state,but Nouveau is rock solid when I launched OpenSCAD example animation with enormous integers
14:17 danofsatx: hrm, that's a good question, I may not. let me check
14:17 imirkin_: danofsatx: a common issue is that steam includes an old libstdc++.so.6 -- if you just remove it
14:17 imirkin_: then all is wel
14:18 imirkin_: danofsatx: i mean... if you remove the libstdc++.so.6 that's inside the steam runtime things
14:18 KhazAkar: Even if simple robotic arm or example of architecture gives me only ~150 fps on 07 state :P
14:18 imirkin_: mwk: nope!
14:19 mwk: I have a funny feeling it's not *quite* a mul with add
14:19 imirkin_: mwk: i assume it's fma...
14:19 imirkin_: mwk: it's FFMA in nvdisasm
14:19 mwk: IIRC I tested for that long ago
14:20 mwk: and it didn't match
14:20 danofsatx: that worked! Thanks imirkin_
14:20 mwk: but
14:20 mwk: that's simple enough to check
14:21 imirkin_: danofsatx: cool. enjoy :)
14:21 karolherbst: airlied: thanks for merging the both patches
14:23 KhazAkar: I must praise(? sorry if I made a misspelling there,English aren't my native language) your work guys with drivers.
14:23 mwk: imirkin_: it's not an FMA
14:24 mwk: 0x3f800001 * 0x3ffffffe - 0x3fffffff computes to exactly 0 with it
14:24 mwk: FMA would preserve all the low bits
14:24 karolherbst: KhazAkar: do you still have issues with something?
14:24 karolherbst: KhazAkar: we could at least fetch your vbios already
14:25 imirkin_: mwk: how do you check the results quickly? numpy?
14:25 KhazAkar: Only "mid" perf,but it is really good. Wait,I must relaunch my notebook to give vbios
14:25 imirkin_: mwk: or are you just familiar enough with the bit encodings that you can do it in your head? :)
14:25 mwk: imirkin_: I am
14:26 mwk: I just wrote a software implementation of IEEE-compliant mul & add, so...
14:26 imirkin_: hehe ok. i am not :) need to refigure out how to do all the bitcasting in numpy
14:26 mwk: struct.pack/struct.unpack
14:26 imirkin_: yeah... but... hm
14:26 mwk: works without numpy
14:28 imirkin_: mwk: so that result would be a denorm though, right?
14:28 mwk: nope
14:28 KhazAkar: Now I cannot,afk for a while. (It is in /sys/class/drm/?)
14:28 imirkin_: and i think nv50 auto-flushes all denorms
14:28 mwk: it's something like 2**-23
14:28 imirkin_: KhazAkar: /sys/kernel/debug/dri/0/vbios.rom
14:28 mwk: perfectly representable
14:28 mwk: without denorms
14:28 imirkin_: hmmmm ok
14:28 KhazAkar: Thanks,Now afk for a while.
14:31 mwk: hmm
14:32 mwk: I think I get it
14:32 mwk: there is an intermediate rounding, but not exponent reduction
14:32 mwk: as in, stuff only overflows to inf/underflows to 0 after the sum
14:33 mwk: ugh, I'll have to make a separate function for it
14:35 mwk: hmm or not, there's still weirdness
14:36 KhazAkar: K,I'm on. Wait a while,I will give my vbios from Quadro NVS 160M
14:36 mwk: screw it, I'll start with a new function
14:36 KhazAkar: https://www.sendspace.com/file/v1ycu3
14:37 KhazAkar: ^ vbios.rom from Quadro NVS 160M
14:38 mupuf: mwk: ah ah, it was bound to happen, crazy approximations that are hard to guess :)
14:41 karolherbst: KhazAkar: G98 right? :D
14:41 KhazAkar: G98M :P
14:41 karolherbst: KhazAkar: and could you install envytools and do a nvapeek 101000
14:42 KhazAkar: My siduction don't know nothing about envytools... :D
14:42 KhazAkar: = Not found
14:43 karolherbst: you can always build from git though
14:44 KhazAkar: ATM I have loaded and installed only nouveau,not blob.
14:44 KhazAkar: But wait,I need to download that envytools
14:44 karolherbst: KhazAkar: https://github.com/envytools/envytools
14:46 KhazAkar: karolherbst even helping aren't so easy :D
14:46 karolherbst: mupuf: where will you run those automatic tests?
14:47 mupuf: karolherbst: I was considering adding new machines (2 laptops)
14:47 karolherbst: k
14:47 karolherbst: keep in mind that we might want to have some POST URLs for that
14:47 mupuf: because REing on them is not really possible
14:47 mupuf: what do you mean?
14:47 karolherbst: like we could have some git post-commit hooks to automatically build and test branches
14:49 karolherbst: well maybe less for mesa, because that's most likely not in our control, but at least for the kernel module
14:52 KhazAkar: If somebody want a package with envytools for debian - I can send it :P
14:53 karolherbst: KhazAkar: well the thing is, there is no release
14:54 mupuf: karolherbst: polling is fine :p
14:54 KhazAkar: I know,but It doesn't make impossible to compile a package with timestampes like gEDA team do this on their ppa
14:54 mupuf: but better, we can test patch series from emails
14:54 karolherbst: mupuf: k then mesa get polled and bens github repository can give the machine a POST request :p
14:54 karolherbst: ohhh right
14:54 mupuf: thanks to the awesome work do damien lespiau!
14:55 mupuf: I just need to ask him to create a new project on patchwork
14:55 mupuf: and we should be in business :p
14:55 karolherbst: anyway, I go to bed now :p, nighty
14:55 karolherbst: :D
14:55 mupuf: night!
14:55 KhazAkar: Good night!
14:55 karolherbst: mupuf: or we jsut do PRs on github which mail notifications and IRC notigfications :D
14:55 karolherbst: or both
14:55 karolherbst: or everything!
14:55 KhazAkar: even clearnet? :D
14:56 mupuf: ah ah
14:56 imirkin_: github pr's are the worst
14:56 mupuf: we'll see
14:56 imirkin_: so... hopefully not
14:57 KhazAkar: I will make that command "nvapeek 101000" tomorrow,because It's 23:56 now in my country :D
14:57 KhazAkar: Good night all!
15:04 mwk: eh
15:04 mwk: I don't get it
15:44 RSpliet: mupuf: btw, I assume that that sat instruction is actually a mov with the sat modifier set
15:46 mwk: RSpliet: it's actually a float-to-float conversion instruction
15:56 mupuf: my god, HDDs are unbearably slow....
15:56 mupuf: I am updating my nvd9 laptop and it installing them slower than it downloaded the packages
16:50 mwk: okay, fmac is... quite damn annoying
16:51 mwk: it definitely rounds the intermediate multiplication result to 24 bits, but how exactly it happens seems to depend on the third operand
17:52 imirkin: skeggsb: are you able to run CTS tests?
17:53 imirkin: skeggsb: or rather, to rephrase, could i convince you to figure out how to run CTS tests?
17:53 skeggsb: what are these tests?
17:53 imirkin: khronos-supplied tests, sorta like piglit
17:53 imirkin: which you (well, RH) has access to
17:53 imirkin: i know airlied has run them in the past
17:54 skeggsb: ah, right, there's also some android cts thing, so i was confused :P
17:54 karolherbst: please remember me the next time to never use ubuntu for any kind of machine ...
17:54 imirkin: there's also dEQP, which i can run myself
17:54 imirkin: but that tests GL ES 2.0, 3.0, and 3.1
17:55 imirkin: but CTS is the khronos suite which you only get access to if you're a member of the club
17:55 imirkin: and is the suite that all other drivers are validated against
17:56 skeggsb: i recall airlied complaining that the test suite kinda sucks in some ways
17:56 imirkin: yeah, from what i hear it's horrible
17:56 imirkin: (which is probably also from airlied complaining...)
17:56 imirkin: but... it has tests for things that other test suites don't have
17:59 imirkin: anyways, if it's some huge thing to work out, don't worry about it...
17:59 imirkin: but i figured that since airlied had worked it out, you could do it too
18:00 skeggsb: i've just built it, and getting "ERROR: std::bad_cast" trying to run tests..
18:00 imirkin: i think that's the "horrible" bit of it :)
18:01 karolherbst: :D
18:02 karolherbst: that's just fine... now my fermi machine just seems to be dying for no apperant reasons :/
18:04 imirkin: skeggsb: unrelatedly, does that ddx patch look fine? http://lists.freedesktop.org/archives/nouveau/2016-January/023786.html
18:04 skeggsb: airlied: ^^^
18:04 skeggsb: imirkin: yeah. you can commit to that yeah?
18:04 imirkin: ya
23:36 karolherbst: Tom^: update your tom branch ;)
23:36 karolherbst: I think the dyn reclock issues you got should be solved now