04:16hrw: can someone take a look at simple patch? http://paste.fedoraproject.org/167621/14208057
04:16hrw: with it I can boot my machine with geforce gts250 to system
04:18hrw: http://paste.fedoraproject.org/167623/08058501/ is dmesg from booting system while http://pastebin.com/EKMUSTVu shows behaviour without it
06:54imirkin_: hrw: i think the right approach is to make the code that causes the explosion not cause the explosion... it probably forgets to check for something, or you need to keep track of whether the map failed or... something
06:54imirkin_: (i've yet to look at the details)
06:55imirkin_: not destroying the object for some errors but not others isn't workable imo
06:56hrw: imirkin_: sure, this was just quick hack
06:59tobijk: hey imirkin_ a user wanted to give you a renewal of his piglit results, do you want them? (nve4)
07:00imirkin_: i saw them but forgot to pick them up
07:00tobijk: i saved em if you are interested
07:01imirkin_: email me
07:03tobijk: i'll add my nve7 results ones as well
07:05imirkin_: that way i won't lose them
07:08imirkin_: hopefully at least one of them is after my texture offset fix
07:08tobijk: imirkin_: btw, any idea on my RFC patch? i hoped for some reactions, even ranting :D
07:09tobijk: when did you upstream the texture patch?
07:10tobijk: oh actually both results are with your trexture fix
07:13Eliasvan: Hi everyone, I'm coming close to the point of doing an mmio trace of reclocking on the binary driver for the 620M (not yet done)
07:14Eliasvan: Can someone give me instructions on how to do some useful reclocking tests on the binary driver?
07:15Eliasvan: (e.g. using the "nvidia-settings" programs to change the clocks manually, is that a good test to trace?)
07:16imirkin_: search for 'ubuntu mmiotrace' -- that gives a good page.
07:16imirkin_: oh... reclocking? duno
07:17imirkin_: RSpliet may have some suggestions
07:17imirkin_: i've done it by modifying the vbios
07:17imirkin_: basically you 0xff out the levels you don't want, and only leave the level you want to test
07:17imirkin_: and then load the nvidia driver while capturing the mmiotrace
07:17imirkin_: it will have no choice but to switch to that level
07:18imirkin_: then you can get X -> Y transitions as well since when you unload the nvidia module, it'll stay at the level you set it to
07:18imirkin_: you can use nvafakebios to help with this (in envytools)
07:19Eliasvan: ok thanks imirkin
07:20tobijk: Eliasvan: i remember that some levels may not be accessible at boot
07:20tobijk: depends on the actual hardware
07:20Eliasvan: note that I had to use bumblebee combined with optirun in order to access the gfx card
07:21Eliasvan: ah, is there some tutorial/documentation on which levels to try and which not?
07:22imirkin_: well, the specific levels are defined by your vbios
07:22Eliasvan: because pmoreau said that the vbios reporting of my card misbehaved
07:23Eliasvan: (I send him a vbios dump)
07:24imirkin_: btw, just so you're clear, i estimate that getting fermi reclocking to work would be a 6+ month full-time job for someone not already familiar with all this stuff.
07:25imirkin_: but getting it to work on just one card is considerably easier
07:25Eliasvan: yeah, that' understandable :)
07:27Eliasvan: but that means I don't need to play around with the GUi "nvidia-settings" thing, it's sufficient to modify the vbios table and then loading/unloading the driver (after starting the trace)?
07:28Eliasvan: And if I modify the vbios, is it permanent?
07:28Eliasvan: (or will it be reset at reboot?)
07:28imirkin_: it may be difficult to correlate actions to things in the trace
07:28imirkin_: not permanent
07:28Eliasvan: ah, ok
07:29imirkin_: just puts it into vram, which is volatile
07:29Eliasvan: ok, I understand, it's easier to examine the trace when not involving a whole X and GUI startup sequence
07:30Eliasvan: ok, I'll try it :)
07:30imirkin_: well, you'll have to start X
07:30imirkin_: but it's easier if there's only one reclocking sequence
07:32Eliasvan: Why do I have to start X? I can modprobe nvidia without starting X.
07:33Eliasvan: And there's an additional gotcha: on an optimus system starting X will only speak to the Intel integrated driver
07:33imirkin_: yeah, but it won't do anything until you do
07:33imirkin_: yeah, that's a very annoying complication
07:33Eliasvan: and I can only run "optirun <command>" once I'm in X
07:33imirkin_: that's coz of bumblebee right?
07:34imirkin_: that might actually help you
07:34imirkin_: if, while in X, you can unload nvidia
07:34imirkin_: then that will make your life easier
07:34Eliasvan: aha, nice idea!
07:35Eliasvan: and then I can run "optirun glxinfo" after "modprobe nvidia" to trigger the gfx card?
07:35Eliasvan: or do I need to run something as glxgears to sufficiently trigger the gfx cards clocks?
07:36imirkin_: glxinfo could be enough
07:36imirkin_: one way to find out ;)
07:36Eliasvan: ok, thanks, I'll try it :)
09:04linas: while trying to bisect a different problem, I found that yesterday's git head hangs during boot
09:04linas: with fb: switching to nouveaufb from simple and then after tha, nothing
09:06linas: two NV40 cards
09:06linas: yes old.
09:07tobijk: let me pull to actually see what changed :)
09:07linas: I'm flipping a coin: bisect some more or buy newer hardware
09:07linas: let me find the exact head I pulled
09:11tobijk: linas: you got 74e59ea05c790c3f2108fa20dd4bacc028c4badf?
09:11linas: argh. not sure. my git bisect log is empty
09:12linas: It was head from yesterday or two days ago
09:12tobijk: git log | grep 74e59ea05c790c3f2108fa20dd4bacc028c4badf
09:14linas: no I don't have that
09:14linas: oh wait
09:14linas: one moment
09:14tobijk: you have a detached head from bisecting maybe?
09:16linas: yes I do ...
09:16linas: and I'm mistyping things
09:17tobijk: suspecting https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1b1f3e1699a9886f1070f94171097ab4ccdbfc95
09:17tobijk: bit thats a wild guess
09:17tobijk: can you actually bisect from rc3 or a last know good commit?
09:18linas: yes, I will do that
09:18linas: may take a few hours
09:18tobijk: looks like only a few steps maybe 5
09:19linas: OK, so my head was bdec41963890f8ed9ad89f8b418959ab3cdc2aa3
09:20linas: which appears to be before 74e59ea05c790c3f2108fa20dd4bacc028c4badf
09:21tobijk: and that rev was fine? yeah just bisect from there if you are sure about it :)
09:22linas: no rev bdec41963890f8ed9ad89f8b418959ab3cdc2aa3 is broken
09:23linas: while 3.18 was broken in a different way
09:23linas: so that rev hangs in boot w/ message I just gave
09:24linas: 3.18 boots fine, but reports gpu lockup in boot, which is what I was originally chasing down
09:24linas: so I figure its easier to bisect the hard hang, first
09:24linas: then biest the gpu lockup later
09:26tobijk: well let us know if you found it :)
09:53Eliasvan: imirkin: so I first ran (on 620M) "nvagetbios > tmp.vbios", which suggested I should run it with "-s prom", so I ran "nvagetbios -s prom > tmp.rom", which then produced a lot of nouveau dmesg lines with someting like "MMIO read failed on address ...".
09:53imirkin_: if you're running nouveau, just do cat /sys/kernel/debug/dri/1/vbios.rom > vbios.rom
09:54Eliasvan: ah, ok, I'll remember it
09:54Eliasvan: Doing "ls -l tmp.rom" showed a size of 1M, which seemed good
09:54imirkin_: ah, well it's probably ok... nvagetbios does nasty things and nouveau reports errors
09:54imirkin_: you can check by decoding it with 'nvbios'
09:55Eliasvan: Then I ran "nvbios -p perf tmp.rom", which said then the first address (0) was already invalid
09:56imirkin_: yeah, that's common
09:56imirkin_: or... dunno
09:56imirkin_: pastebin the whole output?
09:56Eliasvan: The only thing I'm trying to do, it to see which vbios address I should fill with 0xff to force the perf levels, like you said
09:56imirkin_: (or a big chunk of it)
09:57Eliasvan: ok, it might take a while (because I'm on a different pc right now)
09:57pmoreau: Eliasvan: Hey!
09:57Eliasvan: Hi! ;)
09:58pmoreau: (Thanks for the patches, going to apply hem :) )
09:58Eliasvan: Nice, thanks :)
09:58Eliasvan: pmoreau: did you succeed in analysing the vbios I sent you a while ago?
09:59pmoreau: Eliasvan: Didn't have much time sadly...
09:59Eliasvan: pmoreau: because I'm trying to find the addresses which are used for setting the perf level, to do some reclocking tests on the binary driver
09:59Eliasvan: no prob ;)
10:00pmoreau: Was it about some connectors failing?
10:01Eliasvan: it was about something in dmesg at the init of nouveau: a pointer in the vbios to some table couldn't be found
10:01pmoreau: Ah, right!
10:02pmoreau: Some TMDS table or something like that?
10:02imirkin_: oh, that's common
10:03imirkin_: not an issue
10:05Eliasvan: the name of the table started with "D...", I'll have to check
10:06Eliasvan: The weird thing is that in dmesg nouveau seems to succeed in reading the perf levels, so I don't understand why the nvbios tool doesn't work, maybe the nvagetbios tool doesn't work properly instead
10:06Eliasvan: Maybe I should try "cat /sys/kernel/debug/dri/1/vbios.rom > vbios.rom" like imirkin suggested
10:07pmoreau: Or use the one you sent me?
10:09Eliasvan: that one doesn't work
10:09Eliasvan: "nvbios -p perf tmp.rom", which said then the first address (0) was already invalid
10:09Eliasvan: Should I use the rom (1M) or the ram (128K)?
10:11Eliasvan: I also noticed some nouveau dmesg lines with "MMIO write failed at address ..."
10:15Eliasvan: so if I want to edit the vbios by running "nvfakebios -c 0 -e <address-to-write-perfstate> 0xff", maybe it will not succeed because it can't write to the card?
10:15imirkin_: the vbios is usually on the order of 64k... the rest is filler
10:42linas: OK, I got very lucky with the bisect
10:42linas: 26178ec11ef3c6c814bf16a0a2b9c2f7242e3c64 boots fine (although with a gpu lockup during boot)
10:42linas: but 988adfdffdd43cfd841df734664727993076d7cb hangs hard during boot
10:43linas: The one that hangs is a merge of drm-next into 3.19rc
10:47linas: but I guess I can narrow down which drm-next change it was ..
10:50imirkin_: linas: perhaps you need the equivalent of http://cgit.freedesktop.org/~darktama/nouveau/commit/?h=linux-3.19&id=4e351ed8f4e9c41fbe7caab2612eeac6f6c6df80 ?
10:56linas: I can try that, but I do not see an oops, I just get a hard hang when switching from simple to nouveaufb (of course, I guess the oops might be hidden...)
10:57imirkin_: perhaps use netconsole to see if there are messages that you perhaps miss?
10:59Eliasvan: @pmoreau & @imirkin: Good news, imirkin's method of vbios extraction did work and produced a parsable result. For comparison with the nvagetbios method, I did some tests, see pastebin: http://pastebin.com/LcU0iLjd
11:00Eliasvan: @pmoreau & @imirkin: Interesting to note is that the nvagetbios is also not constant (same size, but different checksum, see pastebin)
11:02imirkin_: prolly coz the card was powered off
11:02imirkin_: and nvagetbios doesn't power it on? dunno
11:03linas: wow, I hit the jackpot .. found a version right around 3.18-rc4 that does not gpu-lockup (nor hang) so that makes my window of heartache much smaller.
11:07Eliasvan: @imirkin: If I send you the file "vbios-perf-b-v.txt" resulting from "nvbios -p perf -b -v vbios.rom > vbios-perf-b-v.txt", can you determine which vbios values I should edit?
11:09imirkin_: Eliasvan: pastebin
11:09Eliasvan: @imirkin: "vbios-perf-b-v.txt": http://pastebin.com/UsWNH9va
11:09imirkin_: Eliasvan: also, don't use '@' -- that makes my client not notice that you're referring to me
11:10Eliasvan: oh, ok, just "imirkin: ..."?
11:10imirkin_: -- ID 0x7 Voltage entry 17 PCIe link width 255 2.5 GT/s--
11:10imirkin_: 0x92bf: 07 c0 11 08 00 00 00 00 00 00 96 19 00 00 00 00 00 00 00 00
11:10imirkin_: so the 07 at 0x92bf can befome ff
11:10imirkin_: and then that level will get ignored
11:10imirkin_: makes sense?
11:11Eliasvan: yes, I think so (this is my first time doing it, so forgive me for my ignorance)
11:13imirkin_: won't be the last though
11:17Eliasvan: imirkin: so if I understand correctly, the current level is at
11:17Eliasvan: -- ID 0xff Voltage entry 0 PCIe link width 255 5.0 GT/s--
11:17Eliasvan: 0x927a: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
11:18Eliasvan: because dmesg says: [ 8.770231] nouveau [ CLK][0000:01:00.0] --: core 270 MHz memory 324 MHz
11:19Eliasvan: where memory 324 MHz seems to correspond with the host freq in the corresponding level table
11:22Eliasvan: imirkin: so if I disable the 2nd level like you suggested, the first level will also be ignored when starting a 3D app (because it has 0xff in the beginning as well), and since the 3rd level also has 0xff, the 4th level is the only possible level left, right?
11:28imirkin_: Eliasvan: right
11:28imirkin_: Eliasvan: at least that's the theory
11:30Eliasvan: imirkin: ok, and assume I want to activate the 3rd level (which has 0xff in front of it by default), to what value should I change the '0xff' value?
11:31imirkin_: no, that level's not valid in the first place
11:31imirkin_: you only have 2 levels...
11:33Eliasvan: ah, ok, is that plausible, only 2 levels? (it's a laptop, so I would expect a whole variaty of perf states, like in a laptop cpu)
11:35imirkin_: 2's pretty common... low and high
11:36imirkin_: esp on fermi's... 3 is a bit more common i guess
11:36imirkin_: but 2's not unheard of
11:36Eliasvan: ah, ok, probably it's not that important, since it has optimus
11:36imirkin_: right, the idea is that the gpu is shut off when you don't need heavy accel in the first place
11:46tobijk: Eliasvan: i got only 2 levels here as well :)
11:46Eliasvan: ah, what a relief! ;)
11:47Eliasvan: besides, why does it detect an invalid level?
11:48Eliasvan: is it just an empty table that can support an additional level, e.g. when a firmware update is performed?
11:48tobijk: i'd guess that, yeah
11:48pmoreau: Eliasvan: I have 4 perflvl on both cards :þ
11:50imirkin_: it's not like they carefully craft these vbios's... there's some tool which probably just defaults it like that
11:50Eliasvan: maybe we can add new perf levels by writing to the vbios?
11:50imirkin_: sure. but you need to know what parameters to set
11:50imirkin_: er, what to set the various parameters to
11:50Eliasvan: ah, yeah, probably a lot of "don't care" values
11:50imirkin_: [and what they are]
12:00tobijk: airlied: ping!
12:46Eliasvan: imirkin: nvafakebios fails to upload the modified bios to the card (dmesg lines of "MMIO write failed" occur)
12:47Eliasvan: imirkin: I'll attach pastebin, just a moment
12:48imirkin_: yeah coz the card is probably off
12:48imirkin_: also don't do it while nouveau is running...
12:48imirkin_: that'll mess things up
12:49imirkin_: i don't think there's really any additional info i can give you on this... mess around with it, try to understand what's going on... good luck
13:00Eliasvan: ok thanks imirkin, in case you're still interested in the pastebin, here it is: http://pastebin.com/tNaMsGcQ
13:02utahcon: having a problem with GPU lockup, causes my entire session to hang, I was able to snap dmesg ( http://pastebin.com/xpit8YQ7 ) and journalctl ( http://pastebin.com/Aa6JiSMA ) before a reboot -- I think this second dmesg is most relevant ( http://pastebin.com/S0WDdRL3 ) where is has "[10157.126116] nouveau E[ DRM] GPU lockup - switching to software fbcon"
13:02utahcon: this has been going on for a while
13:03utahcon: kernel 3.17.7-300.fc21.x86_64
13:04pmoreau: utahcon: Do you remember when you started to get this issue?
13:05utahcon: after upgrading to F21
13:05pmoreau: Which kernel version did you have before upgrading?
13:06utahcon: I am unsure.
13:06Eliasvan: imirkin: thanks for the suggestion! "rmmod nouveau" did the job, I successfully wrote to the vbios!
13:06pmoreau: Could you try 3.18.x or better, one of the 3.19-rcX?
13:07tobijk: Eliasvan: did you actually change it? all vbios have the same checksum
13:08utahcon: pmoreau: I ran 3.19-rc3 for a day or so, and it failed out. I wasn't able to get dmesg from that failure.
13:08Eliasvan: tobijk: yes, the successful attempt is not in the pastebin ;)
13:08utahcon: I think it was the same error though
13:08tobijk: ah :)
13:08utahcon: if needed I can run it again and see what happens
13:09pmoreau: If you have the opportunity, it could be great.
13:09pmoreau: Do you recall at least one of the kernel you ran before upgrading to F21?
13:10utahcon: not specifically, just it was in F20, sorry.
13:11pmoreau: If you had it up-to-date, we should be able to find out which version it was
13:12tobijk: hm they both have 3.17? duh
13:13utahcon: my normal acts for gettting it to crash are... well sit and wait, any tips?
13:14tobijk: nah thats allright ;-)
13:15linas: git bisect bad
13:15linas: ad4a362635353f7ceb66f4038269770fee1025fa is the first bad commit
13:15linas: commit ad4a362635353f7ceb66f4038269770fee1025fa
13:15linas: Author: Ben Skeggs <email@example.com>
13:15linas: Date: Thu Sep 18 09:24:10 2014 +1000
13:15linas: drm/nouveau/bios: split out shadow methods
13:15tobijk: F20: kernel 3.11, F21: kernel 3.16
13:15pmoreau: utahcon: Considering when you upgraded to F21 and when (approximately) you updated for the last time your F20, you should be able to find which version you had using https://admin.fedoraproject.org/updates/kernel
13:15Eliasvan: tobijk: is it normal that after doing "modprobe nouveau" the vbios table gets reset?
13:18tobijk: Eliasvan: it loads it from somewhere and checks it
13:19Eliasvan: tobijk: because when the card is powered off I verified with "nvagetbios" that my previous write succeeded, but as soon as I modprobe nouveau, and then download the vbios via "cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom" to see whether the write is persistent, the write seems to be undone (overwritten by the default value)
13:19tobijk: i guess you need to specify from where it should load the vbios from
13:20tobijk: imirkin_: -^ (i dont remember the actual thing)
13:20Eliasvan: tobijk: in the linux boot parameters??
13:21Eliasvan: tobijk: but what if the file does not yet exist at boottime? (because of debugging purposes)
13:21tobijk: hang/fallback to the normal bios, dunno :)
13:22imirkin_: linas: so... it's basically the thing that i said. the patch i pointed out fixes that.
13:22Eliasvan: tobijk: ah, ok, but what if I want to modprobe the binary nvidia driver instead? Then I'm fairly sure the boot parameter will have no effect on the nvidia driver...
13:23tobijk: Eliasvan: right, as far as i remember it was a nouveau.xy= thingy
13:25linas: argh. imirkin_ I will try. .. the crash was before netconsole came up so I just plowed ahead slowly
13:26Eliasvan: tobijk: ah ok, so I can probably specify the parameter at modprobe-time of nouveau
13:27Eliasvan: tobijk: but what if I want to load the nvidia driver instead of the nouveau driver? I guess there is no nvidia.xy= thingy
13:28Eliasvan: tobijk: or do you think the "nvidia" driver will automagically load the one you uploaded to PRAMIN?
13:28tobijk: well nouveau should load the one from pramin as well
13:28tobijk: look at the dmesg
13:28Eliasvan: tobijk: weird, it doesn't
13:29Eliasvan: tobijk: dmesg gives the same output as without writing
13:29imirkin_: Eliasvan: why are you modprobing nouveau? you want to trace nvidia, not nouveau...
13:30imirkin_: it's probably overwritten because the card's powered off... vram is probably lost
13:30Eliasvan: imirkin_: yes, but I wanted to verify whether my write to vbios was persistent
13:30imirkin_: you need to make sure that the card stays on
13:30tobijk: oh that is a optimus system? grrr
13:31Eliasvan: imirkin_: but when I unload nouveau, the card automatically turns off...
13:31imirkin_: coz of bumblebee?
13:32Eliasvan: bumblebee is not running
13:32imirkin_: remove nouveau from your procedure. if you want to test that the vbios is uploaded successfully, use nvagetbios and make sure to use pramin
13:33tobijk: try booting with "nouveau.runpm=0" maybe that lets the card stay on...
13:33Eliasvan: ok, so I should disable nouveau from starting at boottime?
13:52Eliasvan: tobijk: nope, I tried it, doesn't make a difference
13:53Eliasvan: tobijk: and I think the card remains on, judging from the temperature
13:53tobijk: well skip nouveau then, as imirkin_ sugessted
13:55Eliasvan: tobijk: ok, by adding "nouveau.blacklist=yes" to the kernel bootline?
13:56tobijk: if that works, sure, i always use /etc/modprobe.d/myfile.conf with "blacklist xy"
14:04Eliasvan: tobijk: adding "nouveau.blacklist=yes" doesn't work: "unknown parameter 'blacklist' ignored"
14:05tobijk: well consider the option i suggested :)
14:05Eliasvan: tobijk: and I prefer doing it in the bootline (it's a nouveau live image, thus blacklisting it in /etc/modprobe.d/ and rebuilding the ISO is not worh the hastle)
14:06tobijk: ah allright
14:08tobijk: Eliasvan: modprobe.blacklist=module
14:08Eliasvan: tobijk: aha, thanks!
14:08Eliasvan: I'll try
14:08utahcon: pmoreau: I was most likely on 3.17.4, but certainly in 3.17.x
14:10tobijk: utahcon: you get hangs with with 3.18 and above right? nv84+?
14:10pmoreau: utahcon: If 3.19-rcX still fails, you could try bisecting between 3.17.4 and 3.17.7
14:11pmoreau: tobijk: NVCF, and hanging on 3.17.7
14:11tobijk: mh ok nevermind :/
14:14airlied: tobijk: pong?
14:14tobijk: oh hey
14:15tobijk: i saw you have a arb_cull_distance branch where you only use gl_clip_planes or similar
14:15utahcon: 3.19 just failed, but I wasn't able to switch to output any messagin
14:16tobijk: dont we need two arrays
14:17tobijk: if it is only one anyway "MAX_COMBINED_CLIP_AND_CULL_DISTANCES" would be useless
14:17pmoreau: utahcon: If you blacklist nouveau and modprobe it manually?
14:18tobijk: as there can be clipping and culling at the same time, as far as i understand
14:21airlied: tobijk: oh I was just hacking about
14:21airlied: I was going to do a gallium interface that had one array and a bitmask
14:21airlied: as they is how the hw seems to be structured
14:22tobijk: so to allow like two vec4 in the one array
14:23Eliasvan: tobijk: I successfully blacklisted nouveau, but if I now try to read (with "nvagetbios") or write (with "nvafakebios"), the laptop hangs...
14:24tobijk: Eliasvan: yeah to get the bios you'll need nouveau i guess...
14:24tobijk: save it somewhere
14:24Eliasvan: tobijk: no, I already have extracted the bios before
14:25Eliasvan: tobijk: and the writing only works if nouveau is off
14:25tobijk: airlied: let me know about the outcome of your hacking, i'm looking forward to implement it for nvc0 :)
14:26airlied: tobijk: well its way down my list of things to touch again :)
14:26airlied: it would be a good intro to writing a mesa extension if you wanted to try
14:27imirkin_: airlied: yeah, on nv50 (and i assume nvc0) there's one shared array. but at the glsl level, i think you can set both gl_CullDistance and gl_ClipDistance. and i think you're supposed to be able to do indirect addressing on them too.
14:27airlied: imirkin_: yes that seems likely alright
14:27airlied: I was thinking at tgsi of not allowing that
14:27airlied: since tgsi now is two vec4
14:27imirkin_: yeah, that'd be ideal. really annoying to deal with that.
14:28imirkin_: but... how to do the indirect indexing? (how is it done now for clip distance?)
14:28airlied: imirkin_: good point, now sure how we do that now
14:28imirkin_: maybe i'm just full of it and you can't actually do indirect indexing on either of those
14:29imirkin_: but iirc it was a concern
14:29imirkin_: when i looked at implementing when GL4.5 first came out
14:29airlied: oh glsl compiler does it
14:30airlied: so you get gl_ClipDistanceMESA
14:30imirkin_: how? giant if?
14:30imirkin_: right, which is the vec4's
14:31buhman: can has GL_ARB_tessellation_shader :3
14:31imirkin_: buhman: https://github.com/imirkin/mesa/commits/tess-gallium-4
14:31imirkin_: needs to get merged with mareko's stuff and chrisf's more recent work
14:31airlied: so we'd probably need to lower clip and cull to gl_ClipDistanceMESA
14:31imirkin_: but iirc it was passing many piglits at the time
14:31airlied: and have a bitmask ther
14:32buhman: imirkin_: doit
14:33Eliasvan: tobijk: maybe I should undo the blacklisting and just believe that the writing to PRAMIN (when nouveau is shut down after it was loaded once) succeeded (which seems to be the case according to "nvagetbios"), and then do the retracing of loading the binary nvidia driver (in the hope that it will read the correct PRAMIN bios)
14:33tobijk: dont know but can we do things like a vec2 for clip_distance and a vec4 for cull_distance?
14:33tobijk: Eliasvan: dont know if thats allright :/
14:34Eliasvan: tobijk: I don't really have any other option
14:34imirkin_: buhman: and there's a fp64 branch in there too... with those 2, you should get GL 4.0
14:34imirkin_: oh, and stupid subroutines... nevermind
14:34Eliasvan: tobijk: so let's hope the nvidia birary will play nice ;)
14:34buhman: imirkin_: dear santa..
14:34imirkin_: those will get done... some day... generically, i think
14:35tobijk: Eliasvan: i'd honestly be surprised, it always throws bugs on me ;-)
14:35buhman: would be hyper cool if the other two were merged
14:35imirkin_: buhman: yeah. i've been doing what i can to get the relevant people to push the core patches for those...
14:35imirkin_: ahem, airlied, *cough*
14:36Eliasvan: tobijk: yeah, maybe the whole combination of the laptop is not ideal for getting a good trace, but I will try anyway
14:36tobijk: so airlied: anyways push what you have and i'll try to finish it (lets see how thats going)
14:36airlied: tobijk: well that branch is where I was last I looked at it
14:37airlied: I was going to get distracted by writing piglit tests for it, but I really have to get back to my real work
14:37imirkin_: tobijk: writing some piglits would probably be a good way to go... iirc the extension has all sorts of funny provisions for sized vs unsized declarations too
14:38imirkin_: buhman: nothing uses fp64 or tess though, so it's not _such_ a huge deal
14:38tobijk: imirkin_: yeah the tests are the biggest hurldle, as i dont really know how to use glsl :D
14:39imirkin_: tobijk: no time to learn like the present!
14:39imirkin_: [yeah, it's a bit daunting at first.]
14:39buhman: wouldn't requesting a versioned core profile be easier than requesting individual extensions?
14:40imirkin_: buhman: nothing uses core profiles either :) but... you don't *request* things, they're either there or not, and so no reason to care about version if all you need are a few small bits.
14:41imirkin_: [ok, not quite true, things do use core profiles]
14:41buhman: if you do use the core profile though, you only get that and not everything, right?
14:41imirkin_: not the compat stuff. you still get all the various extensions that are available in core profiles though
14:41imirkin_: which is most of them
14:42buhman: even profiles higher than what you requested? O.o
14:42imirkin_: buhman: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
14:42imirkin_: every GL version above GL 3.2 is just GL 3.2 + a bunch of extensions
14:43imirkin_: GL 3.2 introduced geometry shaders which were different from the ARB_geometry_shader4 ones
14:43airlied: imirkin_: well I Think its just lazy GLSL writers
14:44airlied: who want to do #version 400 and move on
14:44imirkin_: airlied: yeah =/
14:44imirkin_: if i weren't so lazy, i'd rant against lazy people all the time
14:44buhman: I'd love to read that
14:46tobijk: imirkin_: thats good for your blood pressure, stay calm :P
14:46buhman: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#diff&b=version&g=NVIDIA%20GKxxx%20%28GeForce%20600%2C%20700%29 is really cool
14:47Leftmost: There's a disturbed part of me that's considered trying to implement ARB_geometry_shader4 in mesa.
14:47airlied: some of the pieces for that were done previously
14:47imirkin_: Leftmost: i don't even know what the differences are... afaik some link-time differences?
14:48airlied: it probably mostly exists in branches out there
14:48airlied: since I know someone dropped it at one point to concentrate on finishing the core
14:48imirkin_: paul berry iirc
14:50Leftmost: imirkin_, it's my understanding that it and EXT_gpu_shader4 encode some of the quirks of DirectX's shader model, making it much easier for wine to use them to translate DirectX shaders.
14:50imirkin_: Leftmost: ah, if you say so. afaik no one would oppose such an implementation.
14:50Leftmost: What little d3d10 support is in wine right now depends on them.
14:51tobijk: really d3d10?
14:51Leftmost: The question is mostly whether I can figure out what I'm doing long enough to carry it off. :)
14:53Leftmost: Still mostly trying to find entry-level projects at the moment.
14:53tobijk: Leftmost: depends what you are looking for, nouveau always needs help :)
14:55Leftmost: tobijk, most anything I can do to help, really. The biggest issue is that I have only two nvidia cards: a GTX 285 and a GTX 970.
14:55imirkin_: Leftmost: https://trello.com/b/ZudRDiTL/nouveau
14:55imirkin_: you can try to track down some of the nv50 bugs
14:55imirkin_: and/or fix them
14:57tobijk: whats gtx285, i forgot :/
14:57imirkin_: nva0 iirc
14:57Leftmost: Sounds right.
14:57buhman: or https://bugs.freedesktop.org/show_bug.cgi?id=70354
14:58imirkin_: yeah, _real_ appropriate for a beginner :p
14:58Leftmost: If it has more than four comments, it's beyond my ken. :)
14:59tobijk: Leftmost: so, we have mostly any kind of work, infrastructure (GL/GLSL), compiler and what not :D
15:06Leftmost: Would one of the green NV50 piglit failures be a good place to start?
15:06imirkin_: Leftmost: let me know which
15:07imirkin_: some of the green ones are just "well, i dunno why it's happening, so step 1 is figure out why -- that should be easy"
15:09Leftmost: I was considering the "nva0+: draw tfb errors".
15:09imirkin_: Leftmost: ah yeah. i've done some stuff on that
15:09tobijk: imirkin_: btw what happened to "Add CVT support in the constant folding pass"
15:09imirkin_: more than the patch linked in there... let me see if i pushed it
15:09imirkin_: tobijk: i lost it
15:10imirkin_: tobijk: resend it without the fp64 stuff?
15:10tobijk: want that split out? well ok if its not split, i'll do so
15:10imirkin_: Leftmost: my latest: https://github.com/imirkin/mesa/commit/c01bb891221e3cd3e030fc33042fd32a80a19cc4
15:10imirkin_: tobijk: i don't want it at all, split out or otherwise
15:10Leftmost: Cheers. I'll start looking into it.
15:11imirkin_: tobijk: it's not the appropriate place for it
15:11imirkin_: Leftmost: iirc pmoreau tested it, and said it still failed. on the bright side, it looks like draw-auto also fails on nvc0
15:11imirkin_: Leftmost: you can see various piglit results at http://people.freedesktop.org/~imirkin/
15:12tobijk: that was fast!
15:12tobijk: Leftmost: let me know if you got problem, maybe i can help you, but mostly ask imirkin :)
15:15Leftmost: Thanks, much appreciated.
15:16Leftmost: Is the current idea with Maxwell that we're waiting on nvidia to allow distributing their firmware?
15:17tobijk: yeah the last state i know is that they'll distribute the fw under a leasure license, so we can pick it
15:34tobijk: Eliasvan: so hows it going? :)
16:09Eliasvan: tobijk: ok, so I'll give a quick summary:
16:11Eliasvan: tobijk: I found out that placing the modified vbios in /lib/firmware, then calling "modprobe nouveau config=NvBios=vbios.rom" resulted in nouveau loading the modified bios
16:12Eliasvan: tobijk: Then "cat /sys/kernel/debug/dri/0/vbios.rom > out.rom" does indeed give the modified bios,
16:12Eliasvan: tobijk: then after "rmmod nouveau" when I run "nvagetbios ..." I also do get the modified bios
16:13Eliasvan: tobijk: (but after that, when I would load nouveau without specifying a vbios, will load the default non-modified bios)
16:14Eliasvan: tobijk: (and I can feel (heat) that the card is not switched off after doing "rmmod nouveau")
16:14tobijk: mh maybe nouveau loads it from the "hard" rom anyway to be sure
16:16Eliasvan: tobijk: And if I load the nvidia module instead: "modprobe nvidia" (with the modified vbios still in place), and then I perform a "nvagetbios ...", I get the modified one, so that seems to work!
16:17Eliasvan: tobijk: and after doing "rmmod nvidia", "nvagetbios ..." still gives the modified vbios.
16:17tobijk: that looks fine
16:17tobijk: just trace the blob with it
16:18Eliasvan: tobijk: yes, so it seems that 'nouveau' reads the vbios from the (slow) PROM, and 'nvidia' loads from the (fast) PRAMIN
16:19Eliasvan: tobijk: The only thing that still makes me doubt, is that "optirun glxgears" on the modified vbios runs about as fast (1100 fps) as the default vbios... Weird huh?
16:20Eliasvan: tobijk: there's something fishy going on here
16:20tobijk: well maybe there are other factors keeping it at 1100 fps, thats a lot
16:20Eliasvan: tobijk: I really hope you're right ;)
16:21tobijk: but be happy, i tried the blob a few minutes ago, it still oopses for me :D
16:22Eliasvan: tobijk: oh, did you know that the blob causes my desktop GTX760 to cause random hangs with screen-corruption, and nouveau is super-stable?
16:23Eliasvan: tobijk: anyway, that's a different story ;)
16:23Eliasvan: Thanks for all help, I will now have to take some sleep :)
16:23tobijk: sleep well :)
16:23Eliasvan: thanks ;)
16:54pmoreau: tobijk: Did you need testing for your OP_CVT patch?
16:55tobijk_: pmoreau: testing is always welcome
16:55tobijk_: the patch is quite old
16:55pmoreau: On which chipsets?
16:55tobijk_: digged it out and send it away :/
16:56tobijk_: nvc0+ included
16:56pmoreau: I only have nv50:nvaa + nvac
16:56tobijk_: yeah thats fine
16:57pmoreau: Are there some specific test to run, or something general?
16:57tobijk_: no just in general piglit
16:58pmoreau: Ok, will do that tomorrow -- need some sleep :)
16:59tobijk_: thanks, sleep well (as well) :D
17:01pmoreau: :D Thanks!
17:01pmoreau: Good night!