00:55 TEX__: hello
00:56 TEX__: Can anyone here assist with Video Adapter Issues?
00:57 imirkin: perhaps you can describe your issue?
01:06 TEX__: I need a way to Increase my Screen Resolution. I can see my Screen but the Edges are not in Clear View...ie...I can only see 1/2 of the Bottom Panel
01:06 TEX__: I have tried everything under the Sun...changes, etc, etc.
01:06 imirkin: TEX__: pastebin your xorg log
01:07 TEX__: I feel it is a Driver issue since I have Full View in Windows 7
01:07 imirkin: also is your screen a TV screen by any chance?
01:07 TEX__: yes 73" Mitsubishi
01:07 imirkin: ah, that's why
01:07 imirkin: TV's overscan by default
01:07 imirkin: is it hooked up over HDMI?
01:08 TEX__: My Pc Video Adapter runs Into my LG BlueRay Player and from there to the Mitsubishi TV
01:08 TEX__: YES HDMI
01:08 imirkin: nouveau probably doesn't set the "no, really, don't overscan!" bit in the infoframe (because most devices ignore it anyways)
01:08 imirkin: on the bright side, you can tell nouveau to underscan
01:08 TEX__: I am Very New so I doon't always Understand what your telling me but can get there with some assistance
01:09 imirkin: which should counteract the TV's overscan
01:09 TEX__: ok
01:09 imirkin: give me a sec
01:09 TEX__: can you help me fix that?
01:09 TEX__: ok
01:09 TEX__: Thanks
01:10 imirkin: xrandr --output HDMI-1 --set 'underscan' 'on'
01:10 imirkin: try running that
01:10 TEX__: ok...gimme a min to do that
01:11 TEX__: hereis what I get.....
01:11 TEX__: sandy@sandy-GA-78LMT-S2P ~ $ xrandr --output HDMI-1 --set 'underscan' 'on' warning: output HDMI-1 not found; ignoring X Error of failed request: BadRROutput (invalid Output parameter) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 15 (RRGetOutputProperty) Serial number of failed request: 30 Current serial number in output stream: 30 sandy@sandy-GA-78LMT-S2P ~ $
01:12 imirkin: you probably didn't connect to the proper display...
01:12 imirkin: try DISPLAY=:0 xrandr ....
01:12 imirkin: if that fails, pastebin the output of DISPLAY=:0 xrandr
01:12 imirkin: (or hastebin.com or whatever)
01:13 imirkin: separately, and this is a better solution -- tv's will often have a setting in their menu's to disable overscan
01:19 TEX__: i dont see that option in my TV
01:19 imirkin: too bad
01:19 TEX__: sandy@sandy-GA-78LMT-S2P ~ $ DISPLAY=:0 xrandr Screen 0: minimum 8 x 8, current 1280 x 720, maximum 8192 x 8192 DVI-I-0 disconnected (normal left inverted right x axis y axis) VGA-0 disconnected (normal left inverted right x axis y axis) DVI-I-1 disconnected (normal left inverted right x axis y axis) HDMI-0 connected primary 1280x720+0+0 (normal left inverted right x axis y axis) 2040mm x 1150mm 1920x1080 60.0 + 59.9 30
01:20 TEX__: Sorry, Couldnt get the pastebin up
01:21 imirkin: ah, you need to use HDMI-0 then
01:21 imirkin: are you using nouveau?
01:21 TEX__: i think so
01:21 imirkin: if you are, it must be a very old version
01:21 TEX__: lemme check my driver, I believe I switched to Noveo since the NVIDIA Driver was of no help
01:24 TEX__: I have to Restart to make the change Back to Noveau....brb
01:37 TEX__: I'm Back
01:37 TEX__: IMIRKIN are you still here?
01:37 imirkin: ya
01:38 TEX__: ok
01:38 TEX__: I changed the Driver to the Nouveau driver
01:38 TEX__: and I have Pasteboard.co up also
01:39 TEX__: can you send me the command again? for the Driver
01:39 TEX__: or tell me what you need me to do...
01:40 imirkin: TEX__: pastebin the contents of your Xorg.0.log file (usually in /var/log)
01:41 imirkin: TEX__: and pastebin the output of 'xrandr --props'
01:48 TEX__: http://pasteboard.co/7uDMhAM.png
01:48 TEX__: thats part of it
01:48 imirkin: ok cool
01:48 imirkin: xrandr --output HDMI-1 --set 'underscan' 'on'
01:50 TEX__: http://pasteboard.co/7uMCDGj.png
01:52 TEX__: I think this Fixed it! <imirkin> xrandr --output HDMI-1 --set 'underscan' 'on
01:54 TEX__: Yes Sir Imirkin...You Have Resolved My Issue...
01:55 TEX__: I can now see my Screen Normally
01:55 TEX__: Thank You So Much!
04:00 TEX__: Imirkin are you back on?
04:01 TEX__: I just wanted You to know you Resolved my Issue and I Thank You Very Much.
04:02 imirkin: no prob
04:30 TEX__: imirkin if your still here I have 1 more question about the Resolution.
04:30 TEX__: When I reboot, I have to Run that Command in Terminal everytime i reboot. Is there a way to Save it so it remains Permanent?
04:31 imirkin: you could stick it into your xinitrc or something
04:31 imirkin: you might ask in a distro-specific support channel for how to get commands like that to run when X starts
04:32 TEX__: ok Thanks
07:11 xliugcn: hello, I want to generate the document like this: http://envytools.readthedocs.org/en/latest/index.html
07:11 xliugcn: can I build on my own from the envytools git repo?
08:02 mwk: xliugcn: cd envytools/doc; make html
08:02 mwk: you'll need python 3 and sphinx for that
08:02 mwk: and maybe some sphinx extensions...
08:02 martm: mlankhorst: hi, are you here sometimes too? i have plans with your patches we'd need to discuss a bit, i am awesomely tired today though, we'd see from whom to squeeze the last juice out to make the performance patches and mt fixes
08:07 martm: mwk: how are you, is it you in large part who has mainteined and also put together quite some solid documentation, or did those envytools folks leave some documentation with the code to start with too?
08:09 martm: mwk: i'd have some day couple of real questions to you too, it's about the scheduler more specifically how to access caches and stuff
08:13 martm: mwk: i have kepler card, starting from fermi it has CCTL/CCTLL shader opcode
08:15 martm: but i am off to bed now, there roughly two different ways to get rid of deadlock possibilities in hw and raise the performance, i've been mostly spamming about first method to the poeple in pm very impolitely
08:15 martm: and talked about second method on the channel
08:18 martm: thanks to the guy who gave me the link to that free game, i have done some driver testing, and i am almost sure that this nouveau project is very neat and we can make the driver to hit the glory fully, those problems seem to be fixable
08:20 martm: mwk: if there is no information you want from me, i was trying to help only, i could probably deal with handling it my own too, or let everyone handle their things in their own code from now on
08:20 martm: that would also suite, cause probably you can handle those things easily your own too
08:22 martm: mwk: just think about that you are heavily involved in the project, having revealed yourself as a nouveau developer, and when users start to show their dissatisfaction for such easy things, it could be uncofortable for you
08:25 martm: during such times you may start to think that it is better off overall to push a fix to master branch too
08:31 martm: this anger about russians every day when i go out, ones tend to point at me ne rabotaet, i don't have believe and interest where those work and what they do, i have seen to many of those big workers who actually do not do shit only say they work
08:32 martm: and in contrast to me, most of them highly lack capabilities to any kind of work at all properly
08:35 martm: i have the capabilities to do work, in contrast to my family where every real person understands that those are incapable to any kind of work
08:35 martm: they only brainwash
08:42 martm: i dunno how to describe it but it's a human psychology which disallows ones to swallow in the fact that one can't be playd on because one is incapable of doing things, such that lack capabilities can't be danger to people who can, things will fuck up that way, they need to understand that they do not play the first violine in life
08:50 xliugcn: mwk: thanks
08:52 karolherbst: mupuf: uhhh V bit table contains up to three tbales
08:52 karolherbst: mupuf: could V stand for voltage? :D
08:52 mupuf: karolherbst: oh, sounds great!
08:53 karolherbst: mhh but it is also there on Tesla
08:53 karolherbst: yeah well
08:53 karolherbst: let's check
08:58 ZanQdo: hello! installed suse tumbleweed on a macbook pro and nouveau is hanging with "Invalid ROM contents". Any ideas?
08:59 martm: imirkin: and btw i am not ever ignored, everything i say carries importance for the huge fanclub i have
09:01 pmoreau: ZanQdo: Which GPUs does it have?
09:01 karolherbst: mupuf: I am quite sure it isn't in the P table though :/
09:01 martm: so don't assume that i am ignored cause bloke like you have done it, don't also try to influence people to ignore me, cause you never succeed in it
09:01 mupuf: karolherbst: it is very likely in pfuse dude
09:01 mupuf: *very*
09:01 mupuf: temperature probe calibration is there
09:01 karolherbst: yeah well. I didn't find it there directly at least
09:04 karolherbst: mupuf: what would be the best way to verify it being inside PFUSE?
09:04 mupuf: have you checked the format it is stored in for tegra?
09:04 mupuf: because it is likely be in the same format
09:04 mupuf: probably a mul and a di
09:04 mupuf: v
09:04 karolherbst: well for tegra it is on the CPU
09:04 mupuf: it does not matter
09:04 karolherbst: and it seems to be just a number
09:04 mupuf: they likely will use the same logic
09:05 mupuf: what do they do with it?
09:05 karolherbst: multiply stuff with it
09:05 karolherbst: wait a sec
09:05 mupuf: i can't have a look at it right now
09:05 karolherbst: k
09:06 karolherbst: cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) <= speedo is the value I need
09:06 martm: mupuf: i also have a question for you, how well do you think softpipe would fit into programmable hw CPLD/FPGA i saw some discussion, imo it's just can't fit into hw, as it would waste lot of registers, so everything would work slowly?
09:06 karolherbst: and this seems to be the value from the mmio reg
09:06 karolherbst: I don't think anything happens to, but I can check again
09:06 mupuf: martm: this is insane, but in any case, I couldn't care less about this. Sorry.
09:06 ZanQdo: pmoreau, NVIDIA 8600M GT
09:07 mupuf: martm: please talk about nouveau, and better, try to redirect all the thoughts you have on fixing bugs and not decade-long projects
09:07 martm: mupuf: imo too that can't be so softpipe is off use for such purpose, thanks for you opinion
09:08 martm: mupuf: yes, thanks again i like your attitude man, actually i think if others would be as nice as you i'd indeed work on fixing bugs
09:09 pmoreau: ZanQdo: Looks like this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=91779
09:09 mupuf: martm: prove them wrong then, go fix bugs :p
09:09 karolherbst: mhh the speedo value on maxwell is funny, but on kepler: sku_info->gpu_speedo_value = tegra_fuse_read_early(FUSE_CPU_SPEEDO_2);
09:09 karolherbst: and gpu_speedo_value is speedo in gk20a
09:10 karolherbst: there is a speedo_revision on maxwell...
09:11 karolherbst: and if its 2: (-1662 + (1082 * cpu_speedo[2] / 100)) / 10;
09:11 karolherbst: ...
09:11 karolherbst: fun
09:11 pmoreau: ZanQdo: From the bug report, it looks like booting with `nouveau.config=NvForcePost=1` on the kernel command line helps. Worth giving it a try.
09:11 pmoreau: ZanQdo: BTW, which kernel version are you using?
09:12 karolherbst: mupuf: well in the end I could just intercept the ioreg_rd calls in the nvidia->linux wrapper source and check which reg would change the voltage calculation later on ...
09:12 ZanQdo: pmoreau, kernel 4.4.0-3
09:13 ZanQdo:reads up
09:13 pmoreau: Ok, almost the latest then.
09:13 mupuf: karolherbst: wouldn't that be equivalent to mmiotracing?
09:13 ZanQdo: yeah, using suse tumbleweed, would have the latest but first need to get X to start :)
09:13 karolherbst: mupuf: I want to fake the value
09:14 pmoreau: :-D
09:14 mupuf: fuck yeah!
09:14 martm: mupuf: i will ask you're opinion tomorrow or in near future, about the pseudo code for fixing multithreading and doing scheduler, if it would be theoretically doable if approve this approach and then indeed will try to fix it if so!
09:14 mupuf: that would be amazing :D
09:14 karolherbst: if I get nvidia to calculate the same voltage as on your gpu, I am happy
09:14 mupuf: martm: sorry, I have no knowledge on this :s
09:14 mupuf: karolherbst: i did not know reading regs was in the open surce part
09:15 karolherbst: but first I will still parse those nvbios tables, because I already started it...
09:15 mupuf: I should have checked
09:15 mupuf: this is super nice!
09:15 karolherbst: mupuf: mhh I think all linux calls are open
09:15 karolherbst: the wrapper code is huge
09:15 mupuf: yeepee
09:15 mupuf: that will be good enough then
09:15 karolherbst: it's over 20 c files and stuff
09:16 martm: mupuf: you definitely do, you are an intelligent fellow, i know you have little knowlege how shaders in hw work, since you're only one talking to me i highly would appreciate your opinion still if you even lack knowledge in this field
09:17 karolherbst: NvU32 NV_API_CALL os_io_read_dword (NvU32); ... :)
09:17 karolherbst: ohh wait
09:17 karolherbst: that's something else
09:19 martm: i talked with karolherbst too in the beginning i thought he lacks clue, but later as he said asynchronous instructions first, it is indeed a smart thing to say at least, but..i think it's not an issue, when you mask correctly it's not compulsory to do it, but indeed this could be a third solution to reorder that non-dependant instructions are first
09:19 martm: karolherbst: so the comment was not dumb at all actually
09:19 karolherbst: but I still say you can't schedule on the GPU
09:21 martm: karolherbst: yes we can, there are masks for this, and you even talked about zcull too, but this would skip with all of the threads
09:22 mupuf: karolherbst: I doubt they would have anything outside of just a function to call mmap
09:22 karolherbst: mupuf: any idea what inl() is for?
09:23 martm: karolherbst: we put every instruction into branch have it exec masked, karolherbst hold on for couple of days, when i make the new pseudo code
09:23 karolherbst: uhh
09:23 karolherbst: unl is readl
09:23 karolherbst: *inl
09:23 karolherbst: os_io_read_dword -> inl -> readl(PCI_IOBASE + addr);
09:23 mupuf: sounds promising!
09:24 karolherbst: yeah
09:24 karolherbst: let's check this
09:24 mupuf: hook the temperature
09:24 mupuf: and return 42
09:24 mupuf: 20400 (if you forgot)
09:25 karolherbst: I will hook 0x0 first
09:25 karolherbst: and see what it returns
09:26 mupuf: that too :)
09:26 mupuf: where will you print though?
09:26 karolherbst: printk
09:26 karolherbst: what a question :D
09:26 mupuf: prepare to get your logs flooded :p
09:26 mupuf: because the blob reads 0x0 often
09:27 karolherbst: yeah well
09:27 karolherbst: I think I got journald under my control now, not quite sure though
09:27 karolherbst: sometimes
09:27 ZanQdo: pmoreau, mm that didn't help
09:28 karolherbst: journald is so busy, it hangs my entire computer....
09:28 karolherbst: because calls to the logger are blocking until it is done writing its 5GB in mem cache to disc while new stuff is getting added...
09:29 pmoreau: ZanQdo: :-/ Too bad… Could you please update the bug report with that information, the output from dmesg with and without the NvForcePost option?
09:29 ZanQdo: pmoreau, I just stick this nouveau.config=NvForcePost=1 into the kernel line?
09:30 ZanQdo: formatting seems a little odd to me but I'm no expert
09:30 pmoreau: Yes
09:30 ZanQdo: ok..
09:31 martm: but the theory is based of radeons code that i read, you have direct access to the cache, cbranch works so that it takes an immediate which can be positive or negative and respects the exec mask (intel does it even more elegantly, but lets stick to amd model for now)
09:31 pmoreau: It does seem weird, but probably not as much as `nouveau.debug=PDISP=spam,PGRAPH=debug` I would say
09:32 martm: it does so that the offset given in cbranch immediate is how many of the instruction words to skip with given number of threads in the mask
09:33 martm: so you can if you have access to cache you can change the immediate value with bitwise operations, and what it does is it will jump after skipping anything but one instruction back to the handler
09:35 martm: branching is based of branch stack on gpu, it is done so that gpu maintains a branch lifo which is based where threads reconverge, threads converge and diverge
09:37 karolherbst: mupuf: mhh, it doesn't seem to call the os_io_read_dword thing...
09:38 karolherbst: oh well :/
09:38 martm: you don't wanna do that scheme without a handler, cause that cbranch instruction before every branch would just waste the cache memory awfully
09:43 martm: that is nothing complex for you to understand when i get the pseudo code ready actually, well reconvergence spot is obviosly just done based of the immediate value, there is nvidia link where this is all explained how gpu works with branch lifo structure
09:43 martm: its a last in first out structure, i give the links in the dpaste.com
09:45 martm: the order of instructions would remain the same, but cpu side of the compiler should add masks after every two instructions
09:46 martm: so it's only a minor patch to the nv50 codegen on that front
09:47 martm: and along with mlankhorst code, the benefit is that deadlocking becomes impossible + it will raise the perf
09:48 karolherbst: meh... 10 03 08 , table header
09:49 martm: mupuf: basically agreed, i will take two of the trello items on me, i will just make time for this
09:52 karolherbst: uhhh
09:52 karolherbst: I found another script table :)
09:54 martm: with that game and current git release of mesa, i know exactly where the fault is in mt, the code is very stable and freezes mostly deterministically due to mt
09:55 martm: so it is seen that nouveau will be absolutely stable to run games when this is fixed
09:56 martm: couple months back there were more failings for dri and such, but current git is stable
09:57 karolherbst: seems to be like the Display script table
09:57 martm: and i forgat one benefit of mt reordering scheme
09:57 martm: it does not need pusbuf relocations which are expensive
09:57 martm: fuck hell, pushbuf
10:02 martm: so the expectations are pretty much, that once those are fixed, the perfromance if karol has reclocking done will skyrocket far beyond the blob
10:06 martm: and stability according to current state, is it will never fail nor crash
10:06 martm: no gpu lockups and such
10:09 martm: mupuf: you were right too, blob does userspace command submission, this is itself slower method
10:09 martm: http://www.oreilly.com/openbook/linuxdrive3/book/ch15.pdf
10:11 martm: it's on page 13 starting with The
10:11 martm: mmap
10:11 martm: method is part
10:12 martm: kernel blocks with mmap to prepare bunch of things, while ioctl is almost prompt
10:13 ZanQdo: pmoreau, bummer, blacklisted nouveau and now it wont even boot to text mode
10:13 martm: those linux dudes who made the controversial decisions are very arrogant guys, but their design is better and correct though
10:14 martm: lots of spam on the web that kernel based design is bad overall and brings down the system and stuff, but it can be done absolutely stable fashion and it is just faster a lot
10:24 martm: mupuf: i actually also made the concept of doing mmiotracing the fast way, and a way to use dx blobs under linux in concept too, but i diverted away from this idea, looking that again open source drivers are better like always, my experience has always proved that open source guys do better code then commercial equivalents that most people use
10:37 martm: well since fermi and up have cctl codes it is easier, today i look how to handle the cache queries with nv50 chips, my laptop has that kind of chip too
10:37 martm: there one must a scratch reg somehow there is no shader opcode for knowing wether this thing is in cache or not to get the mask correct
10:40 Misanthropos: karolherbst, if you think you found a solution to the voltage problem let me know. i volunteer for testing :D
10:42 martm: basically it is possible on nv50 too, and even this fx5200 i dunno if you want me to add solutions for all of those chips,cause i have those gpus, this hexedit dude yestirday complained that fx5200 crashes on him with almost all stuff
10:42 martm: but i remember that my box with fx5200 very raw driver , the new one based of nv50 codegen really handled all the stuff
10:43 martm: so i think he had some problems that all git releases did not manifest in
11:03 karolherbst: Misanthropos: well, not yet
12:30 karolherbst: mupuf: do you know what these PFUSE.FUSES things are?
12:30 mupuf: what don't you understand?
12:31 mupuf: this is just the base address for the fuses
12:31 mupuf: and only a few are known
12:31 mupuf: you can see the TEMP ones I added
12:31 karolherbst: k, I was just wondering if the voltage thing is in there, because all the other PFUSE regs are useless
12:31 mupuf: well, it would be in there
12:31 karolherbst: k
12:32 karolherbst: only 7 reads different between ours...
12:32 karolherbst: the 0x0214a8 looks interessting...
12:32 karolherbst: 0x68a (1674) on mine
12:33 karolherbst: which is near to mode 0 c1: 168
12:33 karolherbst: and c0 has 0.1
12:33 karolherbst: and 0x0214a0 is 1
12:34 karolherbst: a4 too :/
12:34 karolherbst: mhh
12:38 mupuf: 0x0214a0 = 1 may mean: voltage-calibrated
12:38 mupuf: or something like that
12:39 karolherbst: yeah... it would be so much easier if we would be able to fake those mmio reads...
12:40 karolherbst: well
12:40 karolherbst: there are multiple regs with 0x1
12:40 karolherbst: or 0x0
12:41 mupuf: look for a value that could be the speedo
12:41 mupuf: do we know what order of magnitude to expect?
12:41 karolherbst: no
12:41 mupuf: we could dump that from the tk1
12:42 karolherbst: well, maybe the tk1 is sane, but after seeing what is up with the maxwell one...
12:42 karolherbst: there is a speedo_revision
12:42 karolherbst: and according to this, the value can be something completly different
12:42 mupuf: yeepee ;)
12:43 karolherbst: so I wouldn't trust the kepler one much because maybe it has only revision == 3 or something and our gpus like 2
12:43 karolherbst: and this means somethign completly different
12:43 karolherbst: the only thing I know is, that the gk20a is simplier in the voltage design than the desktop gpus
12:44 karolherbst: there are still 6 coefficients, but they have a slightly different meaning
12:44 mupuf: yep
12:45 karolherbst: and they use speedo / s_scale
12:45 karolherbst: and T/s_scale
12:45 karolherbst: where s_scale seems to be 100
12:46 karolherbst: ohh t_scale for temperature
12:46 karolherbst: and t_scale is 10
12:53 karolherbst: mhh and maybe it is just one value in the end
12:53 karolherbst: I think I try to RE the factors on your GPU and see how much they differ compered to mine
12:53 karolherbst: and if the different is always the same, well
12:54 karolherbst: yeah, sounds like the best idea to me currently
13:01 mupuf: karolherbst: agreed
13:46 martm: karolherbst: on radeon my scheme should work, because the only instruction without source operand is cbranch on it's own
13:47 martm: err destination operand karolherbst: do you know if nvidia has many of such opcodes that lack the destination operand?
13:57 amit_: Hello, I've been looking through the projects on x.org summer of code proposals and find this project interesting. I have good knowledge about c++ and hae done a few projects on compilers during my compler design course in college. Can you tel me more about this project ?
13:58 karolherbst: amit_: do you have any nvidia GPUs?
13:59 amit_: Nope.
13:59 karolherbst: n this case this project is most likely nothing for you, because having a nvidia GPU is somewhat required
14:00 karolherbst: not to offend you, but usually nouveau is somewhat known in the open source community and it is suprising you never heard of it and therefore you asked about it
14:01 karolherbst: but if you have specific questions then most somebody will answer them, but for the general question, just take a look at the nouveau wiki
14:04 martm: https://github.com/hyqneuron/asfermi/wiki/OpcodeExecution
14:04 martm: cont ret brk exit are such that do not take enough operands
14:06 martm: if they would be fast instructions i.e usage without masks in shader then there is no problem
14:07 martm: but i dunno, it should be determined with nvidia tools
14:13 martm: ouh my my, it seems that is even better when there are no operands
14:20 martm: karolherbst: so now it's clear i think the sched codes could also possibly end up being masks i.e i think i'd do pretty much the same as with them in the end
14:23 martm: prolly would work without the handler though, as handler is on gpu die, but it should not matter for the perf nor reg usage
14:27 martm: i.e my solution when we do not know the sched codes, would probably equivalent
14:28 martm: i will try to start working on it, i think the success is pretty much guaranteed though, but it's before the data per instruction should be gathered, for nvidia there is thread eddefiency tool, for amd it should be done manually with performance counters
14:29 martm: like measure the time with full set of threads possible like 2560 on radeon, and then lower and see how the performance changes
14:29 martm: i dunno they have not managed to do that easy tool with some years allready, dunno why it seems quite easy
14:30 karolherbst: martm: why don't you just try out your ideas?
14:31 martm: karolherbst: correct i will...
14:32 martm: karolherbst: thought i would not have time for this, as i should really almost sacrifice my life for this, but i suppose it's so for some others too, i will just make time
14:33 martm: karolherbst: i will start later today or tomorrow by patching the mesa with mlankhorst patch, and compiling my environment
14:35 martm: karolherbst: but you're theory could still be true, maybe the masks are delegated via the ctx microprocessor, but if cuda works they have to work, no matter how they are delegated to the gpu
14:36 martm: karolherbst: since you have been helping me with your work, all you guys, i won't anyways leave those ideas to my own, i can make it, i can be contacted we can discuss about this etc.
14:43 martm: karolherbst: i think intel quite oftenly introduces things before me, this time maybe we could beat them, i think they have softpin version allready for their gpu's i.e rendering without batch relocations
14:44 martm: this code is in nouveau_pushbuf.c or some like this file, actually it uses kernel ioctls via drm and kernel copies the data over
14:45 martm: i inspected that code roughly a year or 8months back, it's skeggsb code, calim was not aware much in details how it worked
14:47 martm: karolherbst: actually intel tried to avoid the penalties before allready partly, they had a stack method, one end like was going towards top and the other end towards down, and when they met batch was invalidated or flushed
14:50 martm: karolherbst: for reordering the cache based of ctxid, we won't need to add information into the game via textures, they have hw methods for this all
14:51 martm: we need to study that, how to fetch context ID's to understand which commands should be processed in cache the first etc.
15:01 karolherbst: mupuf: was there a problem with nvafakebios on your gk106?
15:04 karolherbst: ahh
15:04 karolherbst: now it is working
15:04 karolherbst: I had to specify the PROM size to be 0x400000
15:05 karolherbst: mwk: any ideas about this? we fixed it up being 0x20000 for G80+ but it seems like some kepler needs even bigger PROMs
15:07 karolherbst: mupuf: k, at least the first parameter seems to be fixed on both cards
15:07 karolherbst: it is cleary voltage = c0 / 10
15:25 karolherbst: hmpf :/
15:25 karolherbst: well at least something
15:35 martm: my uncle introduced me to programming when i was mess, i remember that msb that of signed int was the negative one, have to recap though, but if we substract from cache base address-destofcurrentpc-destofnextpc and make arithmetic in the handler to replace them with register real destinations and extract masks, then obviously the starting value to derive from, could also be negative
15:51 martm: so need some more checks cause seems it will bust the 10bit 1023 it's something like -512+512 as signed
15:56 martm: so i think we'd need to divide every dest and pc with two before too
15:58 martm: yeah obviously it would work unless the getpc or register value is one, then dividing by two makes 0.5:D
15:59 martm: but i think glsl works on floats, so it's still allowed though
16:02 mwk: karolherbst: not really, sorry
16:09 martm: karolherbst: by now you probably understand what the idea is right, the handler processes two instructions at time in sequence, the last one has masks instead of operands, and in the handler it writes them back to real registers derived from the first instruction with arithmetic, it derives both instructions operands according to currentpc?
16:11 martm: cause in ssa form everything is assgined only once, so the maximum operand register value is the max number of registers per SM
16:13 martm: though it would work without ssa too
16:14 martm: because during execution it processes one instruction at time, and then skips back to the bottoms handler, threads can not accidentaly take two locks in parallel
16:15 martm: if the dependency hasn't been written we add a global check in the handler to reprocess the last one until it's there
16:22 martm: karolherbst: by making you understand i will make you understand it's part of my goal, you get that insurance then that it is reasonably easy, you're not scared about ogl anymore or possibitlies to get a hang
16:24 martm: karolherbst: in that way the codegen patch is maybe as it only replaces some register values , it can't be more then 100 lines, plus it generates the handler code..its like a header it's about it, you have delt with very more complicated problems to be honest
16:38 martm: i would not need to prove to the institution that i am not moran, as i know they are, karolherbst: it's just that i've been for years forced a diagnosis which i am not ok with, i have like some months to solve this with a trial nowdays
16:39 martm: and i have not started writing to the court of law, it all takes time, if i won't manage to win the trial because of doing something else, my life could be screwd
16:46 imirkin_: martm: please stay on topic and don't pollute the logs. you write a lot of things that are totally unrelated, and a lot of other things which make no sense. i don't want to get into a banning situation, but please dial back your commentary.
16:47 martm: imirkin_: ok i agree with unrelated stuff, tell me what did you find from programming sentences which did not make sense, i try to explain them to you, well lets say on signed data type the msb is a sign bit if you did think that did not make sense
16:49 martm: imirkin_: i agree, i am polluting the logs , i'll paste the theory so you'd understand better of with dpaste.com tomorrow
16:49 imirkin_: martm: the vast majority of the time you appear to be talking to yourself. this is what i'm hoping you'll stop doing.
16:54 martm: ok, understood, i grab a sleeping pill for today, actually i am just happy with current situation, i wanted to share my happiness too for a while
16:57 martm: i mean not my diagnosis that i see things that do not exist, i am happy because radeonsi intel and nouveau code is heading towards stable, it's a big statement imo
16:57 martm: ok bye for today.
17:06 BootI386: Hello! Is DRI3 supported in the DDX?
17:07 imirkin_: BootI386: yep, but you have to enable it yourself
17:07 BootI386: At build time or runtime ?
17:07 imirkin_: Option "DRI" "3" -- same as with the intel ddx
17:07 imirkin_: runtime
17:08 imirkin_: [if you have a mega-old X you're building against, then it won't be available at all, of course]
17:08 BootI386: Oh ok thanks, will try (didn't see the option in the doc, so I asked for)
17:08 imirkin_: mmmmm should be in the man page
17:08 BootI386: Xorg 1.17.2 ?
17:09 imirkin_: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/man/nouveau.man#n128
17:09 imirkin_: note to self: remove notes about glamor
17:11 jelly: hi, I'm a bit offtopic here but what common method should I use to capture a nouveau-generated kernel stack trace on intel pc hardware, no serial console, probably no netconsole?
17:12 pmoreau: jelly: If it’s displayed on screen, a photo can do. :-)
17:12 imirkin_: jelly: if you can ssh in, dmesg > foo
17:12 imirkin_: [why no netconsole?]
17:12 BootI386: Well... I guess need to rebuild it (1.0.11, too old) :D
17:13 imirkin_: ah yeah
17:13 karolherbst: jelly: pstore if your computer is new enough!
17:14 jelly: no screen, no ping, no sysrq response (but my keyboard is usb and maybe ps2 would work)
17:15 jelly: reading HangDiagnosis I'm at about step 11, not sure if this board as firewire :-)
17:16 karolherbst: jelly: how old is the machine?
17:17 jelly: intel H55 chipset, clarkdale (pre sandybridge) i3 or i5 cpu, sadly
17:17 karolherbst: mhhh
17:17 karolherbst: this could be new enough
17:17 karolherbst: pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
17:17 Horrorcat: I feel bad for asking this in a dev channel, but does anyone know how the support of GeForce 940MX in nouveau is? I cannot find it on <https://nouveau.freedesktop.org/wiki/CodeNames/> (the 940M is there, is the X significant?)
17:17 karolherbst: check if you have such a mountpoiint and if it stuff is in there
17:18 Horrorcat: it appears to be a Maxwell GM108-N16S-GTR architecture, but I only found that by googling the GPU name, so not quite sure
17:18 jelly: no contents but it's mounted
17:18 Horrorcat: I’m still digging for documents from the notebook manufacturer
17:18 imirkin_: Horrorcat: https://bugs.freedesktop.org/show_bug.cgi?id=89558
17:18 karolherbst: jelly: mhhh
17:18 Horrorcat: haha, nice
17:18 karolherbst: jelly: well on my haswell I have stuff there whenever my kernel crashes
17:19 karolherbst: Horrorcat: it is just that no dev has access to such a card, so this is pending until somebody goes through the stuff :/
17:19 karolherbst: maybe somebody has no, no idea
17:19 Horrorcat: ah pity
17:19 karolherbst: well it might work if you patch nouveau and tell it to handle your gm108 like a gm107
17:20 Horrorcat: I might actually try these things, more worrying is that the intel fallback does seem to make problems in that bug too
17:22 imirkin_: actually it's pending for some to look at the provided mmiotrace and figure out if the golden regs need changing
17:22 imirkin_: there's a patch in there to just treat the GM108 as a GM107 and that's been working just fine for many people
17:24 jelly: I guess it's kdump or maybe try netconsole again.
17:40 BootI386: imirkin: libGL error: Different GPU, but blitImage not implemented for this driver, with DRI_PRIME=1 glxinfo >/dev/null, an IGP ("slave") and a NVidia card ("master") :D
17:41 BootI386: I wonder if it's nouveau or i965 though...
17:41 imirkin_: is the primary intel or nouveau?
17:42 imirkin_: if it's intel, it's the intel ddx that needs dri3, and no need for the nouveau ddx
17:42 imirkin_: (unless you're slaving outputs off it)
17:42 Horrorcat: I’m unable to find anything more specific than "GeForce 940MX" about the GPU in that notebook. so I’ll assume it is affected by that bug above
17:43 imirkin_: Horrorcat: probably. but note that model numbers have little connection to the chip used inside
17:43 imirkin_: they stick whatever they want in, fairly interchangeably
17:43 imirkin_: without adjusting model numbers
17:43 imirkin_: (the marketing ones)
17:44 Horrorcat: whatever it’ll be, if I go with that model, I’ll report back here if anyone is interested and see how it goes with DRI_PRIME etc.
17:47 BootI386: The primary is nouveau :)
17:48 imirkin_: BootI386: please pastebin logs, and the full output of glxinfo and DRI_PRIME=1 glxinfo
17:48 imirkin_: er, make that "pastebin xorg log"
17:52 BootI386: imirkin: xorg.log: http://termbin.com/t5h0
17:53 BootI386: LIBGL_DEBUG=verbose glxinfo: http://termbin.com/h2nr
17:54 BootI386: LIBGL_DEBUG=verbose DRI_PRIME=1 glxinfo: http://termbin.com/b14t
17:55 imirkin_: interesting.
17:55 imirkin_: so it figures out it should load i965
17:55 imirkin_: but then... pile o' fail
17:55 imirkin_: i would recommend asking in #intel-gfx
17:55 imirkin_: did you build mesa without --enable-dri3?
17:56 BootI386: Yeah. And it fallbacks to DRI2 for nouveau. :D
17:56 imirkin_: although that makes no sense... it's using dri3 for nouveau when you don't do the DRI_PRIME thing
17:56 imirkin_: sorry, this is above my paygrade
17:57 martm: i did not take a sleeping pill, last question! for that nv50/nv98 chip what is the max opengl version 3.3?
18:00 BootI386: Nope, it was built with DRI3, just rechecked
18:02 BootI386: I'm moving to #intel-gfk, thank you! :)
18:02 BootI386: *gfx
18:03 martm: https://mesamatrix.net/ got it..so back to sleep!
18:10 karolherbst: mupuf: okay, I think there are two factors
18:11 mupuf: karolherbst: I'm bacl
18:11 karolherbst: mupuf: the difference is either around 1.035 or 1.075
18:11 mupuf: about to mess with the internet and get it to work reliably, because it is just too annoying
18:11 karolherbst: I am done anyway
18:11 mupuf: so, 3.5% or 7.5%
18:11 karolherbst: yeah
18:11 karolherbst: most likely
18:12 karolherbst: there are some static values too
18:12 karolherbst: and the factor for mode 1 c1 and c3 is the same
18:12 mupuf: did you find anything in pfuse?
18:13 karolherbst: well
18:13 karolherbst: 0x68a and 0x647
18:13 karolherbst: 1.0417
18:13 mupuf: 647? weird address
18:13 karolherbst: ohh no
18:13 karolherbst: values
18:13 karolherbst: at 0x0214a8
18:13 karolherbst: the one I mentioned above
18:13 mupuf: ack
18:14 mupuf: so, there is a 4% difference between our two cards?
18:14 karolherbst: well
18:14 mupuf: is that what you are saying?
18:14 karolherbst: the difference is more close to 3%, but the factors have some static and some gpu dependet part
18:15 karolherbst: mode0: c0 * 0.1 + c1 * g0 + c2 * g1
18:15 karolherbst: where g0 has a 3.5% difference and g1 a 7.5% one
18:16 karolherbst: mode0: c0 * 0.1 + c1 * 168 + c2 * 28 (my GPU) c0 * 0.1 + c1 * 162 + c2 * 26 (your GPU)
18:17 karolherbst: mode1: c0 * 0.0597+ c1 * 100 + c2* 15.3T + c3*100T + c4*41 + c5*0.065 T^2 (my GPU) c0 * 0.0597+ c1 * 96 + c2* 15.3T + c3*96T + c4*38 + c5*0.06 T^2 ( your GPU
18:18 karolherbst: 0c1, 1c1, 1c3 have the small difference, 1c1, 1c4, 1c5 have the bigger one
18:19 karolherbst: so for example
18:19 karolherbst: if I set for mode 0, c0 = 0 and c1 = 0, then the voltage difference is around 7.5%
18:19 karolherbst: if c0 = 0 and c0=2, the difference is more like 3.5%
18:19 karolherbst: it really depends on the coefficients in the voltage map table entries though
18:24 karolherbst: mupuf: or maybe it is something stupid like (1/gpu_speedo)^2 and 1/gpu_speedo
18:30 karolherbst: mupuf: yeah well, I don't see any other fitting value, so maybe it is the same and sometimes you just have 2 * speedo or something like that
18:31 karolherbst: we also have T^2 in one place, so this doesn't sound too crazy
18:32 karolherbst: uhhh
18:33 karolherbst: uhhh
18:33 karolherbst: it makes so much sense now!
18:33 karolherbst: awesome
18:34 karolherbst: yeah
18:34 karolherbst: this is good
18:34 imirkin_: you have achieved enlightenment?
18:34 karolherbst: maybe
18:37 karolherbst: mode0 looks like this: 0.1 0.1S 0.000001S^2
18:37 karolherbst: mode1 like this: 0.0597 0.0597S 15.3T 0.0597ST 0.00001463S^2 0.000000023195S^2
18:37 karolherbst: have to normalize the values, but hey
18:37 karolherbst: it has more patterns then the old stuff I had
18:38 imirkin_: do those things divide one another somehow?
18:38 karolherbst: these are the factors for the coefficients in the voltage map table
18:38 imirkin_: right, but are the factors nice multiples of each other somehow?
18:38 karolherbst: mode0: c0 * 0.1 + c1 * 0.1 * speedo + c2 * 0.000001 * speed ^2
18:39 karolherbst: imirkin_: what do you mean?
18:39 karolherbst: I will write that stuff to rather divide the values, because this should looker better
18:40 imirkin_: let x = 0.0597, y = 15.3
18:40 imirkin_: is 0.00001463 some combination of those?
18:40 imirkin_: like 0.0597^6 or something? dunno
18:40 karolherbst: maybe
18:41 imirkin_: (does not seem to be the case)
18:41 karolherbst: c0 / 10 + c1S / 10 + (c2 S / 100)^2
18:41 imirkin_: ok that's good
18:41 karolherbst: ohh
18:41 karolherbst: wait
18:41 karolherbst: c0 / 10 + c1S / 10 + (c2 S / 1000)^2
18:41 karolherbst: I thinkg I forgot a 0
18:41 imirkin_: close enough ;)
18:41 karolherbst: now I have to test this
18:44 karolherbst: ahhh now
18:44 karolherbst: mhh
18:44 karolherbst: well the value is wrong
18:45 karolherbst: I have troubles with the c2 part a bit
18:46 karolherbst: c0 * 0.1 + c1 * 0.1 * speedo + c2 * 0.00001 * speed ^2
18:46 karolherbst: now this is right
18:47 karolherbst: c0 / 10 + c1 * S / 10 + c2 * S^2 / 100000
18:47 karolherbst: but this looks nice now somewhat
18:51 mupuf: well, that looks like a mess to me, but if it works on two cards, ship it :D
18:55 karolherbst: mupuf: https://gist.github.com/karolherbst/2c298b2cdb6eebe5a24e2e34ea8d37b2
18:55 karolherbst: still a mess?
18:55 karolherbst: only c4 and c5 are odd
18:58 mupuf: well, at least, this looks like round numbers!
18:59 mupuf: congrats
18:59 karolherbst: well c5 is really garbage somewhat
19:00 karolherbst: (15.3 * 16.75) ^2 : 65676
19:00 karolherbst: close enough to 68352.7
19:00 karolherbst: could be due to some inaccuracy
19:01 karolherbst: but yeah, no idea
19:01 karolherbst: I think I will read out the fuse value and change the calculation a bit and go testing
19:02 karolherbst: thing is, how do I read that reg out ...
19:03 karolherbst: because it is 1 when I just peek it
19:04 mupuf: karolherbst: check the code of nouveau
19:04 mupuf: you need to flip a bit somewhere first
19:04 karolherbst: PUNITS.FUSE_CONTROL <= { FUSE_READOUT_ENABLE }
19:04 karolherbst: =
19:04 karolherbst: ?
19:05 karolherbst: mhh
19:05 karolherbst: doesn't to be it
19:05 karolherbst: I will check
19:06 karolherbst: ahh
19:06 karolherbst: now I got it
19:06 karolherbst: poke 0x122634 0x00000000, peek 0x0214a8
19:12 mupuf: :)
19:25 karolherbst: fun...
19:25 karolherbst: this seems to be new with kepler
19:28 karolherbst: but is still there on maxwell2
19:28 karolherbst: good
19:31 karolherbst: mupuf: add a volt->speedo field and leave the default value be 1 and read it only out on kepler+ gpus?
19:31 karolherbst: mhh I could move the nvkm_volt_map think into a gk104 implementation though
19:32 mupuf: yeah, please do that
19:32 mupuf: it seems very chipset dependent
19:33 karolherbst: yeah
19:33 mupuf: that being to put volt_map into gk104
19:33 karolherbst: well
19:33 karolherbst: fermi needs it too
19:33 karolherbst: even the 0x20 version exists on fermi
19:33 karolherbst: :/
19:33 karolherbst: on mine
19:34 karolherbst: but nvidia never reads the FUSE reg out
19:34 mupuf: even on kepler or never on fermi?
19:34 karolherbst: the table with the six coefficients exists on Fermi, but the speedo value should be somewhere else
19:34 karolherbst: well I know what I am looking for though
19:35 karolherbst: 0x0212cc 0x000005b6
19:35 karolherbst: mhh
19:35 karolherbst: close enough?
19:35 mupuf: which is different from what you said this morning :D
19:36 karolherbst: what did I said this morning?
19:36 mupuf: that you did not know what to look for, even when looking at the tegra code ;)
19:36 karolherbst: yeah well
19:36 karolherbst: but I already was curious about this reg though...
19:36 karolherbst: even before today
19:37 karolherbst: but there were also like 10 othrs too
19:37 karolherbst: yeah, 0x0212cc looks good
19:38 karolherbst: badf1000 on my gpu
19:38 karolherbst: so kepler: 214a8, until fermi: 212cc
19:38 karolherbst: though fermi is a guess for now
19:43 karolherbst: mupuf: do you know when the voltage map table was added?
19:45 karolherbst: ohh well, I think I stick it into volt->speedo for now. We don't have a proper seperation in clk as well
20:28 karolherbst: mupuf: so, nvkm_fuse_read doesn't do the trick alone. I guess I have to set 0x122634 and see what nvidia does with it after reading the speedo out
20:29 karolherbst: oh well
20:29 karolherbst: it just writes 0 and then 0x41
21:54 hakzsam: karolherbst, are you on reator?
21:54 karolherbst: for a minute
21:54 hakzsam: karolherbst, you killed my session..
21:54 karolherbst: ohhh
21:54 karolherbst: sorry
21:55 karolherbst: I thought it was off...
21:55 karolherbst: I am really sorry
21:55 hakzsam: np
21:55 hakzsam: karolherbst, please tell me when you are done
21:56 karolherbst: done
21:56 karolherbst: nvidia or nouveau?
21:57 ZanQdo: pmoreau, evening :) so yesterday I did something stupid apparently. Every time I launched with run level 3 the boot failed, even text mode. Probably because of the nouveau error. Even then I tried blacklisting nouvea and of course now I have a system that wont boot
21:57 karolherbst: I turned it off anyway now
21:57 hakzsam: karolherbst, nouveau :)
21:57 karolherbst: ahh k
21:57 hakzsam: ok cool
21:57 karolherbst: then nouveua you should get
21:57 ZanQdo: pmoreau, any way of removing the blacklist?
21:57 karolherbst: mupuf: before 100.3% on my gpu, 97% on yours. now: 99.8% on mine, 100.1% on your GPU :)
21:58 karolherbst: hakzsam: yeah, I think I was pretty excited, because I finally found the speedo reg and could improve my volting code....
21:58 karolherbst: mupuf: Now I need more samples :)
21:58 hakzsam: karolherbst, no worries about that, it's just a session :)
21:58 karolherbst: ohh
21:58 karolherbst: so you also turned it on a minute ago?
21:59 hakzsam: no, it was turned on few minutes before
21:59 karolherbst: ohh okay
21:59 hakzsam: maybe wtprm has some issues :p
21:59 karolherbst: no idea
21:59 karolherbst: maybe I was blind
21:59 hakzsam: :)
21:59 karolherbst: ohh wait, my fermi also has the same voltage map table :D
22:17 karolherbst: funny. Why doesn't libnouveau compile on my other system...
22:17 karolherbst: undefined reference to `nvkm_i2c_aux_acquire'
22:27 mupuf: karolherbst: oh wow!
22:27 mupuf: that is ... very nice!
22:27 karolherbst: yeah, trying to test on my fermi
22:27 karolherbst: but the tool doesn't want to compile there...
22:28 karolherbst: nouveau/bin/util.h:102: undefined reference to `nvif_device_init'
22:28 karolherbst: ..
22:28 karolherbst: but the function gets compiled
22:28 karolherbst: and is inside lib/libnvif.so
22:28 mupuf: add -l? LD
22:28 mupuf: or -L
22:28 karolherbst: the Makefile does it already
22:30 karolherbst: everything compiles fine, but linking fails
22:31 karolherbst: hakzsam: how long will you need to do your stuff?
22:32 hakzsam: karolherbst, less than 1h because I'm tired
22:32 karolherbst: okay
22:32 karolherbst: the gf116 is in there?
22:32 hakzsam: it is
22:32 karolherbst: mhhh
22:33 karolherbst: it has the old table. I am not really up to REing this today though
22:33 karolherbst: then it doesn't matter
22:33 karolherbst: it has only 3 coefficients per entry though
22:33 karolherbst: and no mode
22:33 karolherbst: ...
22:33 karolherbst: how easy :D
22:34 karolherbst: well I would like to look into that tomorrow then and RE also this table
22:34 karolherbst: then 80% of the fermis are also done too
22:45 mupuf: karolherbst: want a particular fermi for tomorrow?
22:45 karolherbst: let me check yours
22:45 karolherbst: well I have a fermi with the voltage map table version 0x20, but I don't get libnouveau compiled there
22:46 karolherbst: so I would need one with version 0x10
22:46 karolherbst: which has currently plugged in one
22:46 karolherbst: so I am fine
22:46 karolherbst: maybe two fermis would be nice?
22:47 mupuf: I doubt hakzsam would be happy with this
22:47 karolherbst: the nvc8 when in doubt
22:47 karolherbst: seems to have the biggest table
22:48 karolherbst: ver 0x10
22:48 karolherbst: yeah
22:48 karolherbst: all your fermis have a 0x10 ver table
22:48 karolherbst: I don't know why my fermi is so special
22:50 hakzsam: mupuf, not until I'm done with the gk104
22:51 mupuf: karolherbst: oh well
22:52 karolherbst: well you could plug in the nvc8, but the current one would be fine too
22:52 karolherbst: I can still verify later on all your fermis :D
22:52 karolherbst: and keplers
22:52 karolherbst: and maxwells
22:52 karolherbst: !
22:53 karolherbst: ohh
22:53 karolherbst: you could replace the kepler with another one if that's fine by hakzsam
22:53 karolherbst: the gk104 would be good
22:54 karolherbst: ...
22:54 karolherbst: what a table
22:54 karolherbst: max entries: 0, 1 and 7!
22:54 karolherbst: ...
22:54 karolherbst: usually it is 0,1 and 2, but whatever
22:56 karolherbst: the heck...
22:57 karolherbst: why doesn't the thing compile
22:58 karolherbst: uhh
22:58 mupuf: karolherbst: not sure it is mine
22:58 mupuf: I do not have a GK104 IIRC
23:00 karolherbst: ohh intel?
23:00 mupuf: yeah, I'm afraid so
23:00 mupuf: I can try to get it home for the week end, since no-one will use it then
23:00 karolherbst: what about the gk107?
23:00 mupuf: that I do have here
23:01 karolherbst: k
23:01 mupuf: and hakzsam should see no problem with this
23:01 hakzsam: kepler1 is fine by me
23:01 hakzsam: yep
23:01 karolherbst: k
23:01 karolherbst: the table is a bit small there
23:01 karolherbst: but if I get good results, it os fine by me
23:01 mupuf: ok, when hakzsam is done, I can plug it
23:01 karolherbst: ohh a trace
23:01 karolherbst: mupuf: by the way, the funny reg write to read out the fuse is only required on kepler....
23:02 karolherbst: not on maxwell with the same reg
23:02 karolherbst: not on fermi with the other fuse
23:02 karolherbst: and it is always poke 0, read fuse, poke 41
23:03 karolherbst: uhhh, the fuse value very high
23:03 karolherbst: much higher than mine actually
23:03 karolherbst: good
23:04 karolherbst: that explains why my coefficients were so good :O
23:04 karolherbst: they are somewhere in the middle of all cards
23:08 karolherbst: ....
23:08 karolherbst: stupid envytools
23:09 karolherbst: well it still doesn't compile.. :/
23:10 mupuf: as for me, the auto bisect of piglit tests failing seems to be all in place ... save aggregating piglit runs in one go instead of once per test ... which takes freaking forever!
23:10 karolherbst: somehow ld messes up big time
23:10 karolherbst: awesome!
23:11 mupuf: I'll see if I can be smarter tomorrow and figure out a good way
23:11 karolherbst: mhhh
23:11 mupuf: I have ideas, but I honestly can't tell which one is the sanest, so, time to sleep
23:11 mupuf: this freaking thing looks more and more like a compiler
23:11 mupuf: with optimization passes and everything :D
23:11 karolherbst: :D
23:12 karolherbst: -Os
23:12 karolherbst: -Of
23:12 karolherbst: :)
23:12 mupuf: I mean, sure, if you can call piglit once, please do so :D
23:13 mupuf: because piglit takes forever before starting a test
23:13 mupuf: it is fine if the run takes 10 minutes
23:13 mupuf: but if you wait 5s for every test, the autobisect is going to look very bad!
23:14 hakzsam: mupuf, give me few minutes
23:15 karolherbst: ohhh :O
23:15 karolherbst: the compiler errors are only in inlined stuff
23:16 karolherbst: static inline :D
23:16 karolherbst: yep
23:16 karolherbst: removing the static and it compiles
23:17 karolherbst: seriously...
23:17 karolherbst: what an error
23:29 hakzsam: mupuf, karolherbst have fun
23:29 karolherbst: thanks
23:35 karolherbst: today gcc won't outsmart me...
23:35 karolherbst: friggin compiler
23:36 karolherbst: mupuf: s/inline/__always_inline/ did the trick .....
23:36 karolherbst: .....
23:36 karolherbst: ......
23:58 hakzsam: GL 4.2 for GK104 is on the list :)
23:59 karolherbst: yay