05:13 urjaman: yeah llvmpipe (aka export LIBGL_ALWAYS_SOFTWARE=1) is more useful than the NV34 OpenGL 1.5 of nouveau... the only pieces of software that seem to work with it are xcompmgr (=> transparent conky), glxgears and glxinfo :P
05:13 urjaman: kicad wants OpenGL 2.1 ...
05:14 urjaman: all games i tried just failed to start/crashed (including like Vice City, that i know runs on an FX series fine...)
05:25 imirkin: urjaman: patches accepted.
05:25 imirkin: urjaman: you could play neverball
05:25 imirkin: iirc stk had a gl 1.x renderer too
05:27 airlied: quake 1 :-P
05:29 urjaman: umm, neverball, doesnt work well enough for me to understand that it was trying to show a menu :P
05:30 urjaman: (i ran it with llvmpipe and "oh, a menu")
05:30 urjaman: there was something drawn yeah, some flying background element
05:30 urjaman: but none of the menu
05:32 urjaman: extreme tuxracer crashes
05:35 urjaman: but yeah i understand, and appreciate that this thing atleast has working multihead and video scalers etc, so thanks too
05:36 urjaman: but it's like, that 3D is practically 95% of the time (in my experience now) worse than llvmpipe
05:37 urjaman: oh yeah and kicad needs more than being said its 2.1 (some exception if you fake it)
05:38 urjaman: but yeah I've found a lot of things that dont behave well with ancient OpenGL version :P (extreme tuxracer crashes...)
07:51 kloofy: https://devtalk.nvidia.com/default/topic/471538/questions-about-__byte_perm-x-y-s-/?offset=4
08:08 kloofy: anxious kloofy does not yet understand all the combinations, it's just it's said there that it's twice as fast as arithmetic with bitwise
08:11 mupuf: karolherbst_work: yeah, I tried to add you but I did it wrong
08:11 mupuf: they changed the process
08:11 mupuf: I can try again
08:20 karolherbst_work: mupuf: k, you ust need the htpasswd thing?
08:20 mupuf: let me check
08:41 kloofy: i am yet hyptohesizing to optimize this further more, cause for instance radeon can have inline multiplier for vop3, so instead of for loop one could call with omod
09:22 kloofy: i am thinking about the format to pack masks still, all of the sudden, it's abvious that there are like, hundreds of ways..it's pretty complex to think what is the fastest, makes my head ache and think i have other things to do probably but..
09:27 kloofy: but i am not sure why nv50 aka nv98 or smth would not work with prmt..as the docs say it only needs sm2.0, i think one guy messed it up in the thread
09:28 kloofy: arget ISA Notes: prmt requires sm_20 or higher.
09:29 pmoreau: NV50 is sm1.x, SM2.x is Fermi
09:49 kloofy: pmoreau: ok, thanks, i messed up my own like always, thought this refers to shader model 2.0
09:53 kloofy: i vaguely just remembered that nv50 should support bitwise operations in hw, and this is also ptx 2.0 and sm2.0 requirement
09:58 rhn: mslusarz: nope, it's not clear what I should be seeing in the logs with fuzzer
10:01 rhn: hm, a bit better when I mess with it less, but again: how to read this: http://wklej.org/id/2773493/
11:06 kloofy: https://hpcforge.org/scm/viewvc.php/*checkout*/doc/opennvisa/opennvisa.pdf?root=kernelgen
11:12 kloofy: kind first time looking, but, interesting is the suffix stuff
11:12 kloofy: and the scheduling command decoding stuff there
11:42 mwk:wonders if this thing actually works
11:53 kloofy: https://devtalk.nvidia.com/default/topic/913167/sass-code-analysis/
11:55 kloofy: but do not know what instructions if memory load instruction registers would allow also carry out
12:06 kloofy: imo still a dead end, looking at the smrd from amd isa, looks like the needed offset field, can be inline constant, not sure if they could carry out
12:12 mwk: alright, so how do I submit a method to NV3 PGRAPH... it was so simple on NV1
12:13 kloofy: kind of a headache, of course though if carry could work against arbitrary regs of arbitrary instructions, then gather can work, i am then very shocked, then bridgman had it all spot on
12:22 kloofy: then in place offset encode a mask, and compiler shifts the base address right my mask, i.e just substracts the mask from the base
12:27 kloofy: than in the handler carry out to m0, stuff is done, but needs reading if that really is allowed
12:28 kloofy: i don't think it is allowed
12:48 kloofy: it seems resident loon kloofy is not making any sense again..
12:55 kloofy: neither does the isa..because they do not allow writing to the memory i'd have to poke the cache where the load word is, it could work fast only if that was some sort of direct tagless access via the cache slot
13:01 kloofy: i always remember what everyone says , imo the suggestion that gather can work well to do the mask loading, was indeed correct , looking at the pm, he had some minor other concerns
13:06 kloofy: though the masks are 4 16 32 and 64 probably, inline constant would allow storing up to 64 anyways
13:11 kloofy: not sure what the amd way is but we looked that fermi and kepler would allow that direct access imo in even both ways, it also allows to use l1 as shared memory
13:12 kloofy: it is also documented that at least radeon allows to setpc directly from sgpr
13:18 kloofy: anything else you'd want me to read? as if maybe someday you have a real problem to work out, i highly doubt there, as i don't see anything at the horizon at the moment too
13:19 kloofy: well the scheduling opcodes are said to be about some delay programming in the pipeline for latency hiding
13:20 kloofy: i do not want to deal with this, cause i basically think the different way is even better, but... who knows
13:23 kloofy: i have one bloke here who has 2x gt755 sli in a laptop
13:23 kloofy: like maybe what is the state of SLI's driver support?
13:27 kloofy: it's yeah some powerful laptop he has, i haven't reached yet to such equipment 1.250billion transistors each, and yeah runs every game known in hd resolution
13:37 kloofy: actually being stupid and violating my rights is two different things, as i've read in the past what bridgman has written, i anyhow knew very well his not stupid, however people here are also stupid unfortunently while you maybe a little lazy but at least head is almost ok for the devs
13:39 kloofy: and he did not call me stupid either just a bit worries he had if this plan of what i've talked about would really work out in couple of details on amd hw
13:40 mupuf: kloofy: what is this rambling all about?
13:41 kloofy: mupuf: it was something about if the hw was capable of reforming waprs among simd units after masks have specified, i have it in pm, i have not checked about
13:42 kloofy: mupuf: nothing much, usual stuff, i scored another ban on radeon
13:42 mupuf: that would be stupid if it did not
13:44 kloofy: and it was just about, that people tell me that i think amd devs are stupid, i said above, that i cearly do not
13:45 kloofy: mupuf: well me and him was very positive enough to test the idea if we could make scheduiling better overall
13:45 kloofy: in august, maybe or maybe not i will receive an amd gpu too, and try to make it happen
13:48 kloofy: mupuf: you should be right on that, i can't remember about amd, on one of them the strategy is known to work, i read it from reports
13:54 kloofy: mupuf: also i head off now, i talked about the obvious workaround of minor bugs in the driver, if those are cpu locking bugs, then lockless versions when there is enough memory as workround is pretty easy
13:55 kloofy: but fixing the locking so that locks will still be held, could occationally have some unexpected behavior, like RSpliet said
14:00 kloofy: don't wanna talk about this same stuff again, whole google is full of my stuff, however it was precise, somewhere in radeon dri-devel raw logs it is
14:02 kloofy: mupuf: it's non the less something that all c programmers know anyways, that the kernel feeds stack and heap for the cpu memory wise, while in c++ those are classes that have specifiers for their members, in c
14:02 kloofy: it just is that dynamic malloc and stack objects
14:04 kloofy: mupuf: ah ok, so when you pin the vram handle with malloc into the same address for every context/thread, that is shared, while stack structures are private
14:05 kloofy: it's the usual stuff, cause heap and stack meet in the middle and form the virtual address space of the program
14:09 kloofy: it's just when you have vram handle and bunch of flags, you copy to the per context structures of c, that stuff, in mesa those are named buffers, it's very elegant mostly everything is handled by kernel
14:19 kloofy: dunno like for instance context/thread 1 shares a named hello vbo with thread/context 2 the vbo is malloced and copied to the structures maybe hello even or apprioriate gluint of thread 2 which is kept on per context stack
14:24 kloofy: some log on and freak out and loose hair and i dunno launch bombs in crowded places, while maybe not thinking that it is just that simple in theory, while i agree that most devs know that stuff i told
14:24 kloofy: largely for users this talk was
14:34 kloofy: sorry about the spam, looks as if problems are solved , and noone has not got any questions either..
14:36 kloofy: i am yeah long since offputed, feeling bit ill, looks as if yet some thinking sometimes is possible to be carried out, imo i have made it ... to understand the tact of how things work
14:41 kloofy: i am user my own too, never made any large projects, small things here and there, health did not allow for longer time to manage heroics, thinking has been slow
14:41 Lekensteyn: kloofy: please take a break and have a chat with some friends in a pub or something, it is getting a bad spammy ;)
14:46 kloofy: yeah Lekensteyn good call, yeah i go, i was saying that when i was put onto pressure my own, i broke very often too..kinda lost it and took too much time off, it's cause i injured myself, cheers.
15:06 urjaman: oh, the kicad 3D model viewer works :)
17:29 mslusarz: rhn: you found a bug in mmt (notice how regions overlap), unrelated to fuzzer, probably triggerable without it
17:29 mslusarz: fix it and you will start seeing real fuzzer messages
17:30 rhn: mslusarz: what are those regions?
17:30 rhn: is this mmt's tracking of mmaps?
17:30 mslusarz: almost
17:31 mslusarz: to speed up address lookups it keeps some caches
17:31 mslusarz: one of those caches became inconsistent
17:36 r3m: Hi, I guess you heard that question many time before, Is the GTX 970 supported by Nouveau or I need to rely on proprietary drivers?
17:37 imirkin_: r3m: what is your definition of 'supported'?
17:37 imirkin_: i think for most definitions of 'supported', nouveau fails.
17:38 imirkin_: but there are probably some for which it passes. unless you have a 4GB GTX 970, which is known to not work at all.
17:38 r3m: yes I have this one
17:39 r3m: is the proprietary drivers fine in general when we install it via a repo
17:39 imirkin_: proprietary drivers are supported by a team of paid developers with access to hardware and documentation. as long as you're fine with running random kernel code you download on the interwebs, it's all good
17:40 imirkin_: if you're not, then you've purchased an expensive doorstop
17:41 r3m: ok thanks
17:47 karolherbst: hakzsam: what do you think about splitting Notes into Performance and notes?
17:47 karolherbst: on the Gamedatabase page
17:48 imirkin_: karolherbst: have a look at the source of that page
17:49 imirkin_: my idea was to move all the info into json
17:49 karolherbst: yeah, I noticed
17:49 imirkin_: i did it with one entry, leaving the rest unfilled
17:49 imirkin_: i think it can easily aggregate data into a more useful table
17:49 karolherbst: the entry isn't shown for me though I think
17:49 imirkin_: that said, i don't plan on actually adding stuff myself, so up to you guys
17:49 imirkin_: really?
17:50 imirkin_: worksforme on nouveau
17:50 imirkin_: er
17:50 imirkin_: on chrome
17:50 karolherbst: odd
17:50 imirkin_: anything on the console?
17:50 karolherbst: ahh
17:50 karolherbst: the preview is borked
17:50 imirkin_: oh yeah, it won't work on the preview
17:50 karolherbst: :/
17:51 imirkin_: anyways, wtvr - it's up to you guys. i hacked it together quickly since i figured it may be useful.
17:52 karolherbst: maybe when I find some time I could make it searchable and stuff :p
17:53 imirkin_: i thought that having a table with diff chipset groups made more sense than having independent reports on each row
17:53 imirkin_: fwiw we used to have a page like that of "supported hardware"
17:53 imirkin_: which was a disaster
17:54 karolherbst: odd
17:54 karolherbst: well I made a nice php script for collecting games from steam account with a nice search box :p
17:54 imirkin_: https://secure.freedesktop.org/cgit/nouveau/patch/HardwareStatus.mdwn?id=3e16edcd74f302d94363b42525bc3fba753a4b46
17:55 karolherbst: ugh
17:55 imirkin_: the information on it was just not that useful, and constantly out of date
17:55 karolherbst: in the end we need something where users can also report things
17:55 imirkin_: like ... "works, some instability" - wtf are you supposed to do with that info
17:55 karolherbst: just like the wine app database
17:58 r3m: imirkin: another question
17:59 r3m: imirkin: I will sold my card to someone, I dont need this power, so which card is the most powerful that nouveau support very well
17:59 r3m: please, would be really appreciated
17:59 karolherbst: what does "correct" performance means anyway? :D
17:59 r3m: sell*
17:59 imirkin_: r3m: the most powerful best-supported consumer-class card by nouveau is the GTX 780 Ti
17:59 r3m: thanks a lot!
18:00 imirkin_: r3m: note that AMD GPU's are supported by a full-time team
18:00 imirkin_: r3m: so if you're looking for the best open-source experience, AMD is likely to be it.
18:00 r3m: imirkin_: thanks
18:00 imirkin_: [assuming you need something with a bit more muscle than intel can provide, otherwise intel is quite good too]
18:02 karolherbst: imirkin_: I tidied up a little : https://secure.freedesktop.org/cgit/nouveau/tree/GameDatabase.mdwn
18:03 karolherbst: much nicier now :p
18:03 imirkin_: ok
18:04 karolherbst: if we manage to keep it clean like that, I think it won't be a disaster in the end (for now)
18:04 imirkin_: if you're using a git snapshot, use git describe
18:04 imirkin_: that way it'll give an idea of when the git snapshot is from
18:05 karolherbst: mhh, I doubt anybody cares that much about it
18:05 karolherbst: usually you just want to check if a game runs good enough
18:06 karolherbst: if it doesn't for you, but the page states it does fne, then you check the version
18:06 imirkin_: also, fyi, that table is too wide to fit on a 1200-wide screen without wrapping
18:07 karolherbst: but we really want to have something like the wine app db
18:07 karolherbst: I don't see any problems in lines being wrapped
18:07 karolherbst: or do we want to have scrollbars?
18:07 imirkin_: no
18:07 imirkin_: just pointing it out
18:08 karolherbst: well, somebody wrote a lot for stellaris
18:08 r3m: imirkin_: is the gtx 950 is well supported?
18:08 r3m: i just want a simple card that can manage 3-4 monitor
18:08 karolherbst: r3m: basically maxwell2 is useless if you need perf
18:08 karolherbst: uhh 3-4 displays is also a bit very untested under nouveau
18:09 r3m: well 2 is enough
18:09 r3m: :)
18:09 imirkin_: r3m: not well. anything in the gtx 950+ range is GM20x, which requires firmware signed by nvidia for accel to work.
18:09 r3m: imirkin_: what is a cheap card that is well supported and still sold new
18:09 imirkin_: they've released a small fraction of the firmware required, but hardly all.
18:09 r3m: i mean not very old
18:09 imirkin_: r3m: GT 730
18:09 r3m: merci !
18:10 karolherbst: mhhh
18:10 karolherbst: beware of the GT 730 though
18:10 karolherbst: you might grab a fermi one
18:10 karolherbst: and the fermi is like 30% as fast as a kepler 730 one :p
18:10 imirkin_: oh yeah... make sure it says it has 192 or 384 "cuda cores"
18:10 imirkin_: if you see 96 or 48, it's a fermi
18:10 r3m: karolherbst: thanks
18:11 karolherbst: or just grab the gddr5 one
18:11 imirkin_: that's more expensive :)
18:11 karolherbst: well, I doubt that though
18:12 karolherbst: ohh the kepler2 is also available with ddr3?
18:12 karolherbst: k
18:12 imirkin_: yes
18:12 karolherbst: 50€ for a gddr5 one
18:13 imirkin_: http://www.newegg.com/Product/Product.aspx?Item=N82E16814500367
18:13 karolherbst: 46€ for a ddr3 one
18:13 karolherbst: k, so the 50€ is cheaper :p
18:14 imirkin_: fanless :)
18:14 imirkin_: one less thing that can go wrong
18:14 karolherbst: :D
18:15 karolherbst: ASUS GeForce GT 730 (GK208) Silent, GT730-SL-2GD5-BRK
18:15 karolherbst: but this one is a bit expensive
19:55 karolherbst: odd, did my mail came through? git-send-mail crashed somewhat, but I got a 250 response before that "error: git-send-email died of signal 11"
19:56 imirkin_: karolherbst: i received it.
19:56 karolherbst: k
19:56 imirkin_: i assume you mean "nvkm/iccsense: Parse the resistors and config the right way"
19:56 karolherbst: then mailman is messed up again probably
19:56 karolherbst: yeah
19:56 karolherbst: it doesn't show on the list. page, that's why I asked
19:56 imirkin_: huh. i don't see it on lists.freedesktop.org...
19:57 karolherbst: yeah
19:57 karolherbst: it happend once before, where the mails came through, but the site didn't display them right, or something like that
19:59 imirkin_: it's there now
20:00 karolherbst: mhh, right
20:00 karolherbst: I thought it is actually faster
20:00 karolherbst: it took like 10 minutes though
21:22 hakzsam: okay guys, mesa master now exposes GL4.1 on maxwell, enjoy!
21:27 karolherbst: ya1y
21:27 airlied: hakzsam: nice!
21:28 karolherbst: hakzsam: do you have a maxwell2 gpu by the way? allthough I could try to upload our pmu image on reator too to check if we can reclock the memory in theory
21:28 hakzsam: yep
21:28 karolherbst: guess I play around on the weekend then
21:28 hakzsam: karolherbst, nope
21:28 hakzsam: but I'm currently using reator, sorry...
21:28 hakzsam: trying to figure what the fuck is going on with MP perf counters
21:28 karolherbst: yeah no worries, I will be heading to bed like pretty soon anyway
21:29 karolherbst: hakzsam: ohh, what issue?
21:29 hakzsam: reator will be for you all the week end :)
21:29 karolherbst: awesome
21:29 hakzsam: a mux
21:29 karolherbst: huh?
21:29 hakzsam: and maybe other issues ;)
21:30 karolherbst: well, if you think they are stable enough, ping me and I break it again :p
21:30 hakzsam: but you don't have any maxwell gpus?
21:30 hakzsam: they work fine on fermi/kepler, except the problem you know :)
21:31 karolherbst: nope, I don't. didn't know you were talking about maxwell specifically
21:31 hakzsam: but it will be fixed at some point anyways
21:31 karolherbst: k
21:31 hakzsam: it's also somehow required for global (graphics) perf counters
21:31 hakzsam: this batch of counters thing
21:31 karolherbst: well, I plan on being my next gpu a maxwell one :p
21:31 karolherbst: big plans already :D
21:31 hakzsam: cool
21:32 karolherbst: now that I am kind of done with kepler
21:32 hakzsam: you will be able to report me bugs :)
21:32 karolherbst: sure
21:32 hakzsam: well, no GL4.3 yet
21:32 hakzsam: but it's on the way
21:33 karolherbst: right, no idea if I will fine much time in the future now anyway :/ it is more troublesome finding some time for other stuff once you have a full time job and pretty much underestimated it, allthough I had one before :/
21:34 hakzsam: yeah, not easy to find free time
21:35 karolherbst: I should make saturday my nouveau day and lock me in doing nothing else :D
21:36 hakzsam: hehe
23:06 imirkin_: skeggsb: [ 594.924084] Kernel unaligned access at TPC[105bdfb4] nvkm_instobj_wr32+0x14/0x20 [nouveau]
23:06 imirkin_: thoughts on what that could be due to?
23:07 imirkin_: the things i fixed were in nouveau_bios_init & co
23:07 imirkin_: [this is on a NV34 in case it matters]
23:09 imirkin_: errrrrr
23:09 imirkin_: oops
23:09 imirkin_: for (i = 0x15ac; i <= 0x271c ; i += 16) {
23:09 imirkin_: nvkm_wo32(chan->inst, i + 0, 0x10700ff9);
23:09 imirkin_: nvkm_wo32(chan->inst, i + 1, 0x0436086c);
23:09 imirkin_: nvkm_wo32(chan->inst, i + 2, 0x000c001b);
23:09 imirkin_: skeggsb: that's gotta be wrong :)
23:10 imirkin_: in nv34_gr_chan_new
23:10 imirkin_: looks like nv30 has the same bug. nv35 is good though.
23:16 imirkin_: skeggsb: patch sent :)