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