00:10kloofy: airlied: is it maybe possible to not hang the whole machine doing things over iommu or this so called VT-d, i would not even need a graphicsl output just the console to start with?
00:10kloofy: using some virtual machine that could pass through the card
10:39kloofy: as i don't seem to either have those extensions or not fleshout in usrespce in linux to work on top of the firmware i probably will do the isolation under the OS
12:51rmrfchik: i wonder, whats wrong with proprietary drivers, webgl is blazing fast in nouveau and 3-4 fps in nvidia
12:52imirkin_: ask your browser vendor?
12:52imirkin_: i doubt it's intrinsic to webgl
13:20kloofy: imirkin_: i went out and did couple of beers and talked with major lovely irish grandmo
13:30kloofy: imirkin: is right about the env variable, to be honest only mesa has it, multi-device
13:31kloofy: and it can be implemented in different ways, but mesa one should work too
13:31karolherbst: rmrfchik: maybe EGL is being used and your nvidia driver version doesn't support that or packaging problems?
13:33karolherbst: imirkin_: it seems like here on mac os x BGR_565 isn't supported as well by nvidia
13:34karolherbst: as well as RGBX_8888
13:34imirkin_: what would you like me to do about it?
13:35karolherbst: not sure, thought it might be some interesting piece of information, just noticed that by accident.
13:35imirkin_: those are all supported on all nv50+ gpu's
13:35imirkin_: there's no bgr565_srgb support though
13:35imirkin_: but there's a bgrx/rgbx8_srgb
13:40kloofy: and to be honest recent times i've been advocated that americans do crimes their own, i am not really scared about it,i've got support all around the world
13:41kloofy: i can go against anyone i like
13:42kloofy: as for united states marine i said you gonna sit around here, and i will command you, in contrast to what they offered, that i gonna end up in trashbin
13:44kloofy: non the less americans are worl nr. 1 in science, whera as dutch control them too, even such a small nation
13:45kloofy: i did some beers you don't give me that shit that i am afraid to go against americans
13:47kloofy: as in realistic view some of the marines were clearly bullying with me, and i was about to care about the veterans
13:48kloofy: i.e slaughter the fuck like a dog
13:48kloofy: only then they thought it's best to guard me even
13:50kloofy: imirkin: cmake is fine aight...
13:52kloofy: it's what appears ont he surface with cmake, is lot easier to program then autotools
13:52kloofy: i-e the gnu stuff
13:54kloofy: mr death arrived
13:56kloofy: Smjert: a utebja kak eta zisn?
13:56kloofy: are you in a position to wipe me off without facing cocinciquences?
13:57Smjert: kloofy: i might disappoint you, i'm not russian/ukrainian, i only very few words eheh
13:57Smjert: i only know*
13:58kloofy: off-topic then, i thought some of the pickets, however i go out to grab some beers again
13:59imirkin_: kloofy: i'm updating my policy - even though i have you on ignore, you're effectively spamming the public logs with ... junk. please stop, or i will start actively banning you.
13:59Smjert: kloofy: my family did host an ukrainian boy back then, but.. we were talking a mix of languages.. anyway.. :P
14:00kloofy: imirkin_ buzz the fuck off retard
14:00kloofy: imirkin_: you do not start anything i start the shit
14:01rmrfchik: kernel crash again, no traces in /var/log/messages :(((
14:01rmrfchik: 4.7.0 this time
14:06kloofy: this flyback or this guy, aren't those cpu manuals mostly formed or done my chinease who can't even mostly speak the language?
14:06kloofy: because those manuals are anything but specific, but luckily i always have some other options in the end
14:10kloofy: recent news revealed that chinease have found a lot of resource on their areas, enough to bully with american president before the meeting in g20
14:10kloofy: what they signalled was that yanks get nothing
14:12kloofy: i miss my golden neckless bought from south africa, now chinease have found lots of gold, mostly africa is known to be very rich, but underdeveloped
14:12kloofy: opprotunity for endless ..you know how it is
14:13kloofy: just english and yanks taking control
14:19kloofy: was it gaddafi who they killed being one of the favorite in their country i was told, keeping the resources to to themselves, well try to invade killing me , i have friends in europe too
14:19kloofy: it's not going to be a walk in the park
14:25kloofy: as for the atomic theory, it is known that soveiets first breakhtrough was done from rosevelts times atomic wastes
14:26kloofy: now the soviets definitely have lots of nukes not to mention yanks who were the first to develop them , so along many countries have them
14:28kloofy: what about haarp?
14:29kloofy: again russians and yanks have this also china as always
14:41finnish: man what's up don't you think it's better off to block my ip, then the name kloofy, but imirkin_ is undoubtedly soft
14:42finnish: he wants to me to come back always and educate you all, nouveau's measures are soft
14:42imirkin_:really doesn't want to have to ban all of *.ee like some channels have...
14:49Helloxxc: Scared as it should be,
14:53pq: I've been thinking about doing exactly that but never had quite enough to bother yet - thank you
14:53imirkin_: i figure the end game will be to ban all of estonia, but i'm hoping i can avoid it
14:54imirkin_: i've already banned a swath of even non-estonia ip's from web-based proxies (that elisa mobile carrier only has a /21)
14:56megari: Is this guy notorious in a broader sense or is he only bothing this channel?
14:57imirkin_: other graphics channels too
14:57imirkin_: some have just hard-banned web proxies in general and *.ee
15:01pq: it may have been more than 5 years ago when I fell into his trap the first time, not knowing him then
15:04imirkin_: when you were still young
15:21jay_: any one there
15:37RSpliet: karolherbst: I'd never looked into the warp suspend values before, but I find them fascinating :-P
15:38RSpliet: see how three seemingly similar multiplies take three different suspend values - I can sort of understand why "write back to same register" could take an extra cycle, but... why the last mul takes so much longer... :-)
15:43karolherbst: RSpliet: most likely because of the write into $r4 in the first mul
15:44karolherbst: and because mov executes faster, the second mul has a lower value
15:45karolherbst: and the first mul has even a joinat between itself and the def
15:45karolherbst: but what do I know about that
15:45karolherbst: maybe it is the other way around
15:46karolherbst: no idea
15:46karolherbst: I am more concerned why there aren't more dual issues
15:46karolherbst: ohhh s32
15:47karolherbst: RSpliet: you should look at a binary generated by nvidia for pixmark_piano
15:49karolherbst: RSpliet: https://gist.githubusercontent.com/karolherbst/81ceeecbaaaef7eec45f06552682ba48/raw/103809a42ec2e28afcf5a502e953d43e6d7a3e7e/gistfile1.txt
15:49karolherbst: there you see how hard nvidia actually tries to push as much as possible between def and use
15:50karolherbst: look at "00000a50: 7df65c40 58000000 mul ftz rn f32 $r25 $r31 $r31"
15:50karolherbst: sched is 0x20
15:50karolherbst: which is the lowest value possible
15:50RSpliet: karolherbst: I prefer to look at simple cases rather than complex ones ;-)
15:50karolherbst: $r31 is 000009d0: 77f7dc20 081e0000 max ftz f32 $r31 0x0 $r29 which is like 15 instructions before
15:50karolherbst: same for $r25
15:50karolherbst: 000009d8: 99e65c42 30fd9999 mul ftz f32 $r25 $r30 0x3f666666
15:51karolherbst: so you have both src like 15 instructions before
15:51karolherbst: then you do the mul with sched 0x20
15:53karolherbst: ohh well, that binary is quite interesting though
15:53karolherbst: a lot of good stuff in there
15:54RSpliet: karolherbst: I always assumed that the scheduling hint indicates the number of cycles *after* insn issue
15:54karolherbst: mhh no idea really
15:54RSpliet: that's what envydocs says
15:54karolherbst: but I think it is actually before
15:54karolherbst: because the second instruction is marked as dual issue
15:54karolherbst: not the first one
15:54karolherbst: and even then
15:55karolherbst: why mark the issued as dual issue
15:55karolherbst: doesn't it make sense then to mark the defs with it then?
15:55RSpliet: it issues the mov along with the joinat
15:55karolherbst: both movs are dual issued
15:55RSpliet: that would be silly
15:55karolherbst: why is that?
15:56RSpliet: because the envydocs docs say otherwise :-P
15:56karolherbst: you can't dual issue with joinat to begin with
15:56RSpliet: ... if you know all this, fix the docs! ;-)
15:57RSpliet: but then
15:57RSpliet: there's a delay associated with the *first* insn of the program
15:57RSpliet: surely that doesn't mean *before* the first insn
15:57karolherbst: mhh right, maybe I have to think again
15:57karolherbst: maybe you are actually right...
15:58karolherbst: mhh right, why would nvidia start the shader with 0x4 then
15:58karolherbst: but then again, why not in your example....
15:58karolherbst: ohh wait
15:58karolherbst: maybe accesses to c can't be dual issued as well
15:58karolherbst: well two accesses
15:59RSpliet: sounds plausible
15:59karolherbst: mhh, would be an interesting experiment
16:00karolherbst: there is "// no loads and stores accessing the same space" in codegen
16:00karolherbst: but maybe it is stricter than that
16:00karolherbst: RSpliet: https://github.com/karolherbst/mesa/blob/master/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp#L608
16:00karolherbst: mesa would dual issue both movs in your example as I understand it corectly
16:01RSpliet: looks like it
16:02karolherbst: RSpliet: can you do the same thing with f32?
16:02RSpliet: karolherbst: well, this is just a very basic observation from some OpenCL kernels I created
16:03RSpliet: surely there's a fairly easy way to get piglit to generate the insn you want...
16:03karolherbst: well the hardware tells us how much it actually dual issues, so we can verify it
16:04RSpliet: anyway, I wouldn't be surprised if lines 647-651 have to be pushed upwards before line 625
16:05karolherbst: no idea
16:05karolherbst: actually not
16:05karolherbst: because 625 is only true if both classes are equal
16:05karolherbst: and 647 schecks for LOAD+STORE
16:08RSpliet: either way I wouldn't be surprised if the nouveau dual issue logic needs a lot of refinement :-)
16:08karolherbst: that's why I get like 4% more perf in pixmark_piano just by improving it :D
16:10karolherbst: okay, nvidia dual issues two fma f32 with c1 as source
16:10karolherbst: gotta go
18:27karolherbst: mhh we are kind of bad regarding dual issuing :/ dual issue rate is just slightly above 50%
18:27karolherbst: (with my dual issue pass)
18:44karolherbst: k, joins get a sched of 0x2f
18:46karolherbst: 1056 -> 1059 Score :)
19:00karolherbst: holy crap :O a little change to my pass and the performance improved quite a lot now
19:00karolherbst: dual issue rate nearly at 60%
19:00karolherbst: 1059 -> 1073 score
19:10karolherbst: I am wondering, why can't we dual issued "fma ftz rn f32 $r6 $r4 0x40000000 $r3" + "mul ftz rn f32 $r1 $r5 $r1"
19:11karolherbst: nvidia does it
19:11karolherbst: "fma ftz rn f32 $r13 $r45 0x40000000 neg $r39" + "mul ftz rn f32 $r4 $r4 $r8"
19:14karolherbst: ohh wait, the fma was dual issued with another instruction already in the previous block
19:14karolherbst: but I am actually wondering about that already. nvidia doesn't seem to ever dual issue the last one
20:52karolherbst: huh, nvidia doesn't dual issue two cvt instructions
21:03karolherbst: maybe I am blind, but why doesn't mesa dual issue here: https://gist.github.com/karolherbst/5032e8846cd735e50dcadebbbbd1ad2b :/
21:33karolherbst: imirkin_: there ya go: https://github.com/karolherbst/mesa/commit/c8e8b41a93e4705334f0ca365dc90f4d2fbf2743
21:35karolherbst: it made the code worse though :O
21:40amfern: guys, how do you test your changes, i assume change code -> compile -> reboot -> observe the change. is there a way to spare the reboot?
21:40imirkin_: changes to what?
21:40amfern: to nouveau
21:40imirkin_: nouveau is like 30 diff things
21:40karolherbst: amfern: for the kernel module: stop X, unbind vtconsole, rmmod nouveau, load it again, start X
21:41karolherbst: huh, current codegen can't handle "mov b32 $r25 0x3dc49ba6 + add ftz f32 $r26 neg $r25 0x3e851eb8"
21:41amfern: ok, and i made changes drm load function?
21:42amfern: and if i made*
21:42amfern: or to secure bootcode, is there a way to test it without reboot?
21:43imirkin_: amfern: not really. changes to the kernel module most often require a reboot.
21:43imirkin_: sometimes you can get away without it, but it's generally not worth it
21:44karolherbst: imirkin_: wanna take a look at my OP_SUB removal patch and tell me if that's the right way or if I can be more clever about it
21:45imirkin_: karolherbst: i think you went too far
21:45imirkin_: just lower it away
21:45imirkin_: don't do that silly OP_SUB_NO_USE thing
21:45karolherbst: I just did that, so that I don't have to modify those bitfields
21:46imirkin_: i know
21:46imirkin_: but i'm saying - keep it
21:46karolherbst: ahh okay
21:46imirkin_: only add lowering to make OP_SUB go to OP_NEG + OP_ADD
21:46karolherbst: from tgsi?
21:46imirkin_: no, in AlgebraicOpt or something
21:46amfern: imirkin_: so to keep my development enviroment i ssh into the machine from different machine, is that what you generally tend to do?
21:46imirkin_: before modifierfolding happens
21:47imirkin_: amfern: i generally tend to avoid modifying the kernel module :)
21:47karolherbst: I think we should really remove it when converting from TGSI, or is there some disadvantage doing that?
21:47imirkin_: meh. i guess that's fine if you prefer.
21:47karolherbst: do you think there will be hw to support OP_SUB ever?
21:48karolherbst: then I would say we shouldn't care about that op at all and just remove it entirely from the code
21:49karolherbst: but sadly the effect of removing it isn't exactly big. bad scheduling has a bigger impact currently :(
21:50karolherbst: but now I am indeed wondering why this one add block won't be dual issued...
21:50karolherbst: it is super odd
21:51karolherbst: imirkin_: are there any OPs which get droped while emitting code?
22:00imirkin_: when *emitting*? definitely not. that'd mess everything up
22:01karolherbst: k, then I have no idea why that happens
22:01imirkin_: leave OP_SUB in
22:01imirkin_: don't try to be clever and rename it
22:01imirkin_: don't remove all the handling for it
22:01imirkin_: just lower it away
22:12karolherbst: ohh, there is a delay >= 0 check
22:12karolherbst: that might be it
22:13karolherbst: and it seems to be important :D
22:33waltercool: guys, someone knows how to use a display connected to dedicated nvidia using nouveau? I have 3 displays wired to the nvidia card, and Intel integrated isn't able to detect them
22:34imirkin_: waltercool: https://nouveau.freedesktop.org/wiki/Optimus/
22:34imirkin_: look for "Using outputs on discrete GPU"
22:34waltercool: imirkin_: even if xrandr doesn't detect both providers?
22:35imirkin_: on the off chance you're running the latest and greatest X server, you'll also need https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b824d36c28124955eda4aced5e637aa75eea4d6c
22:35imirkin_: xrandr should see both providers
22:35imirkin_: if it doesn't, something is going wrong.
22:35imirkin_: perhaps you have an xorg.conf - if so, nuke it.
22:35waltercool: hmm let me restart, may it be the dummy driver
22:36waltercool: give me a sec
22:43waltercool: imirkin_: nope :(
22:43waltercool: Provider 0: id: 0x45 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 2 associated providers: 0 name:Intel
22:43imirkin_: waltercool: did you remove xorg.conf?
22:44imirkin_: waltercool: pastebin xorg log
22:45waltercool: may it be because is maxwell2? :(
22:46waltercool: the final add/removal was due rmmod and modprobe of nouveau
22:47imirkin_: [ 846.849] (**) Option "AutoAddGPU" "false"
22:47imirkin_: you've explicitly turned off the option that makes this stuff possible.
22:48waltercool: oh I see, give me another sec
22:52waltercool: hmm still nothing
22:53imirkin_: do you not have modesetting installed?
22:53imirkin_: try removing xf86-video-nouveau from your system if you do have it. perhaps it's not falling back properly.
22:55waltercool: imirkin_: What do you mean with modesetting?
22:55waltercool: Let me try, I hope to not broke something, xf86 nouveau isn't longer needed?
22:55imirkin_: er, xf86-video-modesetting
22:56waltercool: oh, I don't have xf86-video-modesetting installed
22:56imirkin_: well, it comes packaged as part of Xorg now
22:56imirkin_: although some distros may have helpfully split it out
22:56imirkin_: in order to maximize the difference to how upstream does it
22:56waltercool: for good or for bad?
22:57waltercool: is recommended?
22:57waltercool: I meant, should I have it installed?
22:57imirkin_: modesetting? well you must if you want to use those screens.
22:57imirkin_: [for maxwell+]
22:57waltercool: I see, let me install it and restart X, do I need to add something to Xorg?
23:01waltercool: hmm xorg-server 1.18.4 doesn't like current modesetting
23:01waltercool: may it be because is integrated? :S
23:02imirkin_: you know the drill...
23:02imirkin_: xorg log :)
23:02waltercool: I mean, is already integrated: /usr/lib64/xorg/modules/drivers/modesetting_drv.so
23:03waltercool: so, would I need to add it as load module?
23:06waltercool: uhmm well... I will check it later, I don't have a clue... but thanks for all anyways :) I will start investigating through optimus
23:06imirkin_: pastebin xorg log :p
23:07waltercool: I meant, I didn't done anything
23:07waltercool: since last time
23:07imirkin_: well, once you install it
23:07imirkin_: it should get autoprobed
23:07waltercool: I didn't needed to install modesetting because it was already in
23:07imirkin_: and you should see a GPU-0 screen
23:07waltercool: seems like Gentoo bundle it automatically
23:07imirkin_: ok, so remove xf86-video-nouveau then
23:07waltercool: just eDP1 and VIRTUAL1
23:07waltercool: ok, give me a sec
23:08imirkin_: those aren't screens
23:08waltercool: I know
23:08imirkin_: i'm talking about X screens
23:08waltercool: removed, let me restart and try again
23:11waltercool: and nothing
23:12waltercool: nouveau is loaded btw
23:12imirkin_: yeah, it finds the drm device...
23:13imirkin_: you have a Device section for intel
23:13imirkin_: remove it.
23:13waltercool: let me start a clean X
23:13waltercool: without any specific
23:15waltercool: yeah, very different jeje
23:15waltercool: but same result
23:15imirkin_: --listproviders should now list a second provider
23:15waltercool: at least the screens seems to be detected
23:16waltercool: yey yeah :D
23:16imirkin_: now you can run the xrandr command to add the offload provider thing
23:16waltercool: hey, many thanks! It appears now
23:16imirkin_: xrandr --setprovideroutputsource 1 0
23:18waltercool: it works fine :) Many thanks bud!
23:19imirkin_: np. enjoy.
23:19waltercool: it froze me X before, but now is great
23:19waltercool: I owe you a beer
23:51mooch: hey, mwk, if i wanted to look at a disassembly of windows 95 nv4 drivers, where would i start?
23:51mooch: yes i have ida