00:40 hakzsam: imirkin, nice job!
03:28 karolherbst: mupuf: could it be that ptherm sets up the fsrm stuff?
03:29 karolherbst: because just by loading nouveau the fsrm config regs just change
03:29 karolherbst: and usually there is nothing about the two config regs inside the traces
03:29 karolherbst: except two writes for my card
03:31 karolherbst: mupuf: vbios script: 0x9bf6: 02 00 00 00 R[0x02010c] = 0x00000002
03:31 karolherbst: this is the divider value for the low threshold
03:31 karolherbst: "0x9c14: 66 60 66 00 R[0x020074] = 0x00666066" and this is the other FSRM config reg
03:33 karolherbst: mupuf: also the thresholds are all in the script :/
03:34 karolherbst: but with higher values than used by the blob though
03:34 mupuf: karolherbst: good to know that those are set by the init script!
03:35 mupuf: so, we likely do not have to touch anything bit the threshold
03:35 karolherbst: 0x02041c seems to be some kind of threshold too by the way
03:35 mupuf: we can still add a check and complain if the values are unset and set some sane default
03:35 mupuf: s
03:36 karolherbst: gets the same value as 0x0204d8 though
03:36 karolherbst: yeah
03:36 karolherbst: but the blob reduces those values a bit
03:36 mupuf: and we need to do the same
03:36 karolherbst: crit is set to 6e by the script
03:36 karolherbst: 110°C
03:36 karolherbst: this is a bit high :D
03:37 karolherbst: blob reduces that to 68
03:37 karolherbst: 104°C
03:38 karolherbst: will check other kepler cards then
03:38 karolherbst: and then we should use the lowest value -3 or something
03:39 mupuf: try to find those values in the vbios first though
03:39 karolherbst: well that is easy though
03:41 karolherbst: most of the cards have either 6d or 6e set as crit
03:41 karolherbst: meh
03:41 karolherbst: maxwell cards don't have this in the script anymore :/
03:41 karolherbst: seems to be different there again
03:41 karolherbst: also nvf1 doesn'T seem to contain it
03:42 karolherbst: so I can only implement this for nve* first then :/
03:42 karolherbst: bother
03:43 RSpliet: the life of a PM dev isn't all about roses
03:43 karolherbst: well I would go for 95/97/100 °C then
03:43 karolherbst: the vbios just has insane high values
03:43 karolherbst: something like 105/107/110 in the normal case
03:44 RSpliet: but it's for a good cause; on the dark proprietary side of things I just learned that TK1 will not get an upgrade to Cuda 7 toolkit, bearing features critical for stuff like the upstream caffe neural network suite. At least we care about backwards compatibility to a reasonable extent ;-)
03:44 karolherbst: at least nvc has the values
03:45 karolherbst: :D
03:45 RSpliet:hands pmoreau some carambars to motivate him for his OpenCL work some more :-)
03:46 karolherbst: :D
03:46 pmoreau: RSpliet: Hand me a setup where Mesa will build alongside LLVM and I'll be happier! ;-)
03:46 mupuf: RSpliet: since where are there carambars in the UK?
03:46 RSpliet: pmoreau: anything non-ubuntu should do the trick right?
03:46 RSpliet: mupuf: oh, Amazon .fr would do right? :-P
03:46 mupuf: probable :D
03:46 RSpliet: surely they ship to Sweden?
03:47 karolherbst: mupuf: it seems like that some fermi cards use the fsrm like I see that on kepler :/
03:47 pmoreau: RSpliet: I'm still fighting the ABI change in GCC…
03:47 RSpliet: pmoreau: oh is that the "you need GCC 4.6 to be interoperable with clang" shizzle?
03:47 karolherbst: 0x00666066 in the CFG_5 reg on a nvc1 card
03:47 karolherbst: usually fermi has 0x00000026
03:48 karolherbst: and only kepler gets 0x00666066 set
03:48 karolherbst: mehr
03:48 karolherbst: *meh
03:48 pmoreau: RSpliet: Maybe not 4.6, but older than 5.3 for sure. :-) 5.2 seems to improve a bit, but I got another "undefined reference" instead…
03:48 karolherbst: mupuf: found out how we can check what "type" of fsrm is built on the gpu die?
03:48 karolherbst: :D
03:48 mupuf: karolherbst: I will be on vacation starting from thursday
03:48 mupuf: at this point we can work on this issue
03:48 karolherbst: ohh okay
03:48 mupuf: what do you mean by type?
03:48 karolherbst: well
03:49 karolherbst: if the fsrm has to be configured like a kepler one or like and older one
03:49 RSpliet: pmoreau: just build all of mesa and libdrm with clang instead :-P
03:49 RSpliet: clang all the things!
03:49 karolherbst: maybe it is the same though
03:49 karolherbst: no idea
03:49 pmoreau: RSpliet: That's what I've been doing… Except if Mesa decided not to respect my choice for CC and CXX
03:49 RSpliet: pmoreau: bug xexaxo about those kind of issues :-)
03:50 karolherbst: mupuf: I will just concentrate on nve* for now
03:50 pmoreau: RSpliet: Eh eh eh :-)
03:50 karolherbst: because with fermi cards we won't hit any heat issues for now
03:50 pmoreau: Will do after lunch then :-)
03:50 mupuf: karolherbst: well, there is likely a way to configure which thresholds the fsrm is going to use
03:50 pmoreau: RSpliet: BTW, if you want to test hello_world on one of your cards: https://phabricator.pmoreau.org/F15369
03:51 mupuf: karolherbst: RSpliet made progress on fermi reclocking this weekend
03:51 karolherbst: mupuf: well for my card I am pretty sure how to configure the fsrm the way I want it to be configured, except I don't think I would be able to configure it right without the init script
03:51 karolherbst: yay
03:52 pmoreau: RSpliet: I think it should work on Fermi+, but I haven't tested on them and I haven't been able to check the generated code for them since I have some troubles building Mesa. :-/
03:52 mupuf: karolherbst: look for a table that would contain those infos and check mmiotrace to see if the values are constant
03:52 mupuf: if they are, hardcoding them is fine
03:53 mupuf: but fact that the script sets stuff differently likely means that there is a table containing this value, otherwise, the script would set the right value to begin with
03:54 karolherbst: right
03:54 karolherbst: but I don't really feel like searching the vbios for values like 0x68 and check every occurance :D
03:54 karolherbst: maybe I am lucky and find it right away
03:58 RSpliet: mupuf, karolherbst: I'm constantly making iterative progress, but nothing tangible yet
03:59 mupuf: karolherbst: it should be in unk tables or the thermal table
03:59 karolherbst: mupuf: UNK50 would be like the best candidate for that :/
04:00 mupuf: why?
04:00 mupuf: it is likely before it, but hey, can't talk right now
04:00 karolherbst: because there are other temperatures in it
04:00 mupuf: can't speak until thursday, basically
04:00 karolherbst: k
04:00 mupuf: the finnish exam is going to be a pain :s
04:01 karolherbst: have fun
04:02 mupuf: thanks, and to make matters worse, I have lost one book, which does not help for reviewing
04:02 karolherbst: you will be fine
04:03 pmoreau: mupuf: Lycka till! Swedish exam in January for me :-)
04:04 mupuf: Hyvää onnea!
04:04 pmoreau: :-D
04:05 pmoreau: Kiitos ;-)
04:05 mupuf: Tak :p
04:05 mupuf: that's one of the few words I know in Swedish
04:05 mupuf: even if I am surrounded by it in Finland, as it is the second official language
04:06 mupuf: you won't be lost for XDC2016!
04:06 mupuf: during*
04:06 pmoreau: \o/
04:07 pmoreau: I just hope XDC will be before the labs start here, otherwise I most likely won't be able to come.
04:07 mupuf: 21-23 September
04:07 pmoreau: :-/
04:08 mupuf: I am sure you will be able to attend :p Just bribe your supervisor!
04:08 pmoreau: Well, that means he would have to look for another lab assistant for one lab
04:09 pmoreau: And given that most of the PhD students of the group would have left, it might get quite tricky.
04:09 mupuf: that means he has no contingency plan for the case where you are sick, not cool
04:10 pmoreau: We'll see, there's still time before XDC. :-)
04:14 pmoreau: BTW, I'll move in a new apartment beginning of January, so I'll soon be able to setup a reator and plug in all my cards (960 included) :-)
04:14 sooda_: suomi on helppoa!
04:16 sooda_: is the xdc venue determined yet?
04:17 mupuf: sooda_: thanks for making me depressed, I don;t even get why I would need to use the partitive on helppo here :D Either this is a rule I haven't seen or I just forgot this one. In any case, isn't funny that saying "Finnish is easy" is actually difficult? :D
04:17 mupuf: yes, it is!
04:17 mupuf: Haaga-Helia university
04:18 mupuf: I already warned Lori, I guess he did not forward the event information yet. Probably waiting on the date.
04:18 sooda_: a coworker of mine was having some finnish lectures a year or two ago. i'll never forget his face when someone just asked how it's going and jokingly continued "suomi on helppoa!"
04:19 sooda_: he seemed sort of depressed and just responded "goddamn no it's not" or something
04:19 mupuf: by warned, I meant told*
04:19 sooda_: ah okay cool
04:19 sooda_: if you didn't have a venue, i would've suggested startup sauna in otaniemi :P
04:20 sooda_: (not actually a sauna, that's just a name.)
04:20 mupuf: it is not super easy to reach, and we will have a big amphitheater
04:20 mupuf: IIRC, 300 seats
04:20 sooda_: whee
04:21 mupuf: we'll see how much we can fill it
05:01 tagr: mlankhorst: what kinds of errors are you seeing? underruns of some sort?
05:05 mlankhorst: tagr: no just getting -EPIPE it seems
05:05 mlankhorst: from that log
05:05 mlankhorst: no idea why
05:05 tagr: mlankhorst: is that a USB webcam?
05:06 mlankhorst: yeah
05:07 tagr: mlankhorst: if the webcam works on some other setup I'd suspect that it's Tegra's USB support that's doing this
05:07 tagr: perhaps it's too slow or something
05:08 tagr: I think I've seen USB 2.0 work at roughly what I'd expect, but you never know
05:13 mlankhorst: tagr: it works initially, this is after a few hours..
06:04 karolherbst: mlankhorst: could be a linux issue itself though or usb driver. I also have some strange connection issues with my usb mouse adapter
06:04 karolherbst: mlankhorst: does reconnecting helps? :D
06:04 mlankhorst: karolherbst: no idea, dont like those mbox errors
06:07 RSpliet: karolherbst: strange issues with mouse adapter sounds like USB power saving problems
06:07 RSpliet: or, that's what I experience with L4T
06:07 karolherbst: it is a logitech usb receiver
06:08 karolherbst: I kow those power savings problems so I disabled power savings for my usb mouse entirely :D
06:08 RSpliet: yeah, that's what I did with a udev rule
06:08 karolherbst: I don't want to wait a second until I can use my mouse
06:08 karolherbst: no, sometimes I get some usb read errors from the bus
06:09 RSpliet: okay
06:09 RSpliet: that I haven't encountered yet, but I've only ran the proprietary stuff
06:09 RSpliet: (for cuda reasons)
06:10 karolherbst: stuff like "usb 1-1: device not accepting address 101, error -71"
06:11 karolherbst: or "usb 1-1: device descriptor read/all, error -110"
06:24 xexaxo: pmoreau: should work (re: mesa + CC and CXX variables). it's been a while since I've tested it though
06:24 pmoreau: xexaxo: Too bad, it would have been an easier fix otherwise. :-D
06:25 xexaxo: pmoreau: what's the problems again ? Had a quick look at the backlog and I've missed it :\
06:26 pmoreau: I can't compile clover any longer with LLVM due to GCC changing its C++ABI, even when using clang to compile Mesa.
06:26 pmoreau: s/clover/Mesa
06:26 pmoreau: s/with LLVM/with LLVM enabled
06:28 xexaxo: I take it that you're trying to follow the Arch's recommendation - rebuild everything :P
06:28 pmoreau: It's a known issue on the LLVM side since September, but they don't seem to care much about fixing it. And I haven't been able to workaround it.
06:28 xexaxo: but seriously is it chocking up at one of those "we chose to break the ABI for some well known types/objects - aka string and alike" ?
06:29 pmoreau: I didn't rebuilt everything! :-D But I did rebuilt LLVM + clang + Mesa. Should I rebuild more than that?
06:29 xexaxo: not suggesting any of it, just curious.
06:29 pmoreau: Ok
06:30 pmoreau: It fails with a "undefined reference to `std::string llvm::sys::getProcessTriple()`
06:30 xexaxo: and the LLVM issues that you're talking about brings back memories... was it the lack of tagged symbols in their project... ?
06:31 pmoreau: https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg97273.html
06:31 pmoreau: With the LLVM bug report https://llvm.org/bugs/show_bug.cgi?id=23529
06:32 pmoreau: I haven't tried using libc++ instead of libstdc++, worth a try I guess
06:32 xexaxo: I'm curious of one cannot explicitly select the old version of list/string. currently things (likely) expand to std::__cxx11::string
06:33 urjaman: mupuf: btw, we usually (AFAIK...) just say "Onnea!" ... i dont even know why and i'm supposed to be native in this thing...
06:34 xexaxo: pmoreau: have you found anything like the above ? i.e. build with -std=c++11, yet opt out for the old ABI.
06:38 pmoreau: I'm building with c++11 but haven't said anything about the ABI, so it seems like clang is trying to use the new one.
06:38 pmoreau: Trying to lookup how to set the old one
06:39 pmoreau: Let's see if _GLIBCXX_USE_CXX11_ABI=0 helps
06:40 xexaxo: pmoreau: was about to suggest the same thing :)
06:40 pmoreau: ;-)
06:42 xexaxo: you might also want to throw in -Wabi-tag ... to admire how many issues will get hightlighed
06:42 pmoreau: I like how in the article he said Arch wouldn't switch until clang was fixed, and yet they did and clang is still broken. :-D
06:42 xexaxo: *highlighted
06:43 xexaxo: the wonders of using Arch ;-)
06:43 pmoreau: I expect -Weverything to be quite noisy as well :-)
06:43 karolherbst: xexaxo: the ABI isn't broken
06:43 karolherbst: xexaxo: you can use the CXX11 and the CXX98 ABI in one application
06:44 karolherbst: just llvm does something a bit shady
06:44 xexaxo: also the sad part about llvm/clang - serious issues like these take a long time to sort out :-\
06:44 karolherbst: yeah
06:44 xexaxo: karolherbst: should have added some quotes around break. my bad
06:45 xexaxo: karolherbst: I take it that one can mix the two ABI by toggling the above _GLIBCXX... define ?
06:46 karolherbst: xexaxo: not only that, you can link against cxx libraries with different ABIs
06:46 karolherbst: as long as you use the object of one ABI with the right "functions" it is all fine
06:46 karolherbst: the std::string object differs between ABIs so you have to be aware of that a bit
06:46 xexaxo: grep _GLIBCXX_USE_CXX11_ABI -> foo.cpp #define _GLIBCXX_USE_CXX11_ABI 1, bar.cpp #define _GLIBCXX_USE_CXX11_ABI 0 :)
06:47 karolherbst: the CXX11 abi just adds this "cxx11" attribute thingy into the symbols, so all stays compatible
06:48 xexaxo: heh "thingy"... haven't seen many people using that one :P
06:48 karolherbst: xexaxo: you can still create a std::__cxx11::string object when you disable the CXX11 abi ;)
06:49 karolherbst: you just have to call the right functions thenn yourself
06:49 karolherbst: well it isn't a namespace in fact
06:49 karolherbst: ohh wait
06:50 karolherbst: they use namespaces and this new tag thingy
06:50 xexaxo: karolherbst: thanks for the suggestion. I'd opt out fttb :-)
06:50 karolherbst: [abi:cxx11]
06:50 xexaxo: *out of C++ sources
06:50 xexaxo: waiting for all the dust to settle
06:50 karolherbst: xexaxo: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html abi_tag
06:53 karolherbst: this is also interesting, but I beat you already found that: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
06:53 pmoreau: Yep :-)
06:54 karolherbst: so somebody would write a macro and then do something like dual_abi_usage(std::string bla_func(const std::string &){ //code }) or something
06:54 pmoreau:should send some patch to silence some warnings in Mesa, like returning a const value
06:57 xexaxo: I'd imagine the real issue is that llvm should somehow say if they're using 0 or 1 in their build... unless I've missed it in the output of llvm-config
06:57 karolherbst: mhh
06:57 karolherbst: it shouldn't matter in fact, because the std::string thing is tagged with the ABI
06:58 karolherbst: there is somewhere a llvm patch so support the gcc abi_tag thingy
07:00 pmoreau: I couldn't see any changes when I applied the patch. I could have messed up something in between though.
07:01 pmoreau: The issue (from what I understand) is that clang can't demangle the name tagged with the ABI, or does demangle it to some different name
07:01 karolherbst: pmoreau: this is a clang thing
07:01 karolherbst: this allows the compiler to read the gcc abi_tag
07:02 karolherbst: it still produces a compiler error when you use a old std::string for a std::__cxx11::string argument
07:06 karolherbst: there are like 4 combinations now of "c++" applications: pre CXX11 api or CXX11 api combined with pre CXX11 ABI or CXX11 ABI
07:06 karolherbst: and if you try to combine libraries/applications with different abis, the abi_tag prevents "strange" behaviour due std::string and std::list being different across both ABIs
07:07 karolherbst: if the compiler wouldn't fail to link that, it would jsut link different ABIs together
07:08 karolherbst: now if one library wants to stay compatible with both ABIs inside one binary, each function using std::string/std::list would have to proviude two implementations, one for each ABI (which can be easily be done through a macro)
07:57 karolherbst: how gets the script executed on the ptherm by the way?
08:14 karolherbst: mupuf: something, I don't know what, but something sets the thresholds with nouveau like they are with teh blob :O
08:14 karolherbst: yay :D no work to do, just checking if the values are somewhat sane
08:15 karolherbst: ohhh
08:16 karolherbst: there is a mask later in the script
08:17 karolherbst: but why...
08:17 karolherbst: this doesn't make any sense
08:17 karolherbst: can anybody help me to understand why this makes sense? https://gist.github.com/karolherbst/f1ecbd746561dc5a227a
08:17 karolherbst: I mean why setting the value if it gets masked later anyway
08:32 RSpliet: see that little squiggly sign in front of the mask? :-)
08:33 karolherbst: RSpliet: I didn't mean what the mask does, I mean why is the value set and then masked later?
08:33 karolherbst: wouldn't it make more sense to just set the result in the first place?
08:34 karolherbst: or does this mask do more than just changing the value?
08:38 RSpliet: well, no, it does look a bit silly, but that's what you get when OEMs copy-paste scripts together
08:39 RSpliet: ZM_MASK_ADD R[0x0204e8] & ~0xffffff00 += 0x00000000 seems to be even more pointless
08:39 karolherbst: :D
08:39 karolherbst: right
08:39 karolherbst: okay so this is most likely because of a nvidia tool for OEMs and they just didn't bother to optimize this
08:40 karolherbst: okay
08:40 RSpliet: likely, I wouldn't worry about it too much
08:40 karolherbst: that means the FSRM is already configured for most of the gpus already
08:40 karolherbst: good news
08:41 karolherbst: some nva cards also have this
08:41 karolherbst: and some nv94 cards :O
08:42 RSpliet: I forgot what FSRM stands for, is that the clock-slashing mechanism under high temperatures?
08:43 karolherbst: yes
08:43 karolherbst: on my gpu it is able to cut power consumption under full load by half
08:44 karolherbst: the voltage stays the same though
08:44 karolherbst: mhh okay, seems like I have to implement this for cards from g94 and newer
08:44 RSpliet: ah, so it's not the block-level clock gating? :-P yeah, I reckon it can make a difference, but you pay a penalty in performance I reckon
08:45 karolherbst: RSpliet: yes :D
08:45 karolherbst: a big one
08:45 RSpliet: the trick is to get the temperature threshold set properly
08:45 karolherbst: with the highest "divider" 862MHz => 101MHz
08:45 karolherbst: RSpliet: there is a script in the vbios which does that already
08:45 karolherbst: the thresholds are already setup
08:45 karolherbst: also the fsrm config
08:45 RSpliet: ah good
08:45 karolherbst: there is nothing to do
08:45 karolherbst: just
08:45 karolherbst: we should check if this is setup in a sane way
08:46 RSpliet: I think the NV50 reclocking routines also successfully disable/enable it upon reclocking
08:46 karolherbst: well I don't see the regs used for nv8x cards in the vbios
08:46 karolherbst: so I will concentrate on the mechanism I find on my card first
08:47 RSpliet: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/clk/gt215.c <- clk_pre and clk_post
08:47 karolherbst: there is even a g94 card which works exactly like mine here :/
08:48 RSpliet: was it 20060? :-P can't remember any more, too long ago
08:48 RSpliet: too many beers
08:48 karolherbst: FSRM_CFG_=
08:48 karolherbst: 0
08:48 karolherbst: but I take a look at FSRM_CFG_5
08:48 karolherbst: RSpliet: this stufF: https://gist.github.com/karolherbst/1854da8068b510d4cc14
08:49 karolherbst: though I have no clue what the PTHERM.THERMAL_PROTECT_FSRM1_CFG_OFFSET thing does
08:50 karolherbst: RSpliet: do you know if 109°C is "too much" for a g94 chip?
08:51 RSpliet: if NVIDIA says it's all right, it's all right
08:51 RSpliet: don't question the big N :-P
08:51 karolherbst: yeah well
08:52 karolherbst: k
08:52 karolherbst: :D
08:52 karolherbst: have to check traces if nvidia does something there
08:52 RSpliet: oh yes, def.
08:52 karolherbst: the thing is, there is a lot of cards with a crap config
08:52 karolherbst: crit set to 125°C
08:52 karolherbst: and all the other regs to 0
08:52 karolherbst: that just sounds wrong
08:53 RSpliet: do you derive that from init scripts or therm table?
08:53 karolherbst: init script
08:54 karolherbst: the masks are there since nvc1 by the way
08:54 RSpliet: right, I assume NVIDIA overwrites them when parsing the therm table
08:54 karolherbst: maybe
08:54 karolherbst: and hopefully
08:54 RSpliet: if they make any more sense that is
08:54 karolherbst: since nvaf the script seems to set right values always
08:54 karolherbst: in kepler traces I didn't see nvidia touching those regs at all
08:55 karolherbst: not evenr eading
08:55 karolherbst: just on my card, but nowhere else
08:55 karolherbst: there are even nvc0 cards with 115°C set :/
08:56 RSpliet: quite useful, you can use your watercooling rig to make tea
08:56 karolherbst: :)
08:57 pmoreau: RSpliet: You have spent too much time in the UK already! :-p
08:58 karolherbst: ohh there is a word I really dislike from the UK and as long as he doesn't use it, it's all fine
08:58 karolherbst: :D
08:58 karolherbst: well not the word itself, but the way it is used
09:00 karolherbst: pmoreau: would you like to check some regs for me on your tesla cards? :D
09:01 karolherbst: 0x02010c and 0x020074
09:01 pmoreau: Any particular setup needed? (blob running, etc.)
09:01 karolherbst: mhh
09:01 karolherbst: once with nouveau and one with blob
09:01 karolherbst: both cards pls :D
09:02 pmoreau: The G96 is sleeping, don't want to wake her now… :-D
09:02 karolherbst: :D
09:02 pmoreau: Well, especially with X running, it is not going to be really happy
09:03 pmoreau: I'll do that when I get home
09:04 karolherbst: k
09:04 RSpliet: pmoreau: I drink my tea Dutch and black, thank you very much
09:04 pmoreau: xexaxo, karolherbst: BTW, no luck with adding "-D_GLIBCXX_USE_CXX11_ABI=0" to CXXFLAGS. And… can't say much about using libc++ since I run into other issues, but they might be caused by using libc++ 3.7 along with clang+LLVM 3.8.
09:04 RSpliet: no cloud of milk nor two dykes of sugar
09:04 pmoreau: RSpliet: ;-)
09:05 pmoreau: I can't drink tea with milk or sugar either
09:05 RSpliet: it's like eating whipped cream without sugar...
09:06 pmoreau: I wouldn't have thought of that, but why not! :-D
09:07 RSpliet: (I reckon, adding sugar to whipped cream is a very very Dutch thing)
09:07 karolherbst: pmoreau: whats the exact issue by the way?
09:09 pmoreau: karolherbst: `llvm::sys::getProcessTriple()` is considered as an undefined reference upon linking since clang can't demangle (or wrongly demangles) the name due to it containing those new GCC C++ ABI tag.
09:09 karolherbst: ahh so you compiled llvm with gcc with the cxx11 abi?
09:10 karolherbst: and now you want to compile something with clang against this llvm?
09:11 pmoreau: Right
09:11 karolherbst: and you do use a clang with those gcc abi_tag patches?
09:12 pmoreau: I did try but it still ended with the same errors IIRC
09:12 karolherbst: yeah well, this can happen
09:12 karolherbst: the patches won't solve linking errors by itself
09:13 karolherbst: what is the symbol clang tries to link against by the way?
09:14 pmoreau: You mean something like that `_ZN4llvm3sys16getProcessTripleEv`?
09:14 karolherbst: yeah
09:14 pmoreau: Let's see
09:15 karolherbst: this is the symbol I have in my llvm version, but this was compiled with the old ABI
09:15 pmoreau: Need to recompile Mesa without using libc++
09:15 karolherbst: mhh
09:16 karolherbst: you could try that:
09:16 karolherbst: cat /usr/lib64/libLLVMSupport.so | grep -a _ZN4llvm3sys16getProcessTripleEv
09:16 karolherbst: or wherever your libLLVMSupport.so is
09:16 imirkin_: i prefer nm -D :)
09:16 karolherbst: :D
09:16 karolherbst: right
09:16 karolherbst: then nm -D /usr/lib64/libLLVMSupport.so | grep _ZN4llvm3sys16getProcessTripleEv
09:17 karolherbst: :D
09:18 karolherbst: thing is, it returns a std::string so it is a bit more ugly sadly
09:19 pmoreau: I get _ZN4llvm3sys16getProcessTripleB5cxx11Ev
09:19 karolherbst: okay
09:20 karolherbst: so this symbol is marked as a cxx11 abi thing
09:20 karolherbst: so you have to compile mesa with the cxx11 abi
09:20 pmoreau: Well, that should be the default, shouldn't it?
09:20 karolherbst: with clang?
09:20 karolherbst: why should it?
09:20 karolherbst: only gcc defaults to the new abi
09:20 karolherbst: but what does this have to do with clang?
09:21 pmoreau: Ah right
09:21 karolherbst: also
09:21 karolherbst: the ABI split is a gcc thing
09:21 karolherbst: this has nothing to do with the c++11 standard
09:22 karolherbst: it was just the idea of gcc devs, to let c++11 application be compiled against the old ABI, so that c++11 can be linkied together with c++03 libs or something
09:23 karolherbst: pmoreau: and clang needs this abi_tag patch, to demangle the prototype to its cxx11 symbol version, when you compile against the new abi
09:24 karolherbst: compiling against the old abi while linking with a library compiled with the new ABI will always fails (as long as this library doesn't contain backwards compatible implementation of the symbols)
09:24 pmoreau: Meh, I'll rather stay with the old one for now :-)
09:24 karolherbst: :D
09:24 karolherbst: or just add a hacky define into the stdlibc++ config header :D
09:25 karolherbst: it is a gcc issue in the end somehow
09:29 karolherbst: I bet this abi_tag can be missused by library for supporting multiple ABIs in one binary :D
09:29 karolherbst: and I mean library ABIs, not the C++ one
09:30 pmoreau: Oh wait, it seems to have worked! Let's wait for the compilation to end first.
09:30 pmoreau: \o/
09:31 karolherbst: see, the patch works indeed :p
09:32 pmoreau: I just needed to add the _GLIBCXX_USE_CXX11_ABI=1 when compiling Mesa
09:32 karolherbst: figures
09:37 pmoreau: RSpliet: Where are the carambars? O:-) It looks like I need to fix the pointers on Fermi+ since it generates a 32-bit pointer. And I think 0x20 is wrong for the index of the first parameter of the kernel.
09:37 pmoreau: karolherbst: I'll make sure to get you the values! :-) Thanks a lot for helping!
09:37 karolherbst: np
09:49 karolherbst: the blob really likes it hot :(
09:50 karolherbst: 122°C for one gpu...
10:08 pmoreau: xexaxo: I still see Alexandre on the thread. :-p
10:23 karolherbst: I just installed gcc-5.3 today (upgrading from 4.9.3), I just hope nothing breaks :D
10:26 pmoreau: You know how to solve it if it does! ;-)
10:30 imirkin_: karolherbst: how did you defeat AutoAddGPU=false not working?
10:30 karolherbst: patch
10:30 imirkin_: seems like it got broken in X 1.17... worked fine in 1.16 :(
10:31 karolherbst: imirkin_: does that help? https://gist.github.com/karolherbst/fa4c741c5770eec9d3b2
10:32 imirkin_: maybe.... need to figure out how to set up user patches again
10:32 karolherbst: wait a sec :D
10:32 karolherbst: https://gist.github.com/karolherbst/7eebf54310639d70b5b0
10:32 karolherbst: in /etc/portage/bashrc
10:32 imirkin_: errrrr what?
10:32 karolherbst: ohh that is for user_patches for all packages
10:33 imirkin_: are you telling me that the xorg ebuild isn't set up for user patches? :(
10:33 karolherbst: I don't care which package does enable it, for me it is enabled for every package :p
10:33 karolherbst: :D
10:33 karolherbst: if you mean what the directory is: /etc/portage/patches/$category/$package
10:42 hwpplayer1: Hi friends i think that i use nouveau
10:42 hwpplayer1: how can i correct it
10:44 hwpplayer1: http://askubuntu.com/questions/271613/am-i-using-the-nouveau-driver-or-the-proprietary-nvidia-driver
10:44 hwpplayer1: i saw that
10:44 imirkin_: correct what?
10:45 hwpplayer1: if i'm using nouveau
10:45 hwpplayer1: or not
10:45 imirkin_: dmesg | grep nouveau
10:45 hwpplayer1: there is nothing appeared
10:45 imirkin_: then you're probably not. pastebin your xorg log?
10:46 hwpplayer1: ok
10:46 imirkin_: what are you trying to achieve btw? using nouveau, or not using nouveau?
10:47 hwpplayer1: i want to use nouveau
10:47 hwpplayer1: https://paste.kde.org/pbnsqfvfk
10:47 imirkin_: full log please
10:48 hwpplayer1: what command should i write ?
10:48 imirkin_: cat /var/log/Xorg.0.log
10:50 hwpplayer1: https://paste.kde.org/pdnv4dk3h
10:52 imirkin_: hwpplayer1: ok... soo..........
10:52 hwpplayer1: Did you read it ?
10:52 imirkin_: two things
10:52 imirkin_: (a) you have an intel gpu which is coming up as primary. this means you have an optimus-type system
10:52 hwpplayer1: yes it is true
10:53 hwpplayer1: Intel + Nvidia Optimus GT750M
10:53 imirkin_: (b) your secondary (nvidia) gpu is failing to come up properly. there is a fix in linux 4.4-rc5 which might get it going correctly.
10:53 hwpplayer1: Btw i use Debian 8.2 Jessie Gnome
10:54 hwpplayer1: What should i do ? to use Nvidia
10:54 hwpplayer1: sorry
10:54 hwpplayer1: To use nouveau
10:54 imirkin_: update your kernel to 4.4-rc5
10:55 hwpplayer1: If i use computer like that , will it become a problem ?
10:55 hwpplayer1: 4.3.2-040302-generic
10:55 imirkin_: will what become a problem?
10:56 hwpplayer1: Can i use computer like that without installing 4.4-rc5
10:56 hwpplayer1: i want to wait for the stable kernel
10:56 imirkin_: sure, you just won't get anything useful out of the nvidia gpu
10:56 imirkin_: [at least not with nouveau]
10:56 imirkin_: oh wait, actually 4.3 should have the workaround too
10:57 imirkin_: you can boot your kernel with
10:57 imirkin_: nouveau.config=War00C800_0=1
10:57 imirkin_: [in the kernel cmdline]
10:58 hwpplayer1: how can i do that
10:58 imirkin_: check with your distro help pages...
10:58 hwpplayer1: ok
10:58 imirkin_:doesn't do distro support
10:58 hwpplayer1: i don't need nvidia now
10:59 hwpplayer1: if i don't use nvidia , and want to wait for 4.4 stable
10:59 hwpplayer1: will it be a problem ?
10:59 imirkin_: not at all
10:59 hwpplayer1: ok i think that there is no problem
10:59 hwpplayer1: i'll wait
10:59 hwpplayer1: thanks
13:40 chillfan: for the kernel, where should I clone from to test nouveau? I tried the one recommended in installnouveau, and make menuconfig shows version 3.18.0-rc6, is this right?
13:40 imirkin_: no
13:40 imirkin_: i need to nuke those isntructions
13:40 imirkin_: build a regular kernel
13:40 chillfan: oh alright, 4.4-rc4, or from upstream git?
13:40 imirkin_: and then clone from http://cgit.freedesktop.org/~darktama/nouveau
13:41 imirkin_: sure, that's fine
13:41 imirkin_: that's a standalone repo
13:41 imirkin_: which will have the latest stuff
13:41 chillfan: okay, so I can clone from that for the latest kernel?
13:41 imirkin_: and will just build nouveau, against a kernel tree
13:41 imirkin_: it's not a full kernel tree
13:41 imirkin_: it's just nouveau
13:41 chillfan: i see, so cd linux-git-vxx; and clone [url you posted] like that?
13:42 imirkin_: no.
13:42 imirkin_: completely separate.
13:42 imirkin_: look at the "Out-of-the-tree compilation" bits on that InstallNouveau page
13:42 chillfan: alright, will do and will grab the git kernel :)
13:42 imirkin_: meh, linux 4.4-rcN will be good enough
13:43 imirkin_: or even 4.3.0 -- doesn't matter
13:43 imirkin_: note that the tree in question won't build against anything other than airlied's drm-next tree... you'll have to locally revert a commit
13:43 imirkin_: not a big deal though
13:44 imirkin_: if you want all the latest reclocking bits, use karol's tree though
13:44 imirkin_: https://github.com/karolherbst/nouveau
13:44 chillfan: so git clone https://github.com/karolherbst/nouveau will give me the latest kernel + nouveau reclock stuff?
13:44 imirkin_: no clue which branch... he has too many of them
13:44 chillfan: oh okay
13:44 imirkin_: no. like i said, it's *just* nouveau
13:44 imirkin_: not the kernel
13:44 imirkin_: it's built separately.
13:45 chillfan: ah alright
13:45 imirkin_: but requires a kernel tree sitting around somewhere
13:45 chillfan: that I can do, I guess nouveau hasn't changed in linux git atm then yet?
13:45 imirkin_: "hasn't changed"?
13:46 imirkin_: you should just do the things once, and perhaps then it'll become clear to you what the deal is
13:46 chillfan: hm, oh nvm heh, brainfart, i'll be cloning the nouveau stuff there to whatever kernel tree i guess so doesn't matter
13:46 imirkin_: no, not to a kernel tree.
13:46 imirkin_: to a totally and completely separate directory.
13:47 karolherbst: well
13:47 karolherbst: depends
13:47 karolherbst: what does he want_
13:47 karolherbst: ?
13:47 imirkin_: karolherbst: he wants the thing that will be easy
13:47 karolherbst: mhhh
13:47 karolherbst: for 0f reclocking?
13:47 karolherbst: or just upstream for 4.3?
13:47 chillfan: well yes, kind of easy, command line stuff I can do, but if it requires hacking on something then probably not
13:48 karolherbst: it depends on what you want to have, but didn't we already tried the boost reclokcing thing chillfan?
13:48 karolherbst: maybe it was somebody else :D
13:49 karolherbst: imirkin_: stable_reclocking_kepler is the best one if you want generic 0f reclocking working on all kepler cards
13:49 chillfan: no, I haven't tried to test it assume it was someone else, I will try to help testing if reclocking doesn't work straight away though, and my card might have different than reference voltages so not sure if that effects it
13:49 karolherbst: imirkin_: and one could cherry-pick master..pcie_speed if pcie speed is also kind of important
13:50 imirkin_: karolherbst: trim your branches
13:50 chillfan: i know it's not beyond the voltages from the spec as they locked that for this card, but i think it uses the max on it's highest clock
13:50 karolherbst: imirkin_: well I can't :/
13:50 karolherbst: I don't want to mix all the patches in one branch where I can't seperate them again
13:50 imirkin_: ?
13:51 karolherbst: one task one branch
13:51 imirkin_: karolherbst: then organize them somehow
13:51 chillfan: anyway, where should I clone nouveau from for the latest reclock support on this card? I'll go over the intructions from there and see if i can build it out of tree
13:51 imirkin_: karolherbst: e.g. feature/$foo
13:51 karolherbst: well, they are
13:51 imirkin_: karolherbst: and then merge/$bar
13:51 karolherbst: they are all features :D
13:51 karolherbst: except the no_touchy ones
13:51 imirkin_: karolherbst: right, except for the ones that aren't, they're all feature branches :p
13:51 imirkin_: see what i mean?
13:51 karolherbst: :D
13:52 karolherbst: ohh I can remove the please merge one though
13:52 imirkin_: and random kernel versions appended...
13:53 karolherbst: hey, that's my repository, don't tell me how to manage this one :p, the last time somebody told me how I should organize my working place was like years ago :D
13:53 imirkin_: well, presumably you want to make it useful to people
13:53 chillfan: i think i should clarify, heh, I meant I'd prefer to start with more simple stuff if testing, to see if it's too involved, I can report any problems though i'm sure
13:53 imirkin_: if not, organize however you want
13:54 karolherbst: imirkin_: well everything which starts with master_ is a collection of stuff
13:54 karolherbst: and everything which is appended with a kernel number, is for that kernel
13:54 RSpliet: testing isn't supposed to be simple, if things can be done with just the push of a button it's often not worth doing
13:54 karolherbst: all the other stuff is how the branch is called
13:54 karolherbst: :D
13:54 imirkin_: RSpliet: and on that vein, if it was hard to write, it should be hard to read ;)
13:54 karolherbst: chillfan: use the stable_reclocking_kepler branch
13:55 RSpliet: imirkin_: exactly, how else could we share the feeling of privilege with those who succeed?
13:55 chillfan: karolherbst: alright cheers :)
13:58 imirkin_: RSpliet: checked your pm branch... looks like you made good progress?
13:58 RSpliet: imirkin_: well, it's slowly progressing
13:59 imirkin_: are we there yet? :)
13:59 RSpliet: nope
13:59 RSpliet: first thing I need to do is triple-check the voltage stuff on GT21x
13:59 RSpliet: because there's an inconsistency between the voltage line I set and the name I gave it in ramcfg.c
13:59 imirkin_: i didn't mean for pushing, but have you tested your code beyond compilation?
13:59 RSpliet: oh I didn't even compile-test
14:00 imirkin_: lol
14:00 karolherbst: :D
14:00 RSpliet: just to make sure nobody tries out that code
14:00 RSpliet: it's not done yet :-P
14:01 chillfan: alright, bit noobish with git, what would be the command for that?
14:05 chillfan: (to specify kepler stable reclocking)
14:06 imirkin_: chillfan: git checkout stable_reclocking_kepler
14:06 chillfan: from within the cloned dir?
14:08 chillfan: ah ok think so, it mentions it switched branch so i guess that's right
14:08 imirkin_: now 'cd drm; make'
14:09 chillfan: ah cheers :)
14:12 chillfan: ok got build errors from that http://pastebin.com/ivRsd5RA
14:14 chillfan: http://pastebin.com/MsRykRWM
14:15 imirkin_: right...
14:15 imirkin_: what kernel are you building against?
14:15 chillfan: linux-4.4-rc4
14:16 imirkin_: are you running that right now?
14:16 chillfan: yes
14:16 imirkin_: k
14:16 imirkin_: type
14:16 imirkin_: git revert d55c3200d876032f6149c83045eea96c05472dc9
14:16 imirkin_: this will pop up an editor... just save + quit
14:17 chillfan: gives 'bad object'
14:17 imirkin_: hmmmm
14:17 imirkin_: oh yeah good call
14:18 imirkin_: karolherbst: your tree needs updating/fixing?
14:19 imirkin_: karolherbst: my suggestion would be to have feature branches, and then merges of those branches onto various versions in various combinations
14:23 chillfan: so should i switch to the other tree?
14:23 chillfan: git://people.freedesktop.org/~darktama/nouveau for now?
14:24 imirkin_: sure why not
14:25 chillfan: alright will do
14:26 chillfan: ok that worked, will update the userland in a little bit too :)
14:26 chillfan: bbs
14:31 karolherbst: imirkin_: yeah well, then I would have more branches in the end
14:31 imirkin_: karolherbst: not a problem, as long as it's organized
14:32 karolherbst: well you can also just cherry-pick the branches with master..$branchname
14:33 karolherbst: so it is easy to combine them
14:33 imirkin_: yeah no one's gonna do that
14:34 imirkin_: if they did you wouldn't have so many branches with versions in their names
14:58 karolherbst: :D right
15:20 Tom^: imirkin_: cant build -rc3
15:21 imirkin_: use your bare hands!
15:21 Tom^: imirkin_: makefile cant find llvm libraries and if i run the llvm-svn it does find it but errors on missing symbols later on under the compilation
15:21 Tom^: so *shrug* seems broken. :p
15:21 imirkin_: --disable-gallium-llvm
15:21 imirkin_: problem solved ;)
15:22 Tom^: no opencl then ;_;
15:22 Tom^: oh well it didnt run in muh card anyways
15:23 imirkin_: provide the full error to xexaxo ... he may be interested
15:23 Tom^: its something that is fixed in later versions anyways
15:33 Lemmatum: hi, I was wondering what is the recommended method for installed nouveau on debian?
15:33 Lemmatum: installing*
15:33 imirkin_: debian should come with nouveau...
15:34 Lemmatum: jyes, but I've update the kernel to unstable and now it's throwing errors :p
15:34 Lemmatum: updated*
15:34 imirkin_: what sort of errors?
15:35 Lemmatum: nouveau 0000:01:00.0: bios: version 80.07.1d.00.16
15:36 Lemmatum: Dec 14 23:09:05 dhcp-245 kernel: [ 16.924515] nouveau 0000:01:00.0: devinit: 0x9b29[0]: unknown opcode 0x00
15:36 Lemmatum: Dec 14 23:09:05 dhcp-245 kernel: [ 16.924519] nouveau 0000:01:00.0: preinit failed with -22
15:36 Lemmatum: Dec 14 23:09:05 dhcp-245 kernel: [ 16.924545] nouveau: DRM:dddddddd:00000080: init failed with -22
15:36 Lemmatum: Dec 14 23:09:05 dhcp-245 kernel: [ 16.924789] nouveau: probe of 0000:01:00.0 failed with error -22
15:36 imirkin_: please use pastebin
15:36 imirkin_: do you have an hp laptop?
15:36 Lemmatum: vaio
15:36 imirkin_: can you pastebin the full dmesg?
15:38 Lemmatum: http://pastebin.com/8DVHgh2v
15:39 imirkin_: probably the same issue......
15:39 imirkin_: sec
15:40 imirkin_: you probably need a patch like this one: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=linux-4.4&id=954329412ea45ad6b509aa26f1441941fd432823
15:40 imirkin_: either apply this yourself, or grab a 4.4-rc5 kernel
15:41 Lemmatum: so updating the linux kernel should fix it? Do I need to do anything to nouveau if this is the error?
15:41 imirkin_: nouveau has many parts
15:41 imirkin_: one of them is a kernel module, distributed as part of the linux kernel
15:41 imirkin_: this is the part you're having trouble with
15:42 Lemmatum: got it
15:42 pmoreau: Tom^: Care to share the error you have with LLVM? karolherbst helped me fix mine :-)
15:43 Tom^: do i really have to ? master builds and pre rc3 too. :p ?
15:43 imirkin_: might be nice so that we know which change to backport into mesa 11.1...
15:44 pmoreau: Tom^: Your call :-p
15:44 Tom^: FINE, but now that i soon got both mesa and lib32 built im gonna test if rc3 still has the fps drop regression first.
15:44 Tom^: you two are killing me
15:45 imirkin_: Tom^: take that frustration out on CS:GO and kill some people :)
15:46 imirkin_: Tom^: to be clear, you don't _have_ to do anything :)
15:47 Tom^: yes i have to, its for the greater good.
15:47 imirkin_: hehe
16:11 Tom^: imirkin: pmoreau https://gist.github.com/anonymous/345b9a0eec8e91c0a158 this is with llvm-svn which the makefile sort of wants or it wont find the libs.
16:12 imirkin_: xexaxo: --^
16:12 imirkin_: iirc someone added an ifdef to make it work
16:12 Tom^: and mesa-rc3 :p
16:13 imirkin_: xexaxo: should probably backport b4a03e7f8f4006eb2c5b09a0611fdda153dd8437 to 11.1 and maybe 11.0
16:13 pmoreau: Meh… definitely not what I experienced… :-/
16:13 imirkin_: Tom^: cherry-pick that change, and your build should work
16:15 Tom^: yep it did
16:15 pmoreau: Guess I was too up-to-date and missed that issue :-D
16:44 Tom^: imirkin: issue was present at d640f179d314abef4d82bf3237197f1278415d36 , just gotta retest rc3 again because it didnt happend there. then i got a nice little window to git bisect.
16:45 imirkin_: if 11.1-rc3 didn't have the issue, then it's something since the 11.1-branchpoint
16:45 imirkin_: which should be nice
16:47 imirkin_: i haven't the faintest clue what change it might be though
16:47 imirkin_: looked through the list, no good candidates
16:49 Tom^: its just like the unigine new scene stutter when firing, so running around and doing nothing is fine. :p. and it only starts to happend 3 - 4 minutes into the game.
16:50 imirkin_: annoying =/
16:51 pmoreau: imirkin_: Should loading a 64bit value on Fermi+ be handled manually or is one of the pass splitting it up in two 32bit loads?
16:52 imirkin_: pmoreau: i have no clue what you're saying
16:52 imirkin_: please rephrase, ideally in the form of a code segment
16:54 pmoreau: On Fermi, I need to load a pointer (so 64bits). Should I do a `ld u64 %r0d c0[0x20]` or `ld u32 %r0 c0[0x20]; ld u32 %r1 c0[0x20]`?
16:55 imirkin_: either way's fine. i'd do the former.
16:55 imirkin_: make sure that 0x20 is 64-bit aligned btw
16:55 imirkin_: e.g. you couldn't load, from, say, 0x24
16:55 imirkin_: the MemoryOpt pass knows about this and will merge when possible
16:55 imirkin_: and not merge when not possible
16:57 pmoreau: Right, that should be taken care of normally.
16:57 pmoreau: Then I probably have an error somewhere else. :-)
16:57 pmoreau: I'll investigate further
16:57 imirkin_: or you could tell me what problem you're having
16:58 pmoreau: Let me paste DEBUG=255 somewhere
17:03 pmoreau: https://phabricator.pmoreau.org/P68
17:03 imirkin_: ​ 2: mov - %r3 0x0000000040490fd0 (0)
17:03 imirkin_: 53
17:04 imirkin_: that looks very odd
17:04 pmoreau: One thing is that the returned value of the load is a 32bit value, even if the load was 64
17:04 imirkin_: feels like it's a 64-bit value or something
17:04 imirkin_: yeah, you're probably messing up the indirect thing
17:04 imirkin_: it must think it's reg.size=4
17:04 imirkin_: instead =8
17:05 imirkin_: or when you're creating the original load
17:05 imirkin_: can i see the code? :)
17:05 imirkin_: that creates the load and the store?
17:05 pmoreau: Sure
17:07 pmoreau: load is called from https://phabricator.pmoreau.org/diffusion/MESA/browse/spirv_1.0/src/gallium/drivers/nouveau/codegen/nv50_ir_from_spirv.cpp;45e9a634d61df97a521d6d833bb07b1434bf3fc6$731
17:08 pmoreau: load is defined at line 472, and store is just beneath it
17:08 imirkin_: ​Converter::DataArray::load(ValueMap &m, spv::Id id, Value *ptr, Type const* type)
17:08 imirkin_: 473
17:09 imirkin_: where does ptr come from...
17:09 imirkin_: oh... it's null?
17:09 pmoreau: In this case yes
17:09 imirkin_: errrrr
17:10 pmoreau: Should I make a sym for the corresponding offset in c0?
17:10 imirkin_: what's in c0[0x20]?
17:10 imirkin_: why are you loading it?
17:10 pmoreau: Should be the first user param
17:10 imirkin_: and what makes you think it's 64-bit?
17:10 pmoreau: It's a pointer
17:10 imirkin_: is it always a pointer?
17:11 pmoreau: No, but it is for the program I'm trying to run :-)
17:11 imirkin_: ok so
17:12 pmoreau: (The program is just `void (float* out) { out[0] = 3.14159f; }`)
17:12 imirkin_: ​ sym->reg.size = type->getFirstElementSize();
17:12 imirkin_: 507
17:13 imirkin_: does that work out to 4 or 8?
17:13 imirkin_: i'm guessing 4
17:13 pmoreau: If I didn't messed up, should be 8 in this case since the pointer is 64bit.
17:13 pmoreau: Let me check
17:13 imirkin_: er hm
17:13 imirkin_: hold on
17:13 imirkin_: maybe not
17:14 pmoreau: sym in load has a size of 8
17:14 imirkin_: aha
17:14 imirkin_: Converter::DataArray::store
17:14 imirkin_: what is the type that's passed in?
17:14 imirkin_: the type of the pointer? or the type of the value being stored?
17:15 pmoreau: Good question, one sec
17:15 pmoreau: Type of the pointer
17:17 imirkin_: mov - %r1 0x0000000040490fd0
17:17 imirkin_: why is this 64-bit?
17:17 imirkin_: that can't be helping things
17:17 imirkin_: and i dunno what that - is
17:17 imirkin_: should check out the printer and see when it prints that
17:17 pmoreau: FYI, the result of 480 (load of the 64bit value) is of TYPE_NONE and size == 4
17:17 imirkin_: anwyays, this is already wrong: ld u64 $r0 c0[0x20]
17:17 imirkin_: that needs to read $r0d
17:17 imirkin_: which leads me to believe that you're using 32-bit types throughout
17:18 imirkin_: the "u64" thing is meaningless btw
17:18 imirkin_: i bet the value's width is wrong
17:18 imirkin_: which in turn makes other things wrong
17:19 pmoreau: reg.size is 8 for the sym passed to mkLoadv
17:19 imirkin_: what about the value returned?
17:19 imirkin_: i.e. what's "ty"? is it TYPE_U64?
17:19 pmoreau: 02:17:40 pmoreau | FYI, the result of 480 (load of the 64bit value) is of TYPE_NONE and size == 4
17:20 imirkin_: BuildUtil::mkLoadv(DataType ty, Symbol *mem, Value *ptr)
17:20 imirkin_: LValue *dst = getScratch(typeSizeof(ty));
17:20 imirkin_: so you kinda want ty to be right :)
17:20 imirkin_: or at least not totally wrong
17:21 pmoreau: ty is TYPE_U64
17:22 imirkin_: ok
17:22 imirkin_: add more type/size printing to nv50_ir_print
17:22 pmoreau: Wait, I don't have "LValue *dst = getScratch(typeSizeof(ty));", but rather "LValue *dst = getScratch();"
17:22 imirkin_: and you should notice that things are fubar'd
17:22 imirkin_: ah yeah, that will always do 32-bit
17:22 imirkin_: use the BuildUtil helpers
17:23 imirkin_: or copy them verbatim
17:23 pmoreau: the mkLoadv is from BuildUtils
17:23 pmoreau: I haven't changed it
17:23 imirkin_: did i? :)
17:24 imirkin_: hehehehe
17:24 imirkin_: so i did
17:24 pmoreau: :-D
17:24 pmoreau: My master was at 7752bbc44e78e982de3cd4c34862adc38a338234
17:24 imirkin_: https://github.com/imirkin/mesa/commit/e8643fd674ad3f85920bd489db476c1b78bea27c
17:24 imirkin_: it's in my ssbo branch
17:24 pmoreau: Oh, ok
17:25 imirkin_: i guess i ran into this precise issue :)
17:26 pmoreau: ;-)
17:27 pmoreau: Works quite better I would say! :-D
17:27 pmoreau: 00000000: 83f01ca6 14000000 ld b64 $r0d c0[0x20]
17:27 pmoreau: 00000008: 40009de2 1901243f mov b32 $r2 0x40490fd0
17:27 pmoreau: 00000010: 00009c85 94000000 st b32 wb g[$r0d] $r2
17:27 imirkin_: your mov is still too wide if it gets written as 0x0000000040490fd0 in the ir
17:27 imirkin_: you should work out why that is
17:28 imirkin_: bbl
17:33 Tom^: sigh seems im just not meant to git bisect this. :p https://gist.github.com/anonymous/3f37ff0e92571f7f631c in both 11.1-branchpoint and rc1
17:35 pmoreau: Have you ever tried bisecting Nouveau across big rewrites? :-D
17:36 Tom^: hehe nope
17:36 pmoreau: But yeah, it's sad when every commit doesn't compile… :-/
17:37 Tom^: i wonder if there isnt someway i can just debug the issue further instead of git bisecting hm
17:45 chillfan: okay hit a little snag
17:45 chillfan: http://pastebin.com/BuSf4TfB
17:45 chillfan: apparently it wants to use build dependencies from ~/install but i don't have a toolchain there (from InstallNouveau wiki page)
17:46 chillfan: following InstallNouveau*
17:46 imirkin: Tom^: don't build virgl :)
17:46 imirkin: chillfan: do plain ./autogen.sh
17:47 imirkin: chillfan: and then do ./configure --prefix=$NVD
17:47 chillfan: same result, spits out the above
17:47 imirkin: that means it already messed something up :(
17:47 imirkin: clear out the dir and try again with a clean thing
17:47 chillfan: the nouveau part, or erm.. libdrm as well?
17:48 imirkin: the part you're having trouble with]
17:48 chillfan: ok :)
17:48 Tom^: is autogen.sh really necessery to call at all?
17:48 Tom^: was just poking at the pkgbuild of arch's xf86-video-nouveau and it only does ./configure --prefix=/usr , make
17:49 pmoreau: configure alone doesn't generate all the Makefile
17:49 chillfan: tried again, erm spits out the same error
17:49 imirkin: actually it does
17:49 imirkin: but if you don't have configure, you use autogen to create it
17:50 pmoreau: It didn't wanted to when I had an empty Mesa folder and just ran configure
17:50 Tom^: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xf86-video-nouveau the autogen is even outcommented. something changed and its not needed or working any more? :p
17:50 chillfan: ok so what to do now, same error
17:51 chillfan: ~/nouveau-env.sh looks as the one on the InstallNouveau page
17:54 chillfan: okay, erm maybe I shouldn't be installing it in home? like it should go to /usr?
17:54 chillfan: as I intend to use the edge driver
17:57 imirkin: chillfan: doesn't matter... but your system libdrm should be more than sufficient
17:57 imirkin: chillfan: i'm guessing you messed something up and and didn't undo it properly
17:58 imirkin: and figuring out precisely what over irc isn't exactly my idea of fun
17:58 imirkin: so just skip this step :)
17:59 chillfan: ok, using devuan testing (same versions for mesa, libdrm, nouveau as debian stretch), I guess this is okay?
18:01 imirkin: yeah, when you need a fresher libdrm you can always figure out what you did wrong
18:01 imirkin: and/or properly start from scratch rather than the partial cleaning you probably did
18:02 chillfan: alright, I'll give it a try in any case and see if i did go wrong, if I can get it working I'll be slightly happier with that
18:02 chillfan: but will otherwise use the distro versions if i can't
18:03 Tom^: yea i give up this is way to unreliable to bisect, some maps it fps drops, some it doesnt. some more then others. atleast the only consistency is that it takes a 5 or so minutes before it starts happening.
18:06 chillfan: I guess the reclock stuff is more kernel dependent anyway?
18:06 Tom^: yes
18:07 chillfan: so other versions of userland is not important? i can say the reclocking isn't working from the nouveau edge driver for me (not karols tree which didn't work for me)
18:08 chillfan: sorry switch didn't work to didn't compile heh
18:15 Tom^: imirkin: you sure there is no way i can get som idea of how much vram is used? github on csgo is filled with people having mem leaks on nvidia. , perhaps its not even a mesa issue just that its more noticeable since im on mesa and nouveau. and it gets hidden behind the beast of a card i got on the blob.
18:15 imirkin: Tom^: not to my knowledge, sorry
18:15 Tom^: :<
18:16 imirkin: Tom^: i do have a copy of CS:GO (it's a valve game) so i could see if i can repro
18:16 imirkin: Tom^: is there a way of hitting the issue without knowing how to actually play the game? e.g. some sort of single-player mode?
18:17 imirkin: or training or.. something
18:17 chillfan: brb
18:17 Tom^: i dont think so, deathmatch and just run around shot wildly for ~5 minutes. then it starts happening
18:18 Tom^: people on github seems to to suggest they only see it online too and it goes faster the more people there is
18:18 imirkin: heh
18:18 imirkin: sounds like not-my-issue then ;)
18:18 Tom^: :P
18:23 Tom^: yea its probably not mesa related, could use a way to see vram usage. see if it leaks in other games or at all.
18:24 imirkin: oh wait
18:24 imirkin: you can see... something
18:24 imirkin: gimme a se
18:24 imirkin: sec
18:25 imirkin: Tom^: GALLIUM_HUD='drv-tex_obj_current_bytes,drv-buf_obj_current_bytes_vid'
18:27 Tom^: gallium_hud: unknown driver query 'drv-tex_obj_current_bytes'
18:28 imirkin: hmmm
18:28 imirkin: did hakzsam rename stuff?
18:28 imirkin: Tom^: try GALLIUM_HUD=help glxgears
18:28 imirkin: that should give you a list
18:28 imirkin: pick stuff from that list :)
18:29 Tom^: https://gist.github.com/anonymous/f1559ab007fcd09ad396 doesnt seem exist any relating to vram tho :/
18:32 imirkin: wtf
18:32 imirkin: where are all the driver queries??
18:32 imirkin: oh, i bet those are only enabled on debug builds :(
18:35 imirkin: hakzsam: metric-issued_ipc -- i'm seeing 0 for that on my GF108 :(
18:35 imirkin: unless the claim is that i'm really issuing 0 instructions per cycle....
18:46 imirkin: skeggsb: you're not waiting on me for anything right?
18:46 imirkin: reviews-wise, that is
18:47 Tom^: there we go, yes driver querys are hidden unless you enable debug :p
19:08 Tom^: imirkin: yea well i might be memleaking a tiny tiny bit, but still i only went up to a total 490mb and yet it stuttered :p
19:08 Tom^: theory busted. ;_;
19:09 imirkin: Tom^: well it's not the full picture... there's other stuff in there but yeah
19:20 Tom^: interestingly its almost not happening at all with msaa off
19:20 Tom^: meh i blame valve for this.
19:39 Tom^: imirkin: yep i even solved it by simply disabling all muzzle fire with a console command. issue solved. you are excused. =D
19:39 Tom^: even the tiny memleak vanished by doing so
19:52 gnurou: imirkin: btw, I haven't found how to generate HTML documentation from rnndb's XML files?
19:53 imirkin: gnurou: not aware of any
19:53 imirkin: [documentation, nor a way to do it]
19:53 imirkin: gnurou: or do you mean the hwdocs thing?
19:53 imirkin: gnurou: which shows up at http://envytools.rtfd.org/
19:54 gnurou: I mean something that would translate the XML into a file suitable for a human to understand
19:54 gnurou: the doc on rtfd seems to be generated from envytools' docs/ directory only
19:54 gnurou: imirkin: also, I'd like to release our documentation for the nv50 texture format, as it would make it easier for you to match existing members with new ones. The main issue is that of members naming, how would you like me to address this?
19:54 gnurou: 1) replace all names with what NVIDIA uses
19:55 gnurou: 2) complete documentation, keep existing names (will be harder to match with Maxwell's format doc, unless I use the same names there as well)
19:56 imirkin: gnurou: i think it's best if you release the docs that are as close as possible to what you have internally
19:56 gnurou: or 3) issue NVIDIA's documentation as a totally separate XML file that will be somehow redundant with what is in rnndb
19:56 imirkin: gnurou: then we can adapt to nouveau
19:56 imirkin: gnurou: i really like the way other releases were made...
19:56 imirkin: like
19:56 imirkin: ftp://download.nvidia.com/open-gpu-doc/Shader-Program-Header/1/Shader-Program-Header.html
19:56 imirkin: it's nice and nouveau-independent
19:57 gnurou: mmm ok
19:57 gnurou: I though putting stuff in rnndb would make it easier for you guys, but your call
19:59 gnurou: imirkin: so to clarify, no need to submit to rnndb?
20:00 imirkin: gnurou: eventually yeah, but no need to immediately.
20:00 imirkin: gnurou: i think it may be nice if nvidia docs releases were independent of nouveau, as long as the format is consumable in some reasonable way
20:00 gnurou: well rnndb is technically independent of Nouveau :)
20:01 chillfan: okay i was able to build the userland tools, and install them in /home, and set the xorg.conf to point to that.. but I get an xorg error on starting, it shows it can't load the module 'fb'
20:03 imirkin: gnurou: yeah i guess
20:03 imirkin: gnurou: anyways, if you want to release it as rnndb that's fine... do whatever. things can be modified :)
20:04 imirkin: gnurou: if the layout is different, we'll need a new function to generate it anyways, so naming can be totally different
20:04 gnurou: well I just want to do what is the most convenient for everyone... but you guys know better what that would be
20:04 imirkin: well, rnndb would be quite convenient
20:04 imirkin: but i dunno if it's the best thing from a project separation standpoint
20:05 imirkin: but it's also a largely theoretical point
20:05 gnurou: technically nothing prevents anyone from generating HTML documents similar to the one you pointed from rnndb
20:05 gnurou: and it's free software, so it being (loosely) part of a given project is rather irrelevant IMHO
20:06 imirkin: gnurou: as long as the docs are all included, sounds good :)
20:06 gnurou: it also sounds safer to have it there than on a NVIDIA FTP server that could go down some day...
20:06 gnurou: well I will do that if you don't mind then, I just like the idea ;)
20:07 imirkin: if it's already in rnndb format, less work for me
20:07 imirkin: i like less work ;)
20:07 gnurou: ... and since I already wrote part of it for rnndb, less work for me too! :P
20:09 gnurou: remains the answer to my initial question: how to document the nv50 texture format - replace existing names (will affect generated .h files) or submit as a separate XML file
20:09 gnurou: maybe we could have a "nvidia/" sub-directory that contains all NVIDIA-released documents
20:09 imirkin: tough one.......
20:09 gnurou: and some way to cross the information with the one already existing in Nouveau
20:09 imirkin: i'd be up for changing all the names
20:10 imirkin: i'm not proud :)
20:10 imirkin: esp if you document G80 and up
20:10 imirkin: i.e. including the G80, which was different from G84+
20:10 gnurou: that sounds doable
20:10 imirkin: because, you know, why would those two gpu's have the same texture descriptors
20:10 imirkin: actually G84 might have only added additional features, not sure
20:11 imirkin: there are a bunch of unknown fields that we set right now semi-randomly, would be great to know wtf we're doing
20:11 gnurou: yep
20:12 gnurou: ok, so Maxwell will come first (hopefully this week), then I will take care of the older ones
20:12 imirkin: sgtm
20:13 imirkin: gnurou: if you could make it clear what applies where, that'd be super... esp whether it's GM20x or GM10x as well
20:14 gnurou: yep, that aspect is documented already
20:15 gnurou: the bottom-line is that GM10x supports both the old and new format and requires a method to select the new one, whereas GM20x only supports the new format
20:15 gnurou: which explains everything
20:15 imirkin: excellent
20:16 imirkin: that means i can test the new GM20x stuff on a GM10x :)
20:16 imirkin: [neither of which i have, but i bet i can convince mupuf to plug it in]
20:17 imirkin: did they also take the opportunity to randomly reorder TEX opcode arguments on GM20x because they could?
20:17 imirkin: i'm convinced that's all hw designers do all day... sit around and come up with new permutations to that op
20:19 gnurou: imirkin: some fields needed more bits apparently... for me it looks like mostly random shuffling, but I'm sure there is a good (probably hw-related) reason for that
20:19 imirkin: does it do native msaa x16 now?
20:19 imirkin: or still just x8?
20:23 gnurou: mmm I'm not seeing any mention of it, but I also don't really know where to look for that information
20:24 gnurou: isn't that a property of the sampler?
20:25 imirkin: uhhhh
20:25 imirkin: well, among other things, it's a texture field
20:25 imirkin: for the TIC that is
20:25 imirkin: or was... let's see if i'm making things up
20:25 imirkin: https://github.com/envytools/envytools/blob/master/rnndb/graph/g80_texture.xml#L144
20:27 imirkin: where the msaa mode is https://github.com/envytools/envytools/blob/master/rnndb/g80_defs.xml#L74
20:32 gnurou: well your "UNK6" is MODE_4X4 for us (doc says "sixteen real samples") - isn't that it?
20:33 imirkin: interesting.
20:33 imirkin: do you have a way of drawing that?
20:34 imirkin: https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L808
20:34 imirkin: i.e. can i stick MODE_4x4 in there?
20:35 gnurou: mmm here we are drifting into uncovered territory :)
20:35 imirkin: uncovered as in... you don't know, or can't tell?
20:36 imirkin: anyways, if you support msaa x16 textures, but have no way to render to them... it's of limited use :p
20:36 gnurou: probably cannot tell, sorry
20:36 imirkin: it appears that nvidia super-samples for x16 and x32
20:37 gnurou: however it seems like this pattern is not used before Maxwell...
20:37 gnurou: so I'd believe that it will work for Maxwell, but fail for anything below
20:58 imirkin: cool, will have to play around with it
20:58 imirkin: skylake also got 16x msaa support, so maybe all the hw people decided that 16x in hw was cool now?
20:58 imirkin: i haven't done any serious RE on maxwell to see what all has changed
20:59 imirkin: certainly nothing like the original RE that must have been done to get nouveau going
21:33 chillfan: would it still be useful to send piglit tests for mesa 11.0.7?
22:39 chillfan: if it's useful i have some piglit results (mesa 11.0.7)
22:45 chillfan: I guess from the git mesa is better, but i can send it to the same email as before if it's usual at all
22:45 chillfan: useful*
23:12 chillfan: bbl