00:21 karolherbst: or maybe not pre SSA
01:48 karolherbst: imirkin_: mhh there is odd behaviour and I am not sure if that's my fault: https://gist.github.com/karolherbst/38223a454125f097fdf1a8ea54ef0ddd
01:49 karolherbst: RA adds a mov and changes a phi source so that both sources are in the same BB
01:49 karolherbst: and I don't get why it does that
03:20 hexedit: i am seeing a couple more bugs with nouveau at this time
08:33 martm: over the past few years banning has gained a lot of popularity:), people ban people from home or even at/from work, hence we present our Xextension to ban users out from Xscreen, we have made 1kloc modification to the current Xorg tree to ban users out from X, and also make training at #banusers channel on freenode.
08:34 Calinou: b&
10:30 karolherbst: gnurou: welcome back by the way :p
10:35 gnurou: karolherbst: thanks! sorry for the stupid question! ;)
10:35 karolherbst: no problem
10:36 karolherbst: I know that in the mode0 c4-c6 are also used somewhat in the calculation, but I left it out because no vbios ever set them
10:37 karolherbst: and I thought my description of the table would be enough.. well next time I will use the offsets and everything then
10:43 karolherbst: gnurou: so is it worked on or just a question to clarify if it can be worked on? :D
10:55 gnurou: karolherbst: it is being looked at by the people who know and the question actually came from them
10:55 karolherbst: ahh okay
10:55 gnurou: so hopefully we will get somewhere
10:57 karolherbst: awesome :)
11:39 karolherbst: imirkin: I think in the end we get away with something like that: _very_ smart phi -> slct pass and all the other passes optimize it so, that other instructions gets DCEed away (and maybe the branches flattened away)
11:42 karolherbst: mhh wait, the bra has to go away in that case
11:43 karolherbst: so negs/abs and so on have to be folded in immediatly
12:39 FunkyBob: morning
12:39 FunkyBob: so... decided to play with pstate... got some very pleasing results
12:39 FunkyBob: however... http://dpaste.com/0JT8F67
12:40 FunkyBob: what's the go wit AC?
12:46 mupuf: FunkyBob: AC == connected to the power grid
12:46 mupuf: AKA, not on battery
12:46 mupuf: the clocks reported afterwards are just ... the current ones
12:47 RSpliet: well, glad to see OA still running this morning :-)
12:53 Calinou: RSpliet: OA as in OpenArena?
12:53 RSpliet: Calinou: yes
12:53 Calinou: try Stunt Rally :p
12:53 Calinou: http://stuntrally.tuxfamily.org
12:54 Calinou: not even a Titan X can run it at 60 FPS
12:54 Calinou: but that's because the graphics settings are shit
12:54 Calinou: eg. you can completely disable all impostors
12:54 Calinou: which makes no sense
12:54 RSpliet: Calinou: why? on OA I could reproduce my bug and it appears to have gone now
12:54 RSpliet: after applying a relatively small fix
12:54 Calinou: I mean, if you want a more demanding game
12:54 RSpliet: this bug isn't triggered by high demand
12:59 karolherbst: RSpliet: with your patches?
12:59 RSpliet: just the one :-)
13:00 karolherbst: :)
13:00 RSpliet: it's a bit problematic to test, because there is always the off chance that I got lucky
13:00 karolherbst: right
13:00 RSpliet: but by the very least no regressions and solid motivation :-)
13:01 karolherbst: FunkyBob: well it gets interessting whenever you run some benchmarks
13:02 karolherbst: yay, nearly there
13:03 karolherbst: https://gist.github.com/karolherbst/d0679890f3ded720e2ba325e0952c988
13:04 karolherbst: just have to get those mods and sources right :)
13:10 hexedit: you know you sons of bitches sure can't seem to do anything well...if you are not going to do an adequate job why bother trying to do anything at all....the opengl people are pissing all over your efforts and constantly moving on to make sure nobody else gets on their turf
13:10 hexedit: those sons of bitches are trying to sell video boards for $8999 dollars and don
13:10 hexedit: they don't want anyone cramping their style
13:11 hexedit: if you are not going to do an adequate job why bother doing it at all
13:15 hexedit: why don't you sons of bitches just pay the $8,999 every fuckin time those opengl bastards decide they want to sell another video board
13:18 FunkyBob: karolherbst: have always been a fan of real use over benchmarks :P
13:18 karolherbst: FunkyBob: well only with a lot of luck nouveau will run stable at 0f on your GPU
13:18 karolherbst: and with stable I meant like more than one day
13:19 FunkyBob: bette clock it down, then :)
13:22 karolherbst: well
13:22 karolherbst: it doesn't matter
13:22 karolherbst: once you reclock the gpu can be unstable
13:22 karolherbst: mostly due to undervolting
13:22 FunkyBob: noted
13:23 karolherbst: well fixes are on the way, we just hope we can merge those until 4.8
13:24 FunkyBob: so I've noticed
13:24 FunkyBob: am only in 4.5.1 currently
13:24 FunkyBob: on, not in
13:26 hexedit: whats the matter...you don't approve of price gouging or are you willing to pay $8,999 every fuckin time those opengl bastards want to sell another video board
13:30 hexedit: karolherbst..well here is what i rethink you goddamn hardware son of a bitch...you pieces of god damn shit owe me a lot of money for my model 1 ideas you god damn thieves stole without my permission
13:36 hexedit: in most countries....thieves, murderers, and rapists are removed from society and you sons of bitches need to face judgement
13:45 karolherbst: I always fear that one day every IRC channel gets spammed by IRC bots talking with each other and you have no idea if one Nick belongs to a human or not...
13:45 FunkyBob: heh
13:45 FunkyBob: we gad someone in #django recently that I wasn't sure if it was a language barrier, of they were a very good markov bot
13:47 karolherbst: pq: why martm too? I kind of got the feeling he can behave himself if he really wants to
13:49 pq: karolherbst, oh, old habit. Bad memories. Ask any senior.
13:49 pq: like airlied
13:49 karolherbst: pq: yeah I know, but he was unusually quite the last weeks
13:49 pq: just noticed he was suspposed still be on bad, but got around it
13:50 pq: *ban
13:50 karolherbst: *quiet
13:51 karolherbst: pq: not that I want to defent him or something, but usually I would say that the same rules should apply to all and if he kind of got better there is no reason to ban him
13:51 pq: usually I'd agree...
13:53 karolherbst: well anyway, this might could get him angry or something. Well let's see what will happen
13:56 gouchi: what is geometry programs in 3D Features ? https://nouveau.freedesktop.org/wiki/FeatureMatrix
13:56 karolherbst: gouchi: geometry shaders?
13:56 gouchi: I have NV40 card family so I don't have it but I was wondering what is it
13:56 pq: karolherbst, if it does, he'll try to flood my pm. Shouldn't hurt anyone else.
13:57 karolherbst: gouchi: I think a geometry shader can produce vertices as outputs, not sure though
13:57 karolherbst: gouchi: GL 3.2 feature
13:57 gouchi: karolherbst: https://www.opengl.org/wiki/Geometry_Shader ?
13:58 karolherbst: yeah
13:58 gouchi: good to know
13:58 gouchi: thank you
14:19 imirkin: a geometry shader takes an input primitive and is able to emit any number (including 0) output primitives for rasterization
16:14 karolherbst: imirkin: any chance to implement ARB_framebuffer_object on nv40?
16:24 imirkin_: karolherbst: mmmm.... not without shadow buffers for everything. what do you need from it that EXT_framebuffer_object doesn't have?
16:29 karolherbst: imirkin_: no idea, gouchi has an application which uses it
16:29 karolherbst: imirkin_: and it works on nvidia
16:30 imirkin_: nvidia implements a bunch of things that cause shitty perf but are nice to applications
16:30 imirkin_: anyways, it's def not impossible
16:31 karolherbst: okay
16:31 imirkin_: iirc the biggest hurdle was that ARB_framebuffer_object requires supporting fb's of different sizes
16:31 imirkin_: while the hw does not support this
16:31 karolherbst: well I don't know what the application uses but maybe EXT_framebuffer_object might be enough
16:31 imirkin_: which means you have to create shadow RT's to render to, and then copy them onto the "real" RT
16:34 imirkin_: as it happens, we need to implement the shadow RT stuff *anyways* for dealing with incompatible depth/color format combos
16:35 imirkin_: since we kinda have to support those
16:35 imirkin_: right now we just mess up rendering in that case :)
16:38 karolherbst: ahh okay
16:42 karolherbst: imirkin_: guess what, fbo is indeed optional
16:42 karolherbst: but "check_lib FBO -lGL glFramebufferTexture2D" :D
16:43 imirkin_: and of course the mesa libGL exposes that symbol due to a historical accident
16:44 imirkin_: oops.
16:44 karolherbst: right
16:44 imirkin_: that's totally not a valid way of checking for FBO's btw - among other things, you might build against one libGL but run against another.
16:44 karolherbst: exactly
16:44 karolherbst: but
16:44 karolherbst: they check at runtime if the extension is there
16:44 karolherbst: and just fail
16:44 karolherbst: if it isn't
16:45 imirkin_: ah, clever.
16:45 imirkin_: we do have EXT_framebuffer_object, which provides FBO's and most of the functionality normal people want
16:45 karolherbst: well
16:46 imirkin_: https://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#p=compat&v=Mesa%2010.6.0
16:46 karolherbst: they added fbo support in 2012 or earlier, no idea if they really want to support the ext extension in addition
16:46 imirkin_: the EXT version is older
16:46 imirkin_: the ARB one is the fancy new one, so to speak
16:46 karolherbst: okay
16:46 imirkin_: and its functionality was integrated into GL 3.0
16:46 karolherbst: ohh okay
16:46 karolherbst: the ARB?
16:47 imirkin_: yea
17:00 karolherbst: imirkin_: by the way, slct is a check against equal to 0, right? Which CC do I have to pass to bld.mkCmp?
17:01 imirkin_: i don't remember
17:02 imirkin_: i think it's just == or != 0
17:02 imirkin_: btw note that there's also a SELP
17:02 imirkin_: which can take any predicate
17:02 imirkin_: (as its last argument)
17:02 karolherbst: ahh I think I found it
17:02 karolherbst: "mkCmp(OP_SLCT, CC_GT, TYPE_F32, dst0[2], TYPE_F32, val3, zero, val0);"
17:02 karolherbst: ohh
17:02 karolherbst: there are more possible
17:02 karolherbst: (srcTy == TYPE_F32) ? CC_LT : CC_NE, :/
17:03 karolherbst: can I put whatever I want?
17:03 karolherbst: ohh SELP sounds nice
17:04 imirkin_: (only on nvc0+... not like SLCT works on nv50 either though)
17:04 karolherbst: ohh
17:05 karolherbst: so slct/selp is nvc0+
17:05 imirkin_: yea
17:05 imirkin_: look at how SLCT gets lowered on nv50 :)
17:05 karolherbst: thing is I want to reduce simple if () {} else {} clauses into slct
17:05 imirkin_: right
17:05 karolherbst: no idea how well it would work with selp
17:05 karolherbst: especially if there is a phi
17:06 karolherbst: ohh wait
17:06 karolherbst: selp is just slct but the last one is a predicate
17:06 imirkin_: yes.
17:06 karolherbst: I think this would make the pass much easier
17:06 karolherbst: because I move the predicate out of a predicated bra and merge it with a set
17:06 imirkin_: and then you can have a further pass combining SET + SELP into SLCT
17:06 karolherbst: to reduce the entire if thing with a slct
17:07 karolherbst: mhh yeah
17:07 karolherbst: it sounds much better this way
17:07 karolherbst: so I just move the predicate out of the bra into the selp
17:07 karolherbst: and put both phi sources into the selp
17:07 karolherbst: in a smart way
17:07 imirkin_: :)
17:07 karolherbst: well sometimes one source is above the bra
17:08 karolherbst: and I just search for branched neg/abs instructions
17:08 karolherbst: so I can put the mod into the slct/selp
17:08 karolherbst: or movs
17:09 karolherbst: is selp a cmp instruction like slct?
17:10 imirkin_: no
17:11 imirkin_: it doesn't take a cond code
17:11 imirkin_: it can optionally negate the condition
17:11 karolherbst: okay :)
17:11 karolherbst: and the same goes for bra?
17:11 imirkin_: for which you just set the not modifier on the src
17:11 imirkin_: bra is a flow instruction
17:11 karolherbst: so if not $p bra => selp->src(3).mod = NOT
17:12 karolherbst: mhh
17:12 karolherbst: NEG
17:12 imirkin_: the predication you can do on it is the same as you can do on any op
17:12 karolherbst: yeah
17:12 karolherbst: I meant the CC on the bra
17:12 karolherbst: ahh okay
17:12 imirkin_: there is no cc on bra
17:12 imirkin_: there's a cc on instruction
17:12 imirkin_: which you could have on selp as well, if you wanted it to be predicated
17:12 karolherbst: ohh okay
17:12 karolherbst: the question is, is it enough to just get the predicate through bra->getPredicate()?
17:13 imirkin_: yes.
17:13 karolherbst: mhhh
17:13 karolherbst: odd, the not isn't there
17:13 imirkin_: that gets you the instruction predication
17:13 imirkin_: yeah, look at inst->cc
17:13 imirkin_: which is the cond code for the predication
17:13 imirkin_: (on nv50 there's fancier things you can do than on nvc0)
17:13 karolherbst: well, which instruction?
17:13 karolherbst: because the bra is predicated
17:14 Tom^: karolherbst: https://gist.github.com/anonymous/dffdaa6220ff935afb732b6cb5a3c9d2 it has flaws, caused by my lack of C skills. but here you go. now it iterates chooses first found dri card with pstate or boost, or takes --card=VAL to override it incase you got multiple ones.
17:14 Tom^: xD
17:14 karolherbst: :D
17:15 Tom^: bet it has bugs, but valgrind likes it
17:15 imirkin_: this isn't a shell script because...?
17:16 Tom^: because i dont know bash
17:16 Tom^: :(
17:16 imirkin_: seems like a reasonable explanation
17:16 Tom^: sad but true, my bash is limited to aliases and ENV vars.
17:17 imirkin_: this is just a tool for people who can't handle using 'echo' right?
17:18 Tom^: indeed
17:18 imirkin_: i see. didn't realize that was a big group of people.
17:18 karolherbst: well
17:18 karolherbst: you can suid it!
17:18 Tom^: and that and keybind it !
17:18 Tom^: :P
17:18 imirkin_: yeah, can't set a suid bit on a shell script =/
17:18 orbea: heh, I just do this in .bashrc http://dpaste.com/17T9N2C
17:19 imirkin_: [at least not easily]
17:19 orbea: easy enough....
17:19 karolherbst: imirkin_: can't you just call sudo in a suid shell script?
17:20 imirkin_: karolherbst: "suid shell script" is not a thing supported by linux.
17:20 imirkin_: so you can't do anything in it.
17:20 imirkin_: because it doesn't exist.
17:20 karolherbst: ohh right
17:20 karolherbst: interpreter
17:20 karolherbst: ...
17:20 imirkin_: you can certainly have a shell script that calls sudo
17:20 imirkin_: (which seems like exceedingly poor taste since it assumes you have sudo)
17:21 imirkin_: and e.g. in my case:
17:21 imirkin_: $ sudo
17:21 imirkin_: -bash: sudo: command not found
17:21 karolherbst: imirkin_: okay, I am stupid, somewhat I can't add a modifier to selp :/
17:21 karolherbst: 85: selp u32 %r917 %r910 %r2117 %p915
17:22 karolherbst: even tried selp->src(3).mod = Modifier(NV50_IR_MOD_NOT);
17:22 karolherbst: or NEG
17:22 imirkin_: i think you want src(2)
17:22 imirkin_: since there are only 3 sources
17:22 karolherbst: ohhhh :O
17:23 karolherbst: and the right mod is indeed NV50_IR_MOD_NOT
17:23 karolherbst: yeah, that works
17:24 karolherbst: and it is CC_NOT_P :/
17:24 karolherbst: annoying name
17:24 karolherbst: imirkin_: wasn't there a insn->op to mod kind of thing?
17:25 karolherbst: hehe Modifier(op)
17:25 karolherbst: ...
17:29 gouchi: I am trying to run a test gl application but I got this error http://www.hastebin.com/ayexiwevil.vhdl
17:30 gouchi: I have an old card nv40 graphic card family
17:31 karolherbst: imirkin_: this looks okay, doesn't it? https://gist.github.com/karolherbst/eeed6f2b52eb329323cd05ccbc5aa25b
17:31 karolherbst: I just need to remove the phi now
17:31 imirkin_: gouchi: srcAddr=0xffffffffffffffff
17:32 imirkin_: that's probably unfortunate =/
17:32 imirkin_: RetroArch [INFO] :: [GL]: Version: 2.1 Mesa 10.3.2.
17:32 karolherbst: imirkin_: yeah! 84: phi u32 %r917 %r910 %r2117 (0) => 84: selp u32 %r917 %r910 neg %r910 not %p915 (0)
17:32 karolherbst: :)
17:33 imirkin_: gouchi: that was ages ago - a ton of stuff has been fixed since then
17:33 imirkin_: gouchi: please try 11.2.2
17:33 gouchi: imirkin: sure
17:34 karolherbst: ohh bother
17:34 karolherbst: now there is a " 56: join (8)" left
17:36 imirkin_: gouchi: actually, i dunno. could be an application bug:
17:36 imirkin_: #11 0x00000000004295bf in video_driver_frame (data=0xffffffffffffffff, width=320, height=240, pitch=0) at gfx/video_driver.c:2139
17:36 karolherbst: imirkin_: I already said to him that this application path is actually untested for years
17:36 imirkin_: sounds like they're taking an error return and feeding it in as data
17:37 gouchi: let me try with another core
17:37 imirkin_: (and it calls glTexSubImage2D() with it, which is supposed to take a pointer to client data. in this case the client data pointer is obviously wrong.)
17:39 gouchi: I don't if it is a side effect because I disable render-to-texture (FBO) support
17:39 gouchi: I will check with the project first
17:40 imirkin_: dunno. i wonder what they need from ARB_framebuffer_object that's not available in EXT_framebuffer_object =/
17:40 karolherbst: imirkin_: maybe I should rather leave the phi and set a new def value? :/
17:42 karolherbst: mhh doens't change anything
17:42 karolherbst: seems like something doesn't clean up the joins right
17:51 imirkin_: gouchi: where's the libretro source? their site is... difficult to navigate.
17:51 imirkin_: ah nm. found it.
17:52 imirkin_: google to the rescue
17:52 gouchi: imirkin: the core of testgl is here https://github.com/libretro/RetroArch/tree/master/cores/libretro-test-gl
17:53 gouchi: imirkin: retroarch is frontend which launch libretro core. I am taking a simple one as test gl
17:53 imirkin_: k
17:58 imirkin_: gouchi: hm, well it's probably on purpose. i'm guessing that RETRO_HW_FRAME_BUFFER_VALID == -1
18:01 imirkin_: #define RETRO_HW_FRAME_BUFFER_VALID ((void*)-1)
18:02 imirkin_: and that appears to be getting passed through to the GL impl, which is wrong
18:02 glennk: how old is nv40 now?
18:02 gouchi: too old :)
18:02 imirkin_: well, it probably got phased out around 2010 or so?
18:02 imirkin_: or later even
18:03 imirkin_: iirc i got my desktop in 2011, and G7x's were still going strong
18:04 imirkin_: anyways, this is probably a bug in libretro
18:04 imirkin_: -1 should never be making it in as a user pointer passed into GL
18:05 gouchi: ok let me check if I enable fbo
18:06 imirkin_: well, if it wants ARB_fbo, that won't work on nouveau
18:08 gouchi: yep ARB_framebuffer_object :(
18:09 RSpliet: gnurou: oh, didn't see you subscribed to fdobz #93629. Could you verify you got the notification e-mail for this bug and try out the patch I attached?
18:13 karolherbst: only GL_ARB_robust_buffer_access_behavior missing for 4.3?
18:14 imirkin_: and fixing our glsl compiler so that it doesn't die in a bunch of games
18:15 karolherbst: where does it die?
18:15 imirkin_: UE4
18:15 imirkin_: both in demos and in actual games
18:15 imirkin_: (but in different ways)
18:15 karolherbst: I see
18:23 gouchi: If I launch a game I got also data=0xffffffffffffffff http://www.hastebin.com/umerajuqug.vhdl
18:24 imirkin_: yeah, that test thing isn't doing anything wrong. libretro is.
18:25 gouchi: this is with another core I am not using testgl core
18:26 gouchi: ah ok because of https://github.com/libretro/RetroArch/blob/master/libretro-common/include/libretro.h#L1532 ?
18:28 karolherbst: imirkin_: flattening cleans up the joinat/join pairs, right?
18:30 imirkin_: gouchi: well, presumably that bit is done on purpose
18:30 imirkin_: gouchi: however something in libretro is supposed to interpret that -1 and do somethign clever with it
18:30 imirkin_: gouchi: but instead it appears to get passed all the way into libGL
18:31 imirkin_: gouchi: i know nothing about libretro though... i'd recommend getting in touch with people that do
18:31 Tom^: i believe they have an irc channel
18:31 gouchi: thank you very much for help
18:31 Tom^: "IRC channel: #retroarch @ irc.freenode.org."
18:31 gouchi: Yes I am on it
18:31 Tom^: ah oki
18:32 gouchi: I will make a feeback for this issue to them
18:32 gouchi: Again thank you very much for your help imirkin and karolherbst !
18:32 gouchi: I advanced a lot ;-)
18:32 gouchi: Thank you !
18:32 imirkin_: gouchi: ultimately i wouldn't be surprised if it ended up hitting horrid issues in nouveau, but at this point the issue appears to be in libretro
18:33 gouchi: no problem
18:34 gouchi: imirkin: we are relying on drm/kms egl on lakka which is the official linux distribution for RetroArch and libretro ecosystem
18:34 karolherbst: uhh
18:34 karolherbst: that one join is inserted by RA
18:34 imirkin_: gouchi: cool
18:35 gouchi: imirkin: and this issue not impact the other nvidia card
18:35 imirkin_: gouchi: note that nv50+ tends to work fairly well... nv30/nv40 -- not quite as much.
18:35 gouchi: imirkin: this issue is only for nv40 card
18:35 imirkin_: gouchi: i'm happy to provide more info, if you can convince someone familiar with libretro to have a look at what's going on.
18:36 gouchi: imirkin_: sure I will try
18:37 imirkin_: but i'm not going to spend a ton of time familiarizing with that lib myself
18:37 gouchi: sure I understand
18:38 gouchi: anyway if you want to try Lakka be my guest ;-)
18:38 gouchi: http://www.lakka.tv
18:39 imirkin_: gouchi: i barely ever reboot. doubt i'll be installing a new distro :p
18:39 karolherbst: imirkin_: I think it is only a collection of applications though
18:40 gouchi: imirkin: you can use it with live usb
18:40 Tom^: arent most distros that karolherbst ?
18:40 Tom^: :P
18:40 karolherbst: :D
18:40 gouchi: imirkin: I never installed it just using live
18:40 imirkin_: gouchi: yeah, that still requires reboots :)
18:40 gouchi: imirkin_: yes :))
18:42 karolherbst: Tom^: well mine isn't :p
18:42 karolherbst: Tom^: mine is more like a collection of install scripts I install software with :D
18:43 Tom^: fair enough
18:45 karolherbst: is offloaded rendering already part of the vulkan core? Like if I driver my display with intel I can use the nvidia vulkan stuff for an application?
20:18 thum: hi, I'm using a 8400 GS. nouveau seems to have a problem to use 1920x1920, the screen is flickering. however, xrandr says it's supported. does someone have an idea how to deal with this? (debian jessie, Linux 4.5.1., nouveau 2.4.58-2)
20:18 imirkin_: did you actually mean 1920x1920? or 1920x1200?
20:18 thum: it's not a typo :)
20:19 imirkin_: how is the screen connected?
20:19 thum: via DVI
20:19 imirkin_: DVI-DL or DVI-SL?
20:19 thum: let me check that
20:20 Weaselweb: SL only supports 1920x1200@60Hz, no?
20:20 thum: DVI-D dual link
20:21 thum: xrandr says: 1920x1920 59.94 + 29.94
20:21 imirkin_: thum: what if you switch to it?
20:22 thum: screen is unreadable, flickering
20:22 imirkin_: i wonder if the memory's too slow? which gpu is this? G84? or GT218?
20:22 thum: I can read the first line of the terminal title though, like in the upper 1/5 of the screen
20:22 imirkin_: (you can tell from lspci -nn -d 10de: )
20:23 imirkin_: (or from the variuos boot messages)
20:25 thum: GT218, does that make sense?
20:26 imirkin_: yes
20:26 imirkin_: you can try increasing your memory clocks
20:26 imirkin_: check /sys/kernel/debug/dri/0/pstate
20:27 imirkin_: cat that file, that should tell you your current settings (pastebin that somewhere)
20:28 thum: https://paste.ee/p/zCLU6
20:28 imirkin_: well, if you don't mind the possibility of a hang (this is all a bit experimental), you can try doing "echo 0f > /sys/kernel/.../pstate"
20:29 thum: no, can do. just a sec.
20:29 imirkin_: which should up your memory speed, and potentially resolve your flickering issues
20:29 imirkin_: or... give you a ton of new ones
20:31 thum: nothing happened, ../pstate: [..]0f: core 520 MHz [..] 600 MHz AC DC *
20:31 thum: ^^ that's new.
20:31 imirkin_: thum: the AC: line should hopefully reflect the 0f line now?
20:31 imirkin_: (most importantly the memory bit of it)
20:32 thum: yes, that's what I wanted to express :)
20:32 thum: it's all in the 0f line
20:32 imirkin_: ok cool. the AC DC * can be misleading
20:32 imirkin_: ignore those
20:32 imirkin_: look at the AC: line
20:32 imirkin_: and make sure it matches up to the 0f line
20:32 imirkin_: if it does, try flipping resolutions again and see if that helps
20:33 thum: but ignore "AC DC *" at the end in both lines?
20:34 imirkin_: let's try this again... what does the line starting with "AC:" say now?
20:34 thum: core 520 MHz shader 1240 MHz memory 597 MHz
20:34 imirkin_: awesome
20:34 imirkin_: try switching resolutions :)
20:34 thum: works, but...
20:34 thum: looks a little off
20:35 thum: wait
20:35 imirkin_: i.e. better?
20:35 thum: actually it seems to be working perfectly
20:35 imirkin_: excellent
20:35 imirkin_: if you want to apply this setting on boot, you can use nouveau.config=NvClkMode=15
20:36 karolherbst: well maybe I hack up the dyn reclocking patches for gt215+ gpus and test it on my mcp79
20:36 thum: somewhere in modprobe.d?
20:36 karolherbst: and just add an option to enable it for those teslas
20:37 thum: or as a kernel parameter?
20:37 thum:is new to nouveau obviously :)
20:37 imirkin_: thum: a few different ways, depending on how your system is set up
20:37 imirkin_: options nouveau config=NvClkMode=15 in modprobe.d/bla.conf can work
20:38 imirkin_: or sticking what i said on the kernel cmdline
20:38 imirkin_: whatever's easier
20:38 thum: ah great
20:38 thum: thank you for the help!
20:38 glennk: 1920 squared, is this some medical display?
20:38 thum: glennk: nope, let me check on the model...
20:39 imirkin_: it's definitely unusual in today's world of screens-designed-to-watch-movies
20:39 thum: glennk: Eizo EV2730Q
20:39 thum: it's an awesome display
20:39 imirkin_: nice
20:39 thum: for work
20:40 imirkin_: this sounds familiar actually... i think i heard of it
20:40 Weaselweb: but pretty expensive
20:40 thum: yeah it comes at a price, it's exotic.
20:41 thum: imirkin_: if you follow the Libreboot mailing lists, you probably have.
20:41 MichaelLong: thum, nais one, was considering this one too
20:41 imirkin_: nah... i think it was on HN or something
20:41 thum: you get like 32827 terminals on it ;)
20:46 thum: I can confirm that putting a config file with the aforementioned text into /etc/modprobe.d/ works!
20:47 imirkin_: glad it works for you
21:28 mupuf: So, seems like piglit is going to take 4.5h / run on the tk1
21:28 mupuf: oh, but I could upclock the gpu
21:30 mupuf: it does not look like it is affecting piglit's speed at all
21:30 mupuf: so, I guess it is CPU-limited
21:31 mupuf: in this case, I better try to optimize the build of mesa
21:33 mupuf: but anyway, given how little it is used, this is a non-issue right now
21:34 mupuf: and if we need to bisect, then piglit exec time is likely not going to be an issue
21:34 mupuf: compiling mesa takes 13 minutes
21:34 mupuf: but if we do this every day, that should be OK
21:35 imirkin_: 13 minutes??
21:35 imirkin_: are you compiling it directly on the tk1 box?
21:35 mupuf: yes
21:36 mupuf: it is the easiest for now
21:36 imirkin_: heh ok
21:36 mupuf: not sure if distcc could work though
21:36 mupuf: that would be a way to speed things up
21:36 imirkin_: uhm... how could it not?
21:36 imirkin_: this isn't cmake... all the usual tricks work.
21:36 mupuf: and ccache could help
21:37 imirkin_: like cross-compilation, distcc, etc
21:37 mupuf: well, that means that my gcc on my desktop machine can compile ARM code without me installing all the fucking entire toolchain?
21:38 imirkin_: well, you need the toolchain
21:38 imirkin_: should be easy to get going though... at least it is on gentoo
21:38 mupuf: what I like about disctcc is that it still uses the local cpu if the network does not keep up
21:40 mupuf: well, on arch, it is apparently just installing one package: https://www.archlinux.org/packages/community-testing/x86_64/arm-none-eabi-gcc/
21:41 mupuf: well, that could be worth a shot
21:46 mupuf: first things first though, let's get the nvea to spit out a piglit report per day
21:46 mupuf: and bisect changes
21:47 mupuf: then, push the daily changes to piglit.mupuf.org
21:47 mupuf: not sure what to do with the old versions though :s
21:48 mupuf: in the end, we want every release of mesa in order, and HEAD, don't we?
21:48 mupuf: or the last few HEADs
21:50 mupuf: piglit + deqp will likely take most of the day anyway
21:50 mupuf: especially if we want to run it twice, to make sure that tests are not unstable
21:53 karolherbst1: imirkin_: mhh I think I don't quite get slct yet. My slct prints "slct u32 %r917 f32 %r910 neg %r910 %r888 (0)" allthough slct->setCond is 7
21:53 karolherbst1: mupuf: try run 20 piglit tests at once? :D
21:54 mupuf: karolherbst1: at once?
21:54 mupuf: you mean in a row?
21:54 karolherbst1: well parallel tests
21:54 karolherbst1: mhh
21:54 karolherbst1: maybe overhead it process starting though
21:54 mupuf: no, I do not want to do this, as it means missing out on dmesg warn
21:55 karolherbst1: ohh right
21:56 karolherbst1: the heck is CC_TR
21:56 karolherbst1: and where does it come from
21:56 karolherbst1: ohhhh
21:56 karolherbst1: ohhhhhh
21:56 karolherbst: I am stupid
21:57 imirkin_: TR = true
21:57 karolherbst: yeah
21:57 karolherbst: the thing is
21:57 karolherbst: I fed bld.mkCmp with set->cc
21:57 karolherbst: not set->setCond
21:58 imirkin_: oops :)
21:58 karolherbst: awesome, now I generate a nice slct instruction
21:59 karolherbst: my pass: https://gist.github.com/karolherbst/820e2cb34fbdda21c779aee5bea7343c
21:59 karolherbst: :)
22:00 karolherbst: checking if everything is right though
22:00 karolherbst: ehm
22:01 karolherbst: maybe I should compare pre RA with pre RA
22:02 karolherbst: ah, some reversing is missing
22:03 karolherbst: ohh found it
22:10 karolherbst: yeah... NEG won't work on the predicate source
22:11 karolherbst: mhh wait
22:12 karolherbst: ge reversed is le?
22:12 karolherbst: :/
22:12 karolherbst: ahh inverse
22:13 karolherbst: and now I am still left with that stupid join instruction
23:25 karolherbst: imirkin_: what happens when a BB has two Tree outgoing edges, but no branch instruction?
23:26 imirkin_: ka-boom
23:26 karolherbst: mhhh
23:26 karolherbst: well it works
23:26 karolherbst: and the stock nouveau code also does it
23:26 karolherbst: one BB has a " not $p0 neg ftz f32 $r6 $r6 (8)" though
23:27 karolherbst: but the parent BB ends with set ftz u8 $p0 ge f32 $r0 neg $r0 (8)
23:27 imirkin_: oh, this is post-ra? who knows
23:27 karolherbst: yeah
23:27 karolherbst: post-ra
23:27 imirkin_: it's probably a mistake, but no big deal
23:27 karolherbst: ohhh
23:27 karolherbst: yeah of course
23:27 imirkin_: post-ra, the CFG is mostly used to lay out the code
23:27 imirkin_: also used to figure out where to insert texbars
23:28 karolherbst: with the "not $p0 neg" it makes sense
23:28 karolherbst: one edge points to an empty BB
23:28 karolherbst: the other has the predicated neg
23:28 karolherbst: so
23:28 karolherbst: no branching happens
23:28 karolherbst: just a conditional execution of an instruction
23:29 karolherbst: well
23:29 karolherbst: instruction save, is an instruction save
23:29 karolherbst: d
23:30 karolherbst: any I found out why the join didn't got removed: it wasn't bb->getEntry() anymore
23:30 karolherbst: so flattening didn't care
23:30 imirkin_: join's not necessarily the entry instruction
23:31 karolherbst: yeah, but if it isn't flattening doesn't remove it
23:31 karolherbst: so I had a join without a joinat
23:31 karolherbst: and the shader was messed up
23:32 karolherbst: inside FlatteningPass::tryPredicateConditional
23:32 karolherbst: if (bb->getEntry() && bb->getEntry()->op == OP_JOIN)
23:32 karolherbst: removeFlow(bb->getEntry());
23:32 karolherbst: at the end
23:32 imirkin_: nothing's perfect
23:32 karolherbst: yeah
23:32 karolherbst: "total instructions in shared programs : 2135720 -> 2135457 (-0.01%)"
23:32 karolherbst: mhh
23:32 karolherbst: well
23:33 karolherbst: my pass is pretty stupid though
23:35 karolherbst: meh
23:35 karolherbst: we have so many stupid MOVs because of those d/t/q sources
23:36 karolherbst: but this would have to be tweaked inside RA
23:38 karolherbst: ohh
23:38 karolherbst: set u8 %p1088 ne u32 %r421 0x00000000
23:38 karolherbst: yeah, that should be easily mergeble with selp