02:13mixfix41: you guys play steam on nouveau?
02:15urjaman: thats a very generic statement btw
02:15urjaman: pretty sure the client works atleast :P
02:16urjaman: but i'm not sure if using it counts as playing
02:16mwk: with all the card trading stuff... :p
03:12wvvu: what's the default power state in nouveau?
03:13wvvu: my emulator is running at slow fps, and it appears that the culprit is the power state of the card.
03:16RSpliet: wwvu: whatever your VBIOS sets
03:19wvvu: how to know then?
03:20RSpliet: depends on your kernel; on 4.5rc1 cat /sys/kernel/debug/dri/<card number>/pstate
03:20wvvu: it might had to do with the power state, as when I am running the emulator it doesn't change the temperature at all.
03:21RSpliet: you haven't stated which card you're using btw
03:28wvvu: odd I don't have 'pstate' file
03:31RSpliet: then you're not using a 4.5RC1 kernel
03:32RSpliet: previously you could make it appear by passing nouveau.pstate=1 as a kernel parameter, after which you'll find it in /sys/class/drm/card<card number>/device
04:25wvvu: RSpliet: will use it.
04:25wvvu: is it possible to set to max performance though?
04:25wvvu: that's the point. My emulator is running low FPS due to this
04:45martm: mwk: i have a question about warp exec masks, do they work per instruction only, i.e apply to instruction that follows the mask only, and would then be reset automatically, or mask apply to all instructions which follow until the mask is manually cleared or rewritten?
04:51martm: mwk: never mind, it's called thread-masks in your documentation, it seems like you speculate there, that maybe somewhere should be discard mask too, so probably the mask applies to all instructions until it's manually rewritten or discarded..
04:52martm: https://media.readthedocs.org/pdf/envytools/latest/envytools.pdf page 210 there
05:58wvvu: how far are hardware cards that will play 4k games maxed out? At an affordable price.
06:00wvvu: I understand that 4k, although implementable, is very hungry on resources, that not even high end cards can take full advantage.
06:03karlmag: wvvu: "affordable" is not a very strict measurement. Affordable to some may be way out of reach for others.
06:04wvvu: 100-200 range
06:05wvvu: what I am saying that right now is not worth investing in 4k? Another reason is perhaps the gaming industry isn't mature for 4k yet.
06:05karlmag: I'm afraid I'm not able to really answer your questions though.
06:06karlmag: Personally I have started to consider getting 4k monitors, but I still think they are a bit expensive.
06:07karlmag: I do seem to remember quite a few cards are able to do (if the adds are to be believed) 4k, at least on digital ports.
06:08karlmag: I don't have any practical experience thouh
06:09wvvu: yes, output 4k is fine and doable, but 4k gaming, with 4k textures and 4k everything I think is a differnt thing.
06:10karlmag: oh, right.. yeah, I guess that might be a slightly different beast.
06:10karlmag: And given I don't really do any gaming at all...
06:28RSpliet: wvvu: I think you should be able to change the clock speed of your NVE4
06:28RSpliet: just write the preferred mode to that pstate file
06:28RSpliet: make sure you get a new kernel for that though, not your average debian/ubuntu kernel
06:43imirkin: wvvu: your board most likely boots into the lowest power state (this is typical for kepler). you should get kernel 4.4 which ought to let you change power states manually. there is no automatic reclocking atm because the switches between power states aren't sufficiently reliable
06:50wvvu: 4.3 at the moment
06:51imirkin: you'll most likely be able to reclock to the middle state but not the high power state
06:51imirkin: with 4.4 the high pstate will likely work as well
11:50martm: why have you taken a voice away from sweetheart joss193?
11:51martm: imirkin: anyways couple of questions, actually only one..
11:51martm: imirkin: well i am too lazy to test, actually too busy, i think you know that one
11:52martm: imirkin: well if we reorder instructions so that first will be some instruction whos input depend on the other instructions
11:52martm: i.e those inputs have not been calculated yet, if we lift that instruction as a first one, will shader decode and skip to the next one , cause it's inputs are not there?
11:58martm: karolherbst: was the only one talking to me publicly but his not here, i have a better chanche asking from somewhere else then, i am not even sure if that channel is full of really stupid persons or not
12:40martm: nothing to remain, since this channel is full touches, have to test everyhing my own, compiling piglit , then need to trace and feed back the modified buffer
12:48martm: like always go fuck yourself, fuck those poor poirtuguse, and suck their cocks, some day i found those estonians who fabricated stuff around the world, and they will be killed
12:48martm: FUCK YOU RETARTDS!
13:03wvvu: w00t, someone got issues
13:03orbea: *retards :P
13:41ubr47k: what the hell was that for
13:42mwk: business as usual.
13:49ravior: imirkin_: I found the reason why the driver froze. Seems that the nouveau acceleration was causing the problem.
13:50ravior: After I disabled it, I haven't encountered any freeze (nouveau.noaccel=1)
13:51ravior: If there will be any bug investigation for this problem and I could help, please ping me. Thanks.
13:51imirkin_: ah yes... the "nouveau is broken" problem :)
13:52imirkin_: ravior: anyways, you're effectively not using nouveau at that point. so it makes sense you're no longer seeing issues.
13:54ravior: This has to have a root cause somewhere... Unfortunatelly, considering the reproductibility nature of the problem, a git bisection for it is not even an option. :(
13:55imirkin_: "nouveau is totally broken" definitely doesn't have a single root cause
13:55ravior: I also don't have the technical skill to help debug it further. Anyway, if there is a way I could lend a hand, just ping me.
13:56ravior: I doubt that we need to go Occam's razor on this one :D
13:56imirkin_: ravior: git bisect would suggest that some earlier version works... is that the case? iirc it was always broken
14:04ravior: imirkin_: I just got this laptop on which I'm seeing this problem. Unfortunatelly I can't answear that question. :-/
14:06grarap: I'm having a problem with nouveau claiming my external monitor's EDID is not valid
14:06grarap: It won't turn on
14:06grarap: However, as soon as I run get-edid (nothing else) with the monitor unplugged, and plug it in, my monitor works
14:07grarap: It's quite weird
14:07grarap: Actually the monitor does not have to be unplugged when I run get-edid, I think, it may be necessary for it to be plugged in
14:07grarap: I can check that if it's necessary
14:07grarap: This exact monitor has worked with nouveau in the past so it's a regression, I'm pretty sure about that
14:08grarap: I don't have any problem with the monitor with the proprietary nvidia driver
14:13ravior: imirkin_: And it's not "totally broken". It works for some time until something makes the xorg crash / the driver crash. What is that? Good question.
14:22imirkin_: grarap: maybe the monitor doesn't make edid available early enough and nouveau gets upset?
14:22imirkin_: grarap: if it's a regression, bisect :)
14:26grarap: imirkin_: No, unless I run get-edid, it will never work
14:26grarap: It's that checksum error not few people seem to have
14:27grarap: The checksum remainder also changes
14:27imirkin_: hmmm... maybe nouveau caches the bad edid? dunno
14:41mwk:wonders what are the chances of making a correct 128-bit shift-and-round routine operating on 64-bit pieces on the first try
14:41mwk: well, we'll find out soon enough
14:44imirkin_: mwk: #if BITS_PER_LONG == 64 and move on :p
14:44mwk: imirkin_: too late
14:44mwk: I wrote it all... now wiring up the dmul test
14:45mwk: besides, it wouldn't compile on my pretty 32-bit machines
14:45grarap: imirkin_: I just don't get how just running get-edid can change something
14:45grarap: I don't store the output at all
14:46mwk: and I much prefer writing 128-bit arithmetics to wrestling with cmake to detect 128-bit int types
14:46imirkin_: grarap: well, it forces nouveau to grab a fresh edid i think
14:46grarap: And now when I'm connected to my monitor and using it, get-edid doesn't even work
14:46imirkin_: grarap: tbh i'm not 100% sure how it all works... i figured it'd just read directly off the i2c interface
14:46imirkin_: grarap: and that'd be invisible to nouveau
14:46grarap: The EDID seems to be a different one every time I connect my monitor, or at least many times, since the checksum remainder changes
14:48imirkin_: yeah, probably because nouveau grabs it too early and the monitor's not ready? dunno
14:48imirkin_: or something else dumb
14:48imirkin_: either way, if this all used to work, finding the commit that broke it would go a long ways
14:48imirkin_: to determining a fix
14:52grarap: imirkin_: Yes, I'll see if I check that
15:20mwk: whoa, seems it actually works
15:23mwk: I tried to be clever and define fp64_mul(a, b) to fp64_fma(a, b, -0.0)
15:24mwk: but this fails when a*b is 0 and rounding mode is to -Inf
15:26mwk: ah, but I can just use fp64_fma(a, b, 0) for -Inf rounding
15:26mwk: now it works :)
15:27wvvu: funny errors
15:28wvvu: WriteRest op out of range <--- rings any bells?
15:58mwk: all Tesla fp64 ops covered by tests.
15:59imirkin_: mwk: nice!
16:00mwk: so that leaves... integers
16:00mwk: and all the control stuff, load/store, vote, emit/restart, textures... but they're not exactly easy to test
16:00mwk: oh, and interp
16:07imirkin_: hrmph. so by nuking dce/merging/copyprop from st/mesa, we become 2.5% slower :(
16:07imirkin_: and due to idiotic RA fail, we also end up having more regs. but i'm going to look into fixing that.
16:08mwk: protip: don't push before tests run to completion
16:08imirkin_: which you of course just did?
16:09mwk: protip #2: if everyone uses 3 extra bits of accumulator for adds, don't assume you can skip them just because it's an fma and you have all these extra bits for the "m" part already
16:10mwk: on the plus side, no fault in the 128-bit stuff!
16:11mwk: hmm... I might be able to get away with using just 2 extra bits though
16:12mwk: still, better to have an extra bit in there than screw up the maths again
16:14mwk: so, integers... and then Fermi time
16:15imirkin_: hopefully ints will be easy :)
16:15mwk: yeah, I don't expect anything too strange
16:16imirkin_: i assume you'll cover the vector stuff too? :)
16:17mwk: I certainly hope integers will be trivial
16:18mwk: but then... you can really fit a hw bug *anywhere*
16:18mwk: did you hear about the "sat NaN to 0" bit? it's hilarious
16:20mwk: I'd also love to test the interp instruction, but that'll require a full 3d testcase and figuring out how to exactly control the inputs, whatever they are
16:21mwk: I tried to cheat the MP by submitting a compute task, setting a breakpoint just before interp, and flipping the "shader type for warp #X" bits in the debug area, but turns out it's not the master copy and it still failed :(
16:21mwk: it's probably the EXECUTE unit's, and it's the DECODE unit that's causing the errors
16:23mwk: and I'm rather disappointed there's MP state that doesn't show up in the debug area
16:23mwk: the s locked addresses could be useful, for one
18:07imirkin: airlied: i have a patch which should fix that cts thing... would you be up for rerunning it?
18:09imirkin: airlied: https://github.com/imirkin/mesa/commit/e3dd31f0f93eac5bd9dd6ae6f8fe279e9fd618b7.patch
18:44imirkin: karolherbst: do you have "dead island"?
18:45karolherbst: imirkin: yeah I think so
18:45imirkin: the claim is that it crashes on startup
18:45karolherbst: just checked, I don't have it :/
18:45imirkin: (wait, aren't you supposed to be asleep?)
18:46karolherbst: mhhh we just got like home?
18:46karolherbst: kisses from martin
18:49imirkin: sounds like you guys are having a good time
18:49karolherbst: yeah, we had
18:49karolherbst: I think :/
18:49karolherbst: sad that you aren't here with us though
18:50imirkin: too far. and i'm too lazy.
18:50imirkin: you'll get over it
18:50karolherbst: mhh I guess
18:58karolherbst: imirkin: no idea about this dead island issue though
18:58imirkin: yeah no worries
18:58imirkin: you have a lot of games, figured you might have had that one
21:34airlied: imirkin: okay the fp64 tests don't crash anymore with that patch
23:16urjaman: i have a thing that i'm kinda curious about, so i'll just drop this wondering here.... firstly, i have chrome (forced to do gpu acceleration) running a full screen video on one screen...
23:17urjaman: then if i open a glxgears on the other screen it 1. locks up the video on the first screen and 2. runs at ~14 fps
23:17urjaman: then when you close the glxgearss the video runs at hilarious speed to catch up...
23:18urjaman: and yeah it's not only glxgears, i noticed this when using kicad opengl renderer or the 3d viewer (very simple) as the "2nd app"
23:20urjaman: (as before, a G96 / 9400 GT ... i know it's lame, but somehow the feeling is that it shouldnt be that lame at running 2 things)