01:37gnurou: actually, it seems like Nouveau should technically be able to reclock gm2 even without PMU FW
01:38gnurou: it just would not be able to switch the fans on :)
01:40skeggsb: yeah, one of your guys told me recently that our PMU ucode should still be able to access non-priv registers
01:41skeggsb: weird, considering fecs/gpccs can't even touch gr regs..
01:41skeggsb: wonder if we could do gr ctxsw on pmu ;)
01:41skeggsb: i can from the host, except it's horribly slow
02:10gnurou: Ryushin: what did you want to ask me btw? (sorry, too lazy to follow IRC log)
03:22kloofy: ma notin need kõik maha
03:23kloofy: mul on umbes kümme inimest nimekirjas, ja need saavad viisakalt surma
03:25kloofy: was a good joke , but time to be responsible, and no one wants to be there...but i know who made me feel rough times
03:25kloofy: and forgive me, but i am going to kill them
03:27kloofy: world wide guys, houston we have a problem...we have those..you know...
03:27kloofy: they want to get some..
03:30kloofy: ouh damn it, karolherbst those guys are not getting anyway near getting the drift...
03:30kloofy: how the hell can those be so stupid
03:32kloofy: ouh lord that is digsuting..it really is
03:32kloofy: mofos are so friggin stupid
03:33kloofy: you look at a person, and you say like die you will
03:34kloofy: and you never understood shit
03:35kloofy: i dunno terrible really
03:37kloofy: tupac once rapped to my unborn child, but those looked like a freaking unborn persons overall
03:39kloofy: do you want to see, what we have on offer in mental institution, this shit is wack
03:39kloofy: ouh come one dudes
03:40kloofy: türa tere hommikust tainapead raisk!
03:43kloofy: wtf ..i give out the names shortly, those who put me to coffin
03:43kloofy: i hope they will serve good days...I "HOPE"
03:44kloofy: just names, and friggin world wide persons, kille them oll please if you may
03:46kloofy: men just terrible really...
03:47kloofy: i am a bit violent this time around, but those guys i want to squeeeeeeeeeeze their nuts fucos
03:48kloofy: behind the fucking lines, there is always so fucking stupid person that it makes me sick
03:49kloofy: and what the fucking moran, i drink 3.5liters in a day and i can't see the point why were you fucking brought to this life
03:52kloofy: yeah those mofo pills they kill high time
03:53kloofy: and but we hope to get a revenge
03:55kloofy: terrible really your looking at a nonsense person, who ...
03:55kloofy: what the hell did they do, they even took away my rights..
03:56kloofy: and you are looking at a kindly said, at a piece of a good shit
03:58kloofy: you're looking at a such a moran where you lack the words
04:00kloofy: ajax wtf. its just terrible man
04:03kloofy: go there on your own, and judge me, mofo
04:03kloofy: those ain't registering stuff
04:04kloofy: terrible mofucking cow tells me that i am crazy
04:06kloofy: such a fucking nonsense human, that you are proud to be a brit, but not proud to pick a fight with me
04:30huelter: pills here
04:30skeggsb: it's *so* hard not to engage :P
04:31huelter: he really need to take his pills
06:57hakzsam: imirkin_, did you test the ARK free demo? :)
08:18pmoreau: skeggsb: Ping https://lists.freedesktop.org/archives/nouveau/2016-April/024687.html and https://lists.freedesktop.org/archives/nouveau/2016-May/024902.html
08:26Akien: Hi there
08:27Akien: I was thinking that it would be nice to add info about reclocking on https://nouveau.freedesktop.org/wiki/Optimus/ (indicating the minimal kernel version for each method)
08:27Akien: Right now it only mentions that nouveau can't do reclocking yet
08:29pq: Akien, how about just a link to https://nouveau.freedesktop.org/wiki/PowerManagement/ ?
08:30Akien: pq: That would be a good start yeah. Though some more details about how to use reclocking on the cards that have experimental support for it would be useful too.
08:30Akien: (there might already be an existing page about it that could simply be linked)
14:38gouchi: The support according to the Features Matrix for NV46 (G72) graphics card is mostly
14:39gouchi: Is there any parameters that can help to get a correct display ?
14:39gouchi: I mean for TV-Out
14:39imirkin_: that should Just Work (tm)
14:39imirkin_: you're talking about like s-video right?
14:40imirkin_: yeah that should work. lol, it tries to set a 320x240 mode? that seems ... low
14:40imirkin_: on my NV34, s-video defaults to 720x576 (a pal mode)
14:41imirkin_: anyways... what's the precise issue you're having?
14:41gouchi: " outputs to the CRT using some odd resolution and/or refresh rate, as it's grayscale and is rapidly scrolling/flipping vertically like the "vertical hold" "
14:41imirkin_: yeah ... for some reason it tries to set 320x240, which i'm sure the encoder isn't amused with
14:41imirkin_: is it PAL or NTSC?
14:42imirkin_: or one of the funny variants?
14:42imirkin_: if it's an actual TV, esp an old one, you might have to set the tv_norm kernel parameter. have a look at https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
14:43gouchi: imirkin_: thank you
14:43imirkin_: (pal is the default)
14:43imirkin_: i can't remember what pal looks like on ntsc... but it might be what you describe
14:44imirkin_: although with s-video the chroma is separate. dunno.
14:55gouchi: imirkin_: about https://bugs.freedesktop.org/show_bug.cgi?id=94727
14:55gouchi: imirkin_: I got it sometimes when I see video with mpv player as it using opengl video output
14:59imirkin_: gouchi: are you sure it's the same issue? that specific assert is failing?
15:04gouchi: imirkin_: mpv: pushbuf.c:238: pushbuf_krel: Assertion `bkref' failed.10s+3MB
15:04imirkin_: certainly *seems* similar ;)
15:08imirkin_: well my original analysis was that mpv was doing something multithreadedly
15:09imirkin_: you can pull it up in gdb and do "i threads" when you hit the assert
15:09imirkin_: if there are multiple threads calling into nouveau, then that'd be why
15:09imirkin_: at the time i assumed it was due to vdpau + gl
15:09imirkin_: but it could be something else.
15:14gouchi: I am not using vdpau
15:15imirkin_: i know - i've disabled vdpau on nv4x :)
15:19gouchi: I see
15:19imirkin_: some dumb issue somewhere i never cared to identify. but XvMC works
16:39darlac: Is here anyone with NV94 DDR2 card?
16:40imirkin_: huh, i'd be a bit surprised if those were made
16:47Tom^: imirkin_: 9500 gt it seems.
16:47imirkin_: maybe, i guess
16:47imirkin_: i figured those would have ddr3
16:47Tom^: hm http://www.geforce.com/hardware/desktop-gpus/geforce-9500-gt/specifications
16:47imirkin_: also, wait, those are G96's
16:47imirkin_: i have one ;)
16:48imirkin_: G94 are 9600 GT's
16:48Tom^: i see
16:49imirkin_: which are only listed as ddr3... i guess the "GSO" ones could have been ddr2?
16:52karolherbst: I can't push to github anymore
16:53Tom^: why not?
16:54karolherbst: 503 returned
16:54karolherbst: ahh now it worked
16:54karolherbst: :) I tried 20 times
16:54night199uk: anyone know owt about maxwell reg 0x612488/0x612408?
16:55night199uk: envytools/rnndb does not
16:59karolherbst: darlac: asking because of reclocking?
17:00karolherbst: I guess you tried and it failed?
17:01darlac: I enabled ddr2 reclocking on nv96 and it works
17:03karolherbst: and nv94 fails I guess
17:04darlac: i don't know ;p
17:21darlac: karolherbst: Are you going to add support for pre PMU cards in your dynamic_reclocking branch?
17:24karolherbst: darlac: at some point maybe, no idea though how it will work there
18:03karolherbst: imirkin_: I was thinking about doing a pass to move instructions out of loop when possible, but I somehow fail to find out if the new position is better or worse. Like my idea was to check the bb of the sources of an instruction and move it to one of those sources, when they are in different BBs
18:03karolherbst: but I think this is too optimistic
18:04imirkin_: the thing is that it can extend live ranges
18:04karolherbst: I know
18:04imirkin_: and we don't have materialization
18:05karolherbst: but I think increasing live ranges shouldn't be a big problem as long as we move instructions out of loops
18:06karolherbst: I tried to do it for unary instruction first, so that the affect on live ranges is minimal
18:06karolherbst: but the instruction count per frame went up
18:08karolherbst: Anyway it would good to have a way to somehow know where two BBs are located in the CFG, so that we can easily know if we would move an instruction out of the loop
18:10karolherbst: by the way, currently I run piglit on those 6 commits and will send them to the ML after I am sure I didn't break anything in those: https://github.com/karolherbst/mesa/commits/to_upstream
18:30karolherbst: imirkin_: this sounds interessting: https://trello.com/c/bW7SYHtW/56-add-pass-to-set-liveonly-on-tex-instructions-when-possible
18:30imirkin_: go for it.
18:30karolherbst: imirkin_: so for every tex instructions it has to be checked if following the def leads to quadop instructions?
18:30imirkin_: or another tex instruction's coordinates
18:30karolherbst: mhh which part of tex is this?
18:31imirkin_: the first bunch of arguments (bunch = tex->tex.getArgCount() )
18:31karolherbst: and the bit is currently always emited in the emiter?
18:32imirkin_: the emitter knows how to emit the bit
18:32imirkin_: it's just never set
18:32imirkin_: you can change it to always be set
18:32imirkin_: and see what the perf difference COULD be
18:32imirkin_: (i'm guessing minor)
18:32karolherbst: this was my first thing to do :D
18:32karolherbst: yeah, found it
18:33karolherbst: piglit still running, but I am looking for something to improve the perf and which isn't too hard to do
18:33imirkin_: also note that this isn't just direct uses
18:33imirkin_: this is the whole use chain
18:33karolherbst: searching for simple algebraicopts is kind of expensive now
18:33karolherbst: yeah, I know
18:33karolherbst: until the end of the shader I assume?
18:34imirkin_: well, to walk the use chain
18:34imirkin_: you just look at the def's uses list
18:34karolherbst: can there be shaders without any quadops?
18:34imirkin_: like 99.9999% of them
18:34karolherbst: I could check for that for now :D
18:35karolherbst: sounds cheap then
18:35imirkin_: but ... another tex can also happen
18:35imirkin_: and tex's without an explicit lod or explicit derivatives will use the coordinates to calculate implicit derivatives
18:36karolherbst: I assume when I always set that bit, I should _see_ a difference if something goes wrong?
18:37imirkin_: not definitely
18:38imirkin_: it could just be running less efficiently
18:38imirkin_: as a result of pulling from the wrong miplevel
18:38imirkin_: since most people who aren't writing tests put the same data into all miplevels
18:38imirkin_: so you can't necessarily tell which one you pulled from
18:40karolherbst: meh, even parallel piglit is really slow :/
18:51karolherbst: yay, no change in piglit
18:53karolherbst: forgot to recompile
18:56imirkin_: you'll definitely get fails in piglit
18:57karolherbst: I meant for my other opts
18:57karolherbst: mhhh odd, no change in heaven so far
19:00karolherbst: furmark: 47-50 fps => 54-58 fps
19:00karolherbst: which is faster than nvidia
19:00karolherbst: so around 15% more perf through that bit
19:00karolherbst: sounds, good enoug :)
19:01imirkin_: wow, that's a lot more than i thought
19:01imirkin_: obviously that's not fully allowed to just do it whenever
19:02imirkin_: but as long as results aren't used in implicit derivatives or quadops, you're good
19:02karolherbst: I just want to know if it makes sense to work on that
19:02karolherbst: will now test it on some eon games
19:05karolherbst: imirkin_: so we can always enable that bit when there is only one tex and no quadop as a "fast" way to enable it at least for a few shaders
19:06karolherbst: but that pass can become rather expensive :/
19:10karolherbst: "gr: DATA_ERROR 0000000c [INVALID_BITFIELD] ch 2 [00bf890000 TombRaider] subc 0 class a097 mthd 238c data 20050004"
19:10imirkin_: karolherbst: yes, that would be legal
19:10imirkin_: what's 238c? i think there's a command out of place
19:10karolherbst: but hey, at least the hardware tells us this is wrong :D
19:10karolherbst: maybe random mess up again
19:11karolherbst: random mess up
19:11karolherbst: now it works
19:12imirkin_: that's way too high for CB_POS
19:12imirkin_: that means there's some command strema corruption
19:12imirkin_: which likely means multi-thread bs
19:14karolherbst: mhh, it seems like that bit doesn't have a big effect on games
19:14karolherbst: or maybe those games are too shader centric
19:14karolherbst: something with many tex operations should benefit from that I assume
19:24karolherbst: uhh talos principle crashed my gpu
19:31karolherbst: imirkin_: well in the end having 15% more perf in furmark can't be that bad, even if it doesn't really affect anything else...
19:31karolherbst: something might get speed up
21:13karolherbst: "[21587/21587] skip: 2216, pass: 18831, warn: 4, dmesg-warn: 5, fail: 527, crash: 4" this looks okay I guess?
21:13imirkin_: not really
21:13imirkin_: that's a lot more fail than i remember =/
21:13mupuf: karolherbst: revert your patch and run piglit again :p
21:14karolherbst: I am sure that I ran it on stock mesa
21:14karolherbst: but the git tag doesn't get updated, so I don't know
21:14imirkin_: well, a bunch of tests have gotten added
21:14imirkin_: so i could just be behind the times
21:15imirkin_: i remember the number of fails being somewhere around 150 though
21:15karolherbst: let me check what fails
21:15imirkin_: 200 at the outside
21:15karolherbst: geom-conversion-explicit* stuff?
21:15imirkin_: those are new
21:15imirkin_: are those failing with points??
21:15karolherbst: those fail a lot
21:15karolherbst: 100 of those
21:15imirkin_: can you pastebin a list of fails from piglit-summary.py?
21:16karolherbst: arb_shader_precision fails a lot too
21:16karolherbst: 1269/1509 pass rate
21:26karolherbst: updated: https://gist.github.com/karolherbst/2567abc44af9dc0ed6edd06aa2503574
21:26karolherbst: now it looks nice :D
21:27karolherbst: it is mostly spec/glsl-4.10/execution/conversion/ and spec/arb_shader_precision/ which fails
21:27imirkin_: karolherbst: you have an out of date piglit
21:27karolherbst: can't be
21:27imirkin_: karolherbst: or rather, you have a piglit with out of date generated files
21:27karolherbst: I just fetched and builded today
21:27imirkin_: yeah, but old generated tests don't get deleted :)
21:28karolherbst: I see
21:28karolherbst: so I deleted bin? or something else?
21:29karolherbst: well maybe make clean is smart
21:36karolherbst: and now there are only 20396 tests
21:37karolherbst: running without --dmesg is really fast :O
21:37karolherbst: already at 20%
21:41karolherbst: kwin froze real hard though
21:51karolherbst: imirkin_, RSpliet: can you remember why this change was reuquired/right? https://github.com/karolherbst/mesa/commit/c7bd53ccc9e6101451b59d25085540d227bd8f3a#diff-46df282115646e17aa1321265c4e170aL2962
21:53imirkin_: prolly something to do with nv50
21:53imirkin_: and wanting to take non-floats? dunno
21:54imirkin_: that does seem wrong though
21:55karolherbst: yeah, that's why I am asking
21:55imirkin_: probably should be > 2
21:55imirkin_: or >= 4
21:56karolherbst: ohh wait
21:56karolherbst: this was something funny
21:57karolherbst: see that else branch?
22:00karolherbst: I guess this affects tesla cards?
22:00karolherbst: no idea if fermi has the same oddity
22:01imirkin_: it's for tesla
22:01imirkin_: tesla doesn't have a 32-bit integer multiply (or mad)
22:01imirkin_: only 16-bit (and 24-bit)
22:02karolherbst: so should it be "typeSizeof(i->sType) >= 4" then or something else?
22:02karolherbst: I think now I understand
22:03imirkin_: not sure
22:03imirkin_: would have to check wtf it's doing
22:03imirkin_: but i think so, yes.
22:04karolherbst: at least >=4 wouldn't cause any harm?
22:04RSpliet: a good indication the code is either wrong or insufficiently commented O:-)
22:05karolherbst: there is also this "i->getDef(0)->reg.data.id >= 64" check
22:05karolherbst: which doesn't matter for kepler
22:05karolherbst: but what about fermi? and does the same constraint apply there?
22:06imirkin_: i mean
22:06imirkin_: on fermi it's always <= 63 no matter what
22:06karolherbst: ahh okay
22:06imirkin_: but on kepler2 and maxwell, it can be higher, no problem
22:06karolherbst: so kepler2 isa might make that pass a bit more messy
22:06imirkin_: but on nv50, there are 128 regs, but certain encodings can only encode regs up to 64
22:07karolherbst: yeah I figured
22:07karolherbst: I also enable that pass for fermi
22:37karolherbst: "[20396/20396] skip: 2216, pass: 17885, warn: 4, fail: 287, crash: 4" I think this looks better
22:37imirkin_: still a lot more than i remember =/
22:37karolherbst: well I will do a run on master too though
22:38imirkin_: probably just new tests
22:38karolherbst: yeah, maybe
22:38imirkin_: if you could put up the list somewhere, that'd be great
22:38karolherbst: or something regressed
22:38imirkin_: i'll try to have a look ... at some point
22:38karolherbst: ask mupuf, he has his fancy new tool for that :p
22:38imirkin_: well, a couple things definitely regressed
22:38imirkin_: coz i regressed them
22:38imirkin_: but semi-not
22:39imirkin_: i need to spend some time investigating to determine if the piglit is wrong or i'm wrong
22:39karolherbst: ohh okay
22:39imirkin_: but that's just a handful
22:39imirkin_: stuff related to textureGrad()
22:39mupuf: karolherbst: you mean the auto bisect of piglit tests?
22:39imirkin_: well, chances are the tests were added and have failed since then
22:39karolherbst: but first I have to make sure that I didn't break anything
23:34karolherbst: okay, no regression caused by my commits