07:24biker_rat: My GTX 650 doesn't reclock correctly. Only the memory reclocks, not the gpu. Kernel 4.4 & mesa 11.1.1 on archlinux. Any thoughts?
07:56scaroo: imirkin: Hi! Are you interested in a gm107(through PRIME) piglit run ?
08:25Aquarina: I'm experiencing problems with the nouveau driver on debian
08:26Aquarina: installed xserver-xorg-video-nouveau, but even the text console is not behaving correctly
08:29Aquarina: I have a second monitor attached to the vga port of my laptop
08:29Aquarina: and it only duplicates what is on the laptop monitor (with only the resolution provided by that little monitor)
08:29Aquarina: half of my other monitor is not used
08:30Aquarina: this happens even in text mode
08:30Aquarina: any hints?
09:01imirkin: scaroo: sure... i haven't looked at whether i've been breaking it for quite a while
09:01imirkin: Aquarina: pastebin dmesg and xorg log
09:04scaroo: imirkin: Alright. How/where should I send it to ?
09:04Aquarina: imirkin, sorry, whent for a snack
09:05Aquarina: I don't think I can get you a dmesg output since I had to boot into my old system, but let me see...
09:05imirkin: scaroo: make the results file available somewhere and i'll download it. e.g. filebin.ca
09:06imirkin: Aquarina: ok, well, in order to figure out what's wrong i need to see those logs.
09:06Aquarina: let me mout the other system
09:10imirkin: Aquarina: my guess is you're not using nouveau at all
09:10imirkin: Aquarina: and instead using the vesa driver, which would exhibit that behaviour most likely
09:10scaroo: imirkin: here you go http://filebin.ca/2Tn2dsXUqPO6/results.json.bz2
09:11imirkin: scaroo: awesome thanks!
09:12imirkin: "crash": 355,
09:13imirkin: scaroo: is your mesa build a debug build?
09:13Aquarina: imirkin, Ok. I think I have the xorg log
09:13scaroo: imirkin: thanks for your work! so not sure if it has incidence, but this is on a skylake/960m, xorg with intel ddx, DRI3, access to nv through PRIME (DRI_PRIME=1)
09:14imirkin: scaroo: i.e. did you do --enable-debug when building it?
09:14scaroo: imirkin: i can get the debug symbols indeed (this is a rawhide box, with mesa very close to git head)
09:15imirkin: scaroo: nah, not the debug symbols
09:15imirkin: scaroo: did the build have --enable-debug in it?
09:15Aquarina: imirkin, hum... now that you mention it... maybe the log I sent you is after I had changed to fbdev driver...
09:15Aquarina: let me take a look at dmesg, now...
09:16imirkin: Aquarina: more concerning is this:
09:16scaroo: so... no. I can do a build if you need
09:16imirkin: [ 21.319] (II) LoadModule: "nouveau"
09:16imirkin: [ 21.319] (WW) Warning, couldn't open module nouveau
09:16imirkin: scaroo: nah, i think i can figure it out locally
09:16imirkin: would have been a smidge faster if you had.
09:17imirkin: oh hm. it's not what i thought it was....
09:19Aquarina: hehe, dmesg is empty
09:19imirkin: scaroo: can you run: gdb --args /usr/lib64/piglit/bin/shader_runner /usr/lib64/piglit/tests/spec/glsl-1.20/execution/variable-indexing/fs-temp-array-mat4-index-col-row-wr.shader_test -auto
09:19imirkin: scaroo: and then type "r" which should run it, and then when it crashes, type "bt"
09:19imirkin: scaroo: are you a developer? or just a helpful user?
09:20imirkin: [i.e. what level of instructions do i need to provide you]
09:20scaroo: you can go hardcore ;)
09:20imirkin: i.e. lots of instructions? or no instructions at all? :p
09:21imirkin: scaroo: anyways, pastebin the results of that
09:21scaroo: imirkin: not familiar with mesa/drn/nouveau codebases but I am a dev
09:22imirkin: ok, so you know how to operate gdb?
09:22imirkin: eeeexcellent. i hate explaining how to operate gdb :)
09:23scaroo: gimmi a sec, just installing pigly debuginfo and will pastebin the result
09:23imirkin: eh, that shouldn't be necessary
09:23Aquarina: brb, as soon as I get to produce a better xog log
09:27ubr47k: [low relevance] can someone add "Titan Z" to the wiki under NVF1 (GK110B)
09:29scaroo: imirkin: backtrace: http://pastebin.com/UCL6KA8F
09:31imirkin: scaroo: huh. why does it feel like i've seen this before... very recently...
09:32scaroo: already reported ? fixed in HEAD ?
09:32imirkin: ubr47k: done
09:32imirkin: scaroo: no... i had a bug of some sort
09:32imirkin: scaroo: and the result of that bug was this error
09:32imirkin: scaroo: but... i'm not seeing it locally. hm.
09:35scaroo: imirkin: my build here correspond to commit 5e3edd4
09:35imirkin: scaroo: that's *quite* recent... basically the same tree i'm on
09:36imirkin: clearly something's different though
09:36scaroo: prime ?
09:36imirkin: i do have 50 patches or so locally but they're for something else which shouldn't affect it
09:36imirkin: nah, prime is about buffer passing
09:36imirkin: this is the shader compiler failing
09:37imirkin: scaroo: if you could get a debug build (i.e. one that was configured with --enable-debug), i'd very much be interested in the output of NV50_PROG_DEBUG=255 leading up to the crash
09:39scaroo: alright gonna built it now
09:39imirkin: somehow it's getting a broken LValue in
09:39imirkin: oh, THAT's where i saw this... it was with my patches where i was messing with lvalues
09:40imirkin: can you do "p *lval" as well?
09:41scaroo: crap optimized out, I guess the package uses -Ox :/ will do it on a my own build
09:42imirkin: mmmm sec
09:42imirkin: p *it->get()->asLValue()
09:43imirkin: er no, it's the other one...
09:43imirkin: scaroo: p *stmt->def(d).get()->asLValue()
09:44Aquarina: ok, imirkin, I think I have what you asked... with a twist.
09:45scaroo: imirkin: again value optimized out :S will try that as soon as I have a proper build
09:45Aquarina: dmesg: http://pastebin.com/0TUx2zKv
09:45Aquarina: Xorg: http://pastebin.com/WSMpvqm2
09:45imirkin: scaroo: ok. --enable-debug won't set -O0 or anything like that though... you need to stick that into CFLAGS
09:45imirkin: scaroo: and CXXFLAGS
09:46scaroo: imirkin: (BTW, with a proper build, is is just a matter of ldpreload libGL ?)
09:46imirkin: Aquarina: [ 40.590761] nouveau E[ DRM] GPU lockup - switching to software fbcon
09:46imirkin: scaroo: mmmm... never tried it. i always use LD_LIBRARY_PATH
09:47imirkin: Aquarina: G72 chips have slightly messed up MSI, which we enable. in order to avoid the hangs, boot with nouveau.config=NvMSI=0
09:47imirkin: Aquarina: this is fixed in kernels that aren't 2 years old
09:48imirkin: scaroo: to be clear, i do --prefix=/home/user/install and then i do make install and then i use LD_LIBRARY_PATH=/home/user/install/lib
09:49imirkin: doesn't mean other ways can't work, but this is what i do :)
09:49Aquarina: imirkin... hum...
09:49Aquarina: I was looking the orror up on the internet
09:50Aquarina: it goes all over my head
09:50Aquarina: but I'll try what you are suggesting.
09:50Aquarina: put that on the linux line in grub?
09:52Aquarina: lol @ 2 years old kernels... debian, btw.
09:52Aquarina: jessie - stable
09:52Aquarina: not so stable, after all
10:09Aquarina: imirkin, thanks
10:09Aquarina: it kinda worked
10:10Aquarina: (only not on the command line, but that's minor issue
10:10Aquarina: X starts now
10:10Aquarina: so... you think this is a bug in debian kernels?
10:25scaroo: imirkin: mmm... master passes the piglit test. Was there some commit touching IR between 5e3edd4 and master ?
10:27Aquarina: imirkin, Again: Thanks
10:27imirkin: scaroo: it's been known to happen
10:28imirkin: scaroo: oh! yes.
10:28imirkin: scaroo: commit f21df5c51349 should fix it
10:28imirkin: scaroo: you managed to find the like 4-revision-wide hole where that was an issue
10:29imirkin: *that* was where i saw this issue :)
10:30scaroo: somebody should ping fedora mesa package maintainer :) Oh well this is rawhide, I guess it will be updated soon
10:30scaroo: as it is fixed on master, do you still need bt and debug outputs for the current razhide version ?
10:31scaroo: and would you like a piglit run using master over gm107 ?
11:00imirkin: scaroo: nah, it's the precise issue i fixed. that's why it seemed so familiar :)
11:00imirkin: scaroo: if running piglit doesn't cause your machine to hang, a fresh run would be appreciated
11:26scaroo: imirkin: there seem to be a regression somewhere : apart for the aformentioned bug, the previous version skipped 5463 test "only", whereas master skips about 10000 tests (piglit is still running)
11:27imirkin: scaroo: perhaps you built without --enable-texture-float?
11:28scaroo: i didnt used that flag indeed :) trying it out asap
11:28imirkin: scaroo: that limits your build to GL 2.1, since GL 3.0 requires floating point textures
11:28imirkin: which are allegedly protected by a patent
11:29imirkin: in my highly non-legal opinion i think it's a bunch of bs
11:29scaroo: what a wonderful world!
11:30imirkin: but who knows who ended up with that SGI patent
11:32imirkin: aboll: does someone on the debian kernel team monitor firstname.lastname@example.org for backport recommendations for the various kernels debian ships?
11:32imirkin: aboll: btw, sorry i'm asking you all these questions but i have no idea where else to ask :)
12:28scaroo: imirkin_: updated piglit results on a gm107m: http://filebin.ca/2To037BkNmcS/results.json.bz2
12:53airlied: imirkin: a company known as GPHI has the SGI patent, and regularly sue people
12:54airlied: graphics properties holdings, they are what is left of SGI after rackspace bought the name
12:56imirkin: scaroo: ok, that looks a little better. still lots of variable-index fail =/
12:58scaroo: imirkin: if you need some gdb/debug output on this gpu, I am around :)
12:59imirkin: scaroo: awesome. i'm debugging something else atm, but i'll see if i can repro your results locally, and if not i'll request assistance :)
13:02imirkin: scaroo: ok, i think i see (a part of) what's going on
13:03imirkin: the stupid ISA changed again. i hate it all so much.
13:04RSpliet: airlied: when is that patent up for expiry?
13:05scaroo: you mean kepler and maxzell isa are just "slightly" different and devil is in the bloody detail ?
13:05imirkin: scaroo: pretty much. i assumed that some instruction worked the same, but it doesn't.
13:06imirkin: scaroo: apply this patch: http://hastebin.com/ujurezaned.m
13:06imirkin: scaroo: and see if this passes now: bin/shader_runner generated_tests/spec/glsl-1.10/execution/variable-indexing/fs-varying-mat4-col-rd.shader_test -auto
13:08airlied: RSpliet: 2018 I think
13:09RSpliet:steps in his tardis
13:14scaroo: imirkin: how do i generate this test shader ? It doesn t seem to be part of my distro's piglit. I dont see any fs-varying*
13:15scaroo: sorry, wrong folder :s
13:15imirkin: you have it.
13:15imirkin: it's in /usr/lib64/piglit/generated_tests/spec/glsl-1.10/execution/variable-indexing/fs-varying-mat4-col-rd.shader_test
13:15imirkin: (i never install something like piglit, so i just run it out of the built dir)
13:17scaroo: the test passes
13:22imirkin: scaroo: cool
13:22imirkin: i'll push that out
13:23imirkin: and figure out how to deal with it later
13:25scaroo: so do other varying array tests. Guess you nailed it!
13:26imirkin: it's not an ideal fix but... meh
13:26imirkin: my caring level about maxwell is lower than it probably should be
13:26imirkin: once GM20x gets accel i'll care a lot more
13:28scaroo: well, there are quite a lot of maxwell1 laptops around, 960m is showing up in dells, new thinkpads...
13:28scaroo: Has nvidia commited to a date to release the signed stuff ?
13:30imirkin: scaroo: nope
13:30imirkin: scaroo: sure, there's plenty of them, but rarely in places where they do any good
13:31imirkin: scaroo: even if i made the perfect 3d driver for them, without reclocking, it'd still be a fraction of the speed of the intel gpu
13:31imirkin: scaroo: so really it's only for the people with GTX 750/GTX 750 Ti/K620 desktop cards
13:31scaroo: indeed. BTW, how could I help in the reclocking effort ?
13:32imirkin: well, i don't think maxwell reclocking has been touched much
13:32imirkin: i'm not really in tune with what's going on there... i'd try to catch mupuf or karolherbst (not here right now) or maybe RSpliet.
13:34scaroo: alright, I will! As a first step how could I see (apart from kernel panicking) if maxwell reclocking is very different from kepler's ?
13:35imirkin: scaroo: well, the first step in any of these endeavours would be to collect a mmiotrace from the blob, and esp getting it to switch between clocks
13:35imirkin: scaroo: you're in a good position since the nvidia gpu isn't your main gpu
13:35imirkin: so you can load/unload nvidia at will
13:35imirkin: (as well as nouveua)
13:38scaroo: but but but is it possible to instruct nvidia's drm to switch clock without the binary ddx ? it's interface is known ?
13:38imirkin: scaroo: if you want credit for reporting the varying-indexing issue, pm me your name/email so i can stick a Reported-by tag.
13:38scaroo: bah i dont care :)
13:38imirkin: scaroo: just use nvidia-settings? something like that. karol will know, he does it all the time.
13:38imirkin: i guess that uses NV-CONTROL, so you must have a second X server running on the nvidia card
13:40scaroo: sounds legit, might need some bumblebee-like abominatiion
13:40imirkin: scaroo: unrelatedly, i recommend you install libtxc_dxtn -- that will allow s3tc textures to work
13:43scaroo: yet another patent byproduct...
13:43imirkin: i don't make the rules :)
13:46imirkin: scaroo: ok, pushed that patch out...
13:46imirkin: none of the other failures jump out at me as particularly unexpected
13:47scaroo: well, thanks for your time and effort. Hanging around if anything else catch your attention. And will try to optain the trace of the bianry for maxwell clk
14:06imirkin: scaroo: btw if you're interested in 3d devel, maxwell is missing some bits of tessellation, which is why you only get GL 3.3 with it, not GL 4.1
14:07imirkin: scaroo: if you're interested, you can finish the maxwell tessellation implementation... it's missing one specific bit
14:10RSpliet: imirkin, scaroo: maxwell reclocking is untouched
14:12RSpliet: although gnurou might have something (well concealed) in flight for Tegra X1
14:12scaroo: imirkin: well I guess it is out of my current skillset, but I have some free time, why not giving it a try. What/where should I look for reference?
14:14imirkin: scaroo: what's your level of familiarity with GL?
14:14valborro: suspend and hibernate do not work for me ona NV50 NVA3 (GT215) GPU
14:14scaroo: RSpliet: as pointed by imirkin, i have access to the hardware so if you need trace or smth...
14:15valborro: after reboot I get errors like nouveau 0000:01:00.0: ce0: intr 00000300
14:15scaroo: imirkin: i stopped looking when it was still a fixed pipeline :) so wero xp of shader programming :)
14:15imirkin: scaroo: ok cool. so basically like me until i started playing with nouveau.
14:16imirkin: scaroo: let's not worry about the details of this... basically there are stages, and you can write code for them, and they have various input/output expectations.
14:16imirkin: scaroo: one of the stages is the "tessellation control program", aka "hull shader" in directx speak
14:17imirkin: scaroo: one of the things that it can do is write outputs (duh), but it *also* can read other invocations' outputs. this is uncommon.
14:17imirkin: scaroo: so... obviously nvidia changed the way that is done between kepler and maxwell
14:17imirkin: because why keep it the same when you can change it
14:18imirkin: soooooo what you'll need to do is analyze the shaders captured in the mmt traces here: http://people.freedesktop.org/~imirkin/traces/gm107/
14:18scaroo: by invocation you mean vertex/pixel shaders or invocation of the tess itself (wich would be logical I guess as subvertex generation looks somehow recursive by def)
14:19imirkin: (the "tess" ones)
14:19valborro: is suspend to RAM supported for NV50 family?
14:19imirkin: multiple invocations are done of the tess control shaders... one for each control point it's shading
14:19imirkin: (where "shading" means "processing")
14:20imirkin: scaroo: the basic idea of tessellation is let's say you have some bezier surface describing... something. and that something can move. so you feed the N control points into the control shader, and then deform them however you want, and you have your new control points
14:21imirkin: (and then there's an evaluation shader, which evaluates the surface based on those control points. it's pretty clever.)
14:21imirkin: there's a software package called envytools
14:21imirkin: which has a tool called "demmt" which will let you analyze those traces
14:21imirkin: so... basically the task is to look at those shaders and figure out wtf they're doing
14:22imirkin: and then implement the same thing in nouveau
14:22imirkin: i ran out of steam at the "figure out wtf they're doing" part. i was really hoping it was the same as kepler.
14:22imirkin: and i'd already spent a ton of time on figuring out a stupid difference between fermi and kepler
14:23imirkin: so yet-another difference didn't seem too appetizing to me
14:23scaroo: Can't promise success by i ll put some brain cycles into it!
14:23imirkin: ok, and feel free to ask questions
14:23imirkin: there's a lot going on here
14:23imirkin: and i hardly gave you enough info
14:24imirkin: but it should be enough to get started and come back with a more informed "i don't get it" style questions :)
14:24scaroo: Yeah , be ready for the flow :)
14:25imirkin: valborro: in theory it works for a bunch of people. i've never personally tried it.
14:25imirkin: valborro: note that CE0 is an engine that first appeared on GT215 i think
14:25imirkin: (the "copy" engine)
14:26valborro: imirkin: OK, should I report this as a bug?
14:26imirkin: valborro: i pushed a patch which helped some people with suspend/resume types of issues, esp in the context of kde plasmashell
14:26imirkin: valborro: what kernel are you on?
14:27imirkin: that should have the fix i think... let me double check
14:27valborro: I have installed the xf86-video-nouveau 1.0.12 package on archlinux
14:28valborro: will be back in 15 min
14:29imirkin: valborro: huh, doesn't look like it is. i guess it will be in 4.3.4? commit 04b8a4bd8e01e25b9fa9fa7b1c957a7346ae83c1 upstream.
14:32imirkin: valborro: it's also in 4.4 of course (since 4.4-rc1)
14:32scaroo: imirkin: would you mind describing each files at the url you pointed me to ? Also for reference, where in mesa tree can I find kepler's tesselation implementation?
14:32imirkin: scaroo: only look at the tess* ones
14:33imirkin: scaroo: they're mmt trace files (from valgrind-mmt, which is a tool written by joi, and perhaps others? dunno), basically record the conversation of userspace with the kernel
14:33imirkin: scaroo: demmt will decode those files into something readable
14:34scaroo: sanity vs. quads ?
14:35imirkin: scaroo: the kepler bits that you'd have to re-figure out are here:
14:36imirkin: (i think... there might be more)
14:36imirkin: the thing is that kepler and prior were both pretty straightforward... maxwell not so much
14:36imirkin: kepler gained the AL2P thing but maxwell appears to use it a lot more
14:37imirkin: and it appears to read this stuff directly out of memory, not using the usual intrinsics
14:37imirkin: sanity vs quads are the piglit tests this traced
14:37imirkin: tests/spec/arb_tessellation_shader/execution/sanity.shader_test and quads.shader_test
14:38imirkin: once you get demmt going, search for START_ID
14:40mupuf: Well, that is a bummer, the nvd9 crahes while running heaven
14:40mupuf: let's see if it is related to the tesselation
14:41mupuf:is setting up a performance CI system on his old nvd9 laptop
14:41imirkin: mupuf: gah! really? :( i think hakzsam also has a nvd9 and i haven't heard anything from him
14:41hakzsam: imirkin, let me try
14:41imirkin: mupuf: what kind of crash are we talking about? segfault? or hang?
14:41mupuf: yeah, got a lot of FIFO intr 0x5 IIRC
14:42mupuf: nope, GPU hanh
14:42imirkin: well i haven't seen anything like that on my GF108
14:42imirkin: how much vram do you have?
14:42hakzsam: mupuf, with mesa master?
14:42mupuf: hakzsam: yes
14:42mupuf: imirkin: rebooting, will tell you in a sec
14:42hakzsam: mupuf, nothing here
14:43mupuf: ok, cool ... I guess :D
14:43imirkin: hakzsam: "nothing"?
14:43imirkin: mupuf: what level of stuff are you using? high? ultimate?
14:43hakzsam: imirkin, I meant, it works fine :)
14:43imirkin: mupuf: also are you using 4.0 or the unreleased 4.1?
14:44mupuf: Will check in a sec for the level
14:45mupuf: ok, it finished rebooting
14:45valborro: imirkin I will try suspend with 4.3.4
14:45mupuf: horrible machine... but it will do the trick for continuous testing and bisecting
14:45mupuf: so, 512MB of VRAM
14:46mupuf: GART, 1 TB? :o
14:46hakzsam: mupuf, did you test on reator?
14:46mupuf: hakzsam: nope, this is my labri laptop
14:46hakzsam: okay :)
14:47mupuf: I am planing on using my nv86 and nvd9 for testing
14:47mupuf: since they do not take a lot of space
14:48mupuf: and we cannot really do REing on it because it cannot be integrated with wtrpm
14:48mupuf: at least until I open them and add wires
14:53mupuf: testing in high, no tess
14:57imirkin: valborro: there is no 4.3.4 yet :)
14:58imirkin: mupuf: hm, i guess it could be some thing with running out of vram and nouveau failing in various ways. i have 2GB.
14:58valborro: imirkin: yes, will test it when it comes out :)
14:59imirkin: valborro: are you using kde5 plasmashell?
14:59valborro: no, i am using i3 wm
14:59imirkin: hmmmm ok
15:00imirkin: less likely to be the same issue then
15:00imirkin: although still possible.
15:00valborro: ok, will try and report if still having issues
15:00valborro: thank you for your help
15:01imirkin: valborro: however if it still doesn't work, my question will be "what about 4.4" or maybe "what about 4.5-rc1"
15:01mupuf: imirkin: possible
15:02mupuf: the machine is not really set up properly yet, it is sort of a pain to work with it
15:02mupuf: especially since it is an optimus machine
15:02valborro: imirkin: it is not a very important bug for me, so I can still use the machine
15:02imirkin: mupuf: get it going with DRI3, that fixes a lot of configuration headaches.
15:02imirkin: valborro: kk
15:02mupuf: yop, good idea
15:04mupuf: seems like it crahed again, even without tesselation
15:04mupuf: my logs get flooded with SCHED_ERROR 13
15:04mupuf: it was 14 last time
15:04scaroo: imirkin: alright, i have a readable repr of the trace, have several occurence of START_ID. which should I look at ? (Is it part of the prologue of a shader ?)
15:05imirkin: mupuf: next time might be 12 :)
15:06imirkin: mupuf: just wait till it hits 0 ;)
15:06imirkin: scaroo: you're looking for the TCS (or TCP?) shader
15:06mupuf: then .... kabooooom!
15:06imirkin: mupuf: no, 0 = no error
15:06mupuf: big badaboom
15:07scaroo: TCP it seems
15:07scaroo: TCP it seems
15:07imirkin: that's the tessellation control program
15:08scaroo: (not how my previous message wasn't ack by the tcp/ip stack thus had to resend it... well uhuh)
15:09imirkin: scaroo: oh looks like i might have lied... TEP might need some love too
15:09scaroo: what about a TIP ?
15:09imirkin: tessellation evaluation program
15:09scaroo: (ok it is late here)
15:09imirkin: anyways... so find the real TCP
15:09imirkin: the first one is a fake one
15:09imirkin: look for the one with lots of instructions
15:10scaroo: got it
15:10imirkin: ok so you see how there's the $directbewriteaddresslow and isberd nonsense?
15:10imirkin: one needs to figure out what that nonsense is all about
15:10imirkin: coz i have no clue
15:12imirkin: scaroo: btw, you shouldn't expect this to be a 5-minute task. if it were, i would have done it already.
15:12scaroo: i must admit my asm-fu is quite rotten, is there a way to decompile that into a c-like representation somehow ?
15:12imirkin: not that i'm aware of. these are nvidia gpu opcodes btw
15:12imirkin: not x86 or anything like that
15:13imirkin: let me know if you don't know how to interpret some particular op
15:13imirkin: (mad = multiply + add btw)
15:14imirkin: it's generally intel-style, i.e. op dst src0 src1
15:14scaroo: what about 'sched' ?
15:14imirkin: ignore those
15:14imirkin: every 4th op there's scheduling info
15:15imirkin: sometimes we don't decode it properly (due to limitations in the disasm logic)
15:15imirkin: so it'll come otu as
15:15imirkin: 00000100: e7a007f0 087fc000 $p0 fadd32i cc $r240 abs $r7 neg 0xfc000e7a
15:15imirkin: but it's still just a sched op
15:15imirkin: every 4th one :)
15:15mupuf: Ah ah, the intel gpu is much much faster than nouveau on nvd9 without reclocking
15:15mupuf: looks like a factor of two
15:15imirkin: mupuf: it also doesn't have to transfer the data over the pci bus
15:16mupuf: what data? unless it is lacking vram, that should not be an issue
15:16imirkin: mupuf: and intel doesn't do fp64 :p
15:16mupuf: does xonotic use it?
15:16imirkin: of course not
15:17imirkin: nothing uses it
15:17mupuf: which does not help motivate the troops :p
15:17imirkin: which is why i spent an hour last night making it work with ssbo
15:17mupuf: Go tell that to Topi who tried to make it work on Intel GPUs for months :p
15:18imirkin: well from what i can see igalia has made a lot of progress on it
15:18mupuf: 28.3 fps for nouveau, 56 for Intel
15:19mupuf: yep, let's hope it does not end up in chasing hangs
15:19imirkin: i prefer to run away from them :)
15:24scaroo: imirkin: is the isa i am looking at the PTE ISA as described in cuda's doc ?
15:25imirkin: scaroo: of course not :)
15:25imirkin: but... related
15:25scaroo: would be too easy :)
15:25imirkin: there are no docs for these... at least not official ones. the PTX ISA is just something nvidia puts out
15:25imirkin: so... ISBERD is probably input something BE read
15:26imirkin: where the BE is related to $directbewriteaddresshigh
15:26imirkin: ISBERD.O relates to outputs
15:26imirkin: as opposed to inputs
15:26imirkin: (all guessing here btw)
15:27imirkin: and then at the end, the output writes become stg (store global)
15:27imirkin: instead of the more usual AST
15:27imirkin: so there's some protocol for computing the global address of these things
15:28imirkin: and it needs to be figured out
15:28imirkin: ISBERD is critically related to this stuff... somehow
15:32scaroo: and mmm what is the question mark in ?[smth] ? The decompiler couldn t figure out the dereferenced stuff ?
15:32imirkin: scaroo: ignore the ?
15:32imirkin: scaroo: basically it was unclear what to call the memory space
15:49imirkin: scaroo: so the idea is to have a clear understanding how to convert the desire to read/write outputs into the instructions you see there... those tests are pretty simple, in that they just write outputs, no funny business. once that's figured out, there are other levels of nastiness.
15:52scaroo: mmm, so the shaders here a basically noop and all the instructions i am seeing are just related to getting other invocations outputs, right ?
15:52imirkin: scaroo: well basically there's a lot fixed function stuff going on *around* the shaders. each shader is responsible for reading its inputs and writing its outputs
15:53imirkin: actually shuffling that data around is in magic-land
15:53imirkin: but yeah, the noop TCS is pretty simple :) that's kinda the point
16:46valborro: imirkin: i have switched from grub to syslinux and the suspend/hibernate problem is gone on the GT215
16:56orbea: been seeing a lot of suspend/hiberate issues lately, is this the 4.4.0 kernel? For me it was xfs and some bad commit from a suse dev....
17:02valborro: orbea: it is a 4.3.3 kernel
17:34imirkin: valborro: no clue why that'd matter
18:02imirkin: airlied: can you teach skeggsb how to run CTS?
18:06airlied: imirkin: if I ever get to the office at the same time as hime again
18:24P1ro: hi, does nouveau works with cuda? or only nvidia drivers ?
18:26imirkin: P1ro: no cuda support... cuda is a proprietary api
18:27P1ro: imirkin ok thanks
18:27imirkin: i think there's some llvm support for actually compiling cuda into something a bit more useful, but i haven't looked at the details
18:42skeggsb: airlied: baby keeping you busy? :)
18:47airlied: skeggsb: not too bad, just need to be nearby to help out if necessary :)
19:07sooda: skeggsb: hi, do you have any virt plans up your sleeve? i see how the nvif mechanism would work with that in general (and some patches mention it), but is there any clear direction yet? i'd like to get familiar with that
19:28skeggsb: sooda: filling in the gaps where nvif doesn't express some functionality that's needed (i'm currently working on something that'll fill in one of the big gaps as a side-effect), and making it possible to build the drm portion on its own without being directly linked to nvkm (think: what the guest part of the driver would need) are the initial bits that need dealing with i think
19:29skeggsb: it's not a direct goal of mine though currently, but, i keep it in mind when working on other things
19:44imirkin: alrighty... with some RA abracadabra, down to these deqp ssbo fails: http://hastebin.com/iyotozigur.md
19:45imirkin: a few are due to not having images, a few are due to the drm platform not supporting windows, and the rest... i'm gonna blame on hakzsam .
21:27sploozer: hello...is there a quick and dirty to enable dual monitors with the nouveau driver? I have a legacy nvidia card
21:30imirkin: sploozer: should Just Work (tm)
21:31sploozer: xrandr shows both monitors connected and the supported resolutions
21:31sploozer: but the 2nd monitor won't enable
21:31sploozer: i've had to use the nvidia drivers in the past but there is a kernel conflict at the moment
21:31imirkin: so... what's the problem?
21:31sploozer: not sure what else I can do
21:32sploozer: I'm running 02:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 9300 GE] (rev a1)
21:32imirkin: sploozer: pastebin the output of xrandr
21:33sploozer: the monitor isn't broken :)
21:34imirkin: and what's going on with the monitor that's not working? is it asleep, or is it "on" but showing black?
21:34imirkin: and also, which monitor is it? dvi, or hdmi?
21:36sploozer: its on showing black...
21:36sploozer: maybe I need to confirm whats in my xorg.conf
21:40imirkin: sploozer: ok, well let's try making it clone your first screen...
21:41imirkin: sploozer: xrandr --output HDMI-1 --same-as DVI-I-1
21:41sploozer: i don't want to clone it
21:41sploozer: anyhow I ran it
21:42sploozer: 2nd monitor is still lights out
21:42imirkin: is it still black?
21:42imirkin: can you check if there's anything odd going on in dmesg?
21:42imirkin: what kernel is this btw?
21:43sploozer: i can try w/ 4.2.8
21:44sploozer: nothing odd in dmesg
21:48sploozer: ok on 4.2.8 now
21:48sploozer: the display manager does not give you an option for a twin display
21:50sploozer: mean anything to you?
21:52imirkin: yeah that all seems fine
21:53sploozer: anything else you want to see?
21:53sploozer: the display manager doesn't give you much of an option
21:53imirkin: what if you leave only the "broken" monitor connected, does it start working?
22:01imirkin: i guess that didn't go too well
22:22imirkin: gnurou: in case you're not aware of what my script does: https://github.com/imirkin/re-vp2/blob/master/extract_firmware.py
22:27imirkin: skeggsb: there are people who *still* report stability issues fixed by blob gr fw
22:27imirkin: skeggsb: but i generally agree with you that it's not *really* worth supporting, which is why i didn't raise a big stink when the paths changed
22:57gnurou: imirkin: ah, I thought these FW had Nouveau-written equivalents
22:57gnurou: imirkin: I guess it's better to not switch to my functions for them
22:57gnurou: btw, does your script also work with the latest NVIDIA drivers?
22:58imirkin: gnurou: no... you guys changed how you were packing stuff
22:58gnurou: imirkin: right, that's what I figured out recently as well :/
22:58imirkin: gnurou: oh, maybe i could still do it for the video fw, but... meh. doesn't really matter.
22:59imirkin: the fw barely changes version to version, and my script ain't magic, it only works after i (or someone) has done the hard work of actually finding these things and determining signatures.
23:00gnurou: well the good solution would be that *we* release these firmwares officially
23:00gnurou: like, all of them
23:00imirkin: gnurou: unfortunately it would take *considerable* effort to write nouveau firmware for these engines
23:01imirkin: vp2/vp3/vp4 all have internally-programmable hardware accessible from xtensa/falcon using insane ISA's which aren't necessarily easy to RE
23:01imirkin: i don't know what the deal with vp5 is, but that one might be baked in somehow, and thus easier? dunno, haven't looked.
23:02imirkin: gnurou: definitely +1 from me for nvidia releasing these in a redistributable manner... my script is a bit of a hack, both technologically and legally speaking
23:02imirkin: gnurou: note that there are user-space components to the firmware for vp2/vp3/vp4
23:02imirkin: (i.e. loaded by mesa, and fed in buffers to the engines)
23:03gnurou: eh, funny
23:03imirkin: this isn't a strict hardware requirement, but it's how that was done
23:03imirkin: the VP2 one is wildly insecure and would allow a dedicated individual to root the box
23:03imirkin: [not nouveau-specific of course]
23:04imirkin: since you basically just feed it an xtensa/falcon blob to be executed... so you can do whatever that cpu has access to
23:04imirkin: and the xtensa cpu has access to everything :)
23:04gnurou: guess that's partially why we switched to signed firmware
23:04imirkin: i guess iommu would protect it
23:05imirkin: nah... the vp2 situation was just bad
23:05imirkin: if you reprogrammed some pci stuff, you could end up doing whatever dma you wanted
23:05imirkin: i suspect the signed firmware is to get on top of the fake hardware situation
23:06imirkin: where people would flash it so that the gpu would report as something that it was not
23:08imirkin: gnurou: you can look at my extraction script for the full list of blobs necessary... almost all of those are used. i never did vc1 support for vp2, and iirc there's one or two "extra" h264 or mpeg4 blobs we don't use coz we don't know when we should use them, and it works fine without it.
23:08gnurou: imirkin: got it. thanks
23:46mupuf: I wonder if nvidia's patches to get tear-less prime support is going to help Nouveau too
23:47mupuf: I managed to get my system somewhat working
23:47mupuf: but the tearing is unbearable
23:47mupuf: well, it is not tearing, it is displaying images out of order
23:49mupuf: and there are multiple tearing lines