00:29 pmoreau: imirkin: Oh right, my French is getting through... And yes, "Apple Gmux _DSM"
00:32 hansg: imirkin, hi, I'm here about https://bugs.freedesktop.org/show_bug.cgi?id=90435
00:34 hansg: Note I'm working for Red Hat (I'm a college of skeggsb) and the plan is for me to start working on nouveau, also see the self introduction mail I just send to the nouveau list
00:34 hansg: So I've time to work on this, but as said in my self intro I'm pretty green when it comes to gpu stuff, so I can use some help / hints how to debug this.
00:36 RSpliet: hansg: welcome ;-)
00:36 RSpliet: as long as it doesn't mean I have to start carrying linux-sunxi :-D
00:37 hansg: RSpliet, hi, on linux-sunxi, your last reply in the "Proposal to add NAND-boot support for Sunxi SPL" once more has dropped all Cc-s is that intentional ?
00:37 RSpliet: no, but I re-sent it to everybody a few minutes ago
00:38 hansg: Ok
00:43 mupuf: hansg: let me re-iterate what I said on the ML. Welcome to the project!
00:43 mupuf: :)
00:44 hansg: thanks
00:48 hansg: mupuf, do you know what timezone imirkin is in ?
00:48 mupuf: yes, east coast US
00:49 mupuf: so, 5h difference with you
00:49 mupuf: IIRC
00:49 hansg: mupuf, ah, then pinging him now is not really helpful :)
00:49 mupuf: yeah, it is not going to yield the best results :)
00:49 hansg: If he is near Boston 6h (lots of RH colleges there)
00:49 mupuf: that would be the same tz
01:01 pmoreau: hansg: Welcome! :)
01:09 hansg: So anyone here who can help me with debugging: https://bugs.freedesktop.org/show_bug.cgi?id=90435
01:10 hansg: I've downgraded to mesa-10.0, as the report said that helps, but it does not help for me. I've interrupted glxgears in gdb and done a bt and it hangs in DRI2GetBuffersWithFormat
01:10 hansg: (my intend was to git bisect this bug, but since the reported downgrade does not help for me, that is not an option really)
01:12 hakzsam: hansg, Hey, welcome :)
01:19 mupuf: hansg: seems like a funny bug
01:20 mupuf: it could indeed simply be a present bug and not a rendering bug
01:20 mupuf: did we drop the support for dri1 in nouveau?
01:20 mupuf: if not, you may want to try dri1 as it will render straight to the front buffer
01:21 hansg: mupuf, I indeed have the feeling that it is some sort of vsync / pageflip related bug
01:21 mupuf: alternately, you may want to force enabling dri3
01:21 mupuf: oh, that could also be!
01:21 mupuf: try with vblank_mode=0 glxgears
01:22 hansg: mupuf, that fixes things (at least with mesa-10.0
01:22 mupuf: good!
01:23 mupuf: so, the bug is probably not in mesa
01:23 mupuf: but in the ddx or the kernel
01:23 hansg: So how do I debug this further? Note lets starts with the vblank=0 thing and then try mesa-master once that is finished)
01:24 mupuf: actually, I would suggest trying mesa master and checking if the workaround still works
01:24 hansg: Ok, will do that first then
01:24 mupuf: my opinion is that it won't change anything
01:24 mupuf: 10.0 is so old that people will have forgotten about it
01:24 mupuf: better use the latest and greatest and debug on it
01:25 hansg: Given that the origina report is about 10.5 not working and needing to go all the way back to 10.0 we may have 2 bugs... But as said I'll try master first.
01:25 mupuf: if my hunch is right, the bug will likely be in the ddx (possible since no-one tested the rendering synced to vblank there) or in the kernel for *some* outputs
01:25 mupuf: as Ilia's NV4x works
01:26 mupuf: yep, looks like multiple bugs
01:26 mupuf: if we have multiple bugs, then, working on 10.0 will make sense
01:28 hansg: mupuf ack, I'
01:28 hansg: I'll try mesa-master and if that fails even with the work around I'll go back to 10.0 and tackle the vblank bug first.
01:29 mupuf: sounds about right!
01:30 mupuf: as to how to debug the vblank issue, I would start with the kernel and make sure you do receive the vblank IRQs
01:31 hansg: ok
02:10 mupuf: hansg: does the workaround work on mesa master?
02:13 neoraider: Mmh, I have really weird behaviour with my NVD9 on kernel 4.0.4 with nouveau
02:14 neoraider: After stating X, VT switches fail
02:14 neoraider: The X log says "Failed to switch from vt01 to vt02: Input/output error"
02:19 neoraider: I haven't tested any other kernels yet, I've just switched from the nvidia blob to nouveau as with nvidia s2ram doesn't work anymore with the newest kernel/driver versions
02:22 hansg: mupuf, yes it works, and I checked without the workaround and the nvmk interrupt count in /proc/interrupts does not change when running glxgears (and glxgears hangs)
02:22 hansg: So looks like a vblank irq issue. First I'm going to try to use the vga output instead of the dvi one and see if that makes a difference
02:22 mupuf: sounds like a good idea
02:23 mupuf: although it should not change anything
02:23 mupuf: the hw is the same in both cases
02:23 mupuf: but maybe this is a bug in the dvi codepath
02:23 hansg: mupuf, note I'm the dvi-out as dvi (rather then as a second vga out)
02:24 hansg: s/I'm/I'm using/
02:30 hansg: mupuf, ok, you're right switching to vga does not help
02:30 hansg: mupuf, any further hints on debugging this ?
02:30 mupuf: I would suggest reading the envytools documentation
02:30 hansg: Ok.
02:31 mupuf: as in, rnndb and hwdocs (unlikely to contain anything related to display, IIRC)
02:31 mupuf: rnndb == reg dump in xml format
02:31 mupuf: I would suggest looking at the values written by nouveau in the relevant registers and comparing with rnndb
02:32 mupuf: I would also suggest fiddling around with nvapeek/nvapoke and try to enable to IRQs while the damn thing is running
02:32 mupuf: maybe nouveau simply disables the irq because it thinks there are no users for it, so you may want to add some traces related to display
02:32 mupuf: there is a kernel parameter to get debug information
02:33 mupuf: http://nouveau.freedesktop.org/wiki/KernelModuleParameters/
02:33 hansg: Thanks that should get me started. I'll start digging into this
02:34 mupuf: nouveau.debug="PDISPLAY=trace" will give you *everything*
02:34 mupuf: you may need to recompile the nouveau module though to get all the register writes
02:34 mupuf: do you know how to recompile nouveau out of the kernel tree?
02:37 hansg: mupuf, no I do not know howto recompile nouveau out of the kernel tree, that certainly seems like a useful way to work on the kernel side of things. Is there a special git repo for this, or ... ?
02:37 mupuf: yes
02:37 mupuf: http://cgit.freedesktop.org/~darktama/nouveau
02:38 mupuf: you will need to use an rc kernel for that
02:38 mupuf: IIRC, Ben uses the rc kernels from rawhide
02:38 mupuf: or whatever name the repo has nowadays
02:39 hansg: Ok, I should be able to get that working, thanks
02:39 mupuf: when running an rc kernel, you may simply do the following
02:39 mupuf: cd drm
02:39 mupuf: make
02:39 mupuf: and you'll get /drm/nouveau/nouveau.ko
02:40 mupuf: you may also want to be able to reload the module without rebooting
02:40 hansg: Hmm, what happens when I rmmod when I'm using kmsconsole ?
02:40 hansg: <comments crossed>
02:40 hansg: Yes I would like to be able to do that :)
02:41 hakzsam_: you can use a script like this http://hastebin.com/eyucatalog
02:41 mupuf: hansg: I doubt you can use kmscon and reload the module
02:41 mupuf: http://hastebin.com/ivugizaxer.bash
02:41 mupuf: hakzsam_: thx :D
02:42 mupuf: yeah, use hakzsam_'s script, it is more complete than mine
02:43 hansg: I might have mixed up my terminology here, what I mean with kmscon is just the standard linux text virtual consoles running on kms
02:44 mupuf: yeah, I got it
02:44 hakzsam_: btw, you will have to modprobe nouveau before running that script if nouveau is blacklisted by default
02:44 mupuf: is it used by default on fedora?
02:44 hansg: Yes
02:45 hansg: As soon as a kms driver loads, the monitor switches to the native resolution and the kernel text console gets rendered in the native resolution
02:45 mupuf: hansg: then you will need to get rid of it
02:45 mupuf: kmscon is not needed for this
02:45 mupuf: nouveaufb does the same
02:46 hansg: Hmm, but doesn't nouveaufb conflict with using a kms driver ?
02:47 mupuf: no idea how all this works
02:47 mupuf: but I never had any problem
02:47 skeggsb: 19:43 < hansg> I might have mixed up my terminology here, what I mean with kmscon is just the standard linux text virtual consoles running on kms
02:47 skeggsb: nouveaufb == kmscon, if that's what you mean :)
02:47 skeggsb: there's another "kmscon" project i think, that's something different, hence the confusion
02:48 hansg: Ah, ok
02:48 mupuf: Right, I was surprised kmscon would be used by default on fedora
02:48 mupuf: skeggsb: thx for clearing the confusion
02:49 pmoreau: skeggsb: This one I guess: http://www.freedesktop.org/wiki/Software/kmscon/
02:49 skeggsb: is kmscon even still maintained? i thought it disappeared
02:49 mupuf: skeggsb: I hope I did not say too many stupid things while getting hansg started :)
02:49 skeggsb: no, it seems like there's progress already in tracking it down :P
02:49 mupuf: no idea if it disapeared, one would need to ask david
02:49 hansg: mupuf, no worries sofar you've been really helpful. I'm learning a lot and we got the bug narrowed down from "it hangs" to "sync to vblank does not work" which is a huge improvement
02:50 mupuf: anyway, skeggsb, are we disabling vblank IRQs if there are no users for it?
02:51 hansg: Ah, that is why kmscon is lodged in my mind, David is still actively pursuing that (talked to him about this last october)
02:51 mupuf: Where do you think hansg should look for the issue?The ddx or the kernel?
02:52 skeggsb: it could be either, if it's the kernel, i probably screwed it up with some change or other.. but the dri2 code has also seen a lot of changes over the last while
02:52 mupuf: right
02:52 mupuf: and buffer age will be coming over soon
02:52 hansg: skeggsb, I'm not seeing any interrupts in /proc/interrupts when running glxgears with sync to vblank enabled, not even 1.
02:53 hansg: I could try an older kernel, any idea for a good version to try ?
02:53 mupuf:is currently fixing issues with regards to active uniforms handling and the vector constructors in glsl, but I will soon move to the driX and help icke there
02:55 skeggsb: the interesting thing is that the bug report claims mesa 10.0 works
02:55 skeggsb: presumably without changing the kernel or ddx versions..
02:55 hansg: skeggsb, except that it does not for me.
02:55 skeggsb: ah
02:55 skeggsb: just got to that comment :)
02:56 skeggsb: i'd probably try reverting the ddx to before the big batches of dri changes
02:56 skeggsb: seems simpler to check first
02:56 hansg: Ok
02:58 hansg: skeggsb, so the version to try would be 1.0.10 then, right ?
02:59 skeggsb: that looks about right from a quick glance
03:03 hansg: Hmm, so that fixes glxgears, but trying to run gnome-shell is still broken. After killing X over ssh (I think it was after) I get the following in dmesg: "nouveau E[gnome-shell[25014]] failed to idle channel 0xcccc0000 [gnome-shell[25014]"
03:03 skeggsb: one problem at a time :P
03:03 skeggsb: as i said, nv3x/nv4x support has rotted a bit over the last while
03:04 hansg: Hehe
03:05 hansg: Ok, so shall I git-bisect the glxgears issue ?
03:06 skeggsb: sounds like a reasonable plan :)
03:08 mupuf: hansg: seems like you're narrowing down on the bug quite well!
03:08 hansg: ok, it is time for lunch break for me now. and I also have some non nouveau stuff which I need to do, but I
03:08 hansg: I'll try to get this done today ( Grrr ' and <enter> keys are too close to each other)
03:11 imirkin: hansg: welcome :)
03:12 imirkin: hansg: ftr, my first step would be to remove complexity from the stack. gnome-shell introduces enormous quantities of complexity... what happens if you just run X, no wm, no compositor, no funny business?
03:12 skeggsb: imirkin: you don't sleep long ;)
03:12 imirkin: skeggsb: usually i do. today's an exception.
03:13 mupuf:is having the same problem in finland right now. The sun is always out and I can;t sleep after seeing the sun
03:14 hansg: imirkin, I'm already running just X + xterm + metacity + glxgears. After the downgrade of the ddx fixed the glxgears issue I decided to give gnome-shell a try, but that did not end well :)
03:14 hansg: So I'll go back to my simple test setup and bisect the ddx issue which is causing glxgears to not work
03:14 imirkin: hansg: ok cool, that sounds good. ftr, it does seem to mostly work on my NV44 + S-Video
03:14 imirkin: (why S-Video, you ask? my monitor has an s-video input and can do picture-in-picture with it.)
03:15 mupuf: nice
03:16 imirkin: hansg: rather unrelatedly, i recently wrote up a summary of how opengl operates for pmoreau... happy to forward that on to you. not sure how familiar you are with the various concepts
03:16 mupuf: imirkin: how about putting it in a wiki form? I must have missed it
03:17 mupuf: that would be a great document for new comers
03:17 imirkin: hansg: and back to the nv4x thing, i pushed a ton of nv30 driver fixes in the past couple of days. unlikely to fix your issues, but... maybe :)
03:17 imirkin: mupuf: it was a direct email, so you wouldn't have seen it. nothing nvidia-specific... just the GL pipeline
03:18 mupuf: ok
03:18 hansg: imirkin, I'm not familiar at all yet, so I would love to have such a writeup. I'm also planning to work my way through: http://nouveau.freedesktop.org/wiki/IntroductoryCourse/ although a lot of that seems either stuff I mostly know (I'm familiar with 2d display engines) or obsolete(ish)
03:18 mupuf: it still is very relevant to newcomers to mesa
03:18 imirkin: hansg: ooooh... be careful with that stuff. most of it was written back in the year 1900...
03:19 hansg: imirkin, I'm aware of that, I'm planning on reading at least this one: http://jrfonseca.blogspot.com/2008/04/gallium3d-introduction.html
03:20 imirkin: at a quick glance, looks not-completely-wrong :)
03:23 mupuf: I added two resources
03:23 mupuf: https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline and http://cwabbottdev.blogspot.de/2013/06/compiler-theory-links.html
03:25 imirkin: hansg: sent. if you find it useful, i'll throw it up on a wiki and let people who *actually* know GL poke holes in it.
03:27 imirkin: hansg: note that nv4x doesn't have tessellation or geometry shaders, and the nv50 family doesn't have tessellation. nvc0+ has all the stages.
03:28 imirkin: hansg: also we use the two numbering conventions interchangeably... so nve4 = gk104, nvc0 == gf100, nv50 == g80.
03:33 hansg: imirkin, thanks
03:35 hansg: imirkin, skeggsb, git bisect done, it points to this commit which is not really helpful: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=f0fa8313714c2a5b16e784b257b5ff79da3a443b
03:35 skeggsb: haha :)
03:50 hansg: Ok, I've updated: https://bugs.freedesktop.org/show_bug.cgi?id=90435 with my findings sofar, and now it is really lunch time. After lunch I need to do some non nouveau work, so I'll see you all tomorrow. If in the mean time you've any suggestions how to debug the vblank issue further please leave a comment in the bug.
03:50 imirkin: hmmm... well the vblank stuff was working fine for me. it sync'd to 50hz (not sure why it picks the 50hz modeline by default rather than 60, but... wtvr)
03:51 hansg: imirkin, right this might be specific to nv46 or even to my cards video bios
03:52 imirkin: i haven't tried vga/dvi though... perhaps i should
03:52 hansg: imirkin, perhaps you can try with another output then the svideo output
03:52 imirkin: but i won't be able to in the near future
03:52 hansg: Right comments crossed
04:02 hansg: Really going afk (and of irc) for lunch now
06:02 imirkin: skeggsb: do you see anything wrong with RT_FORMAT => { COLOR = A8R8G8B8 | ZETA = Z24S8 | TYPE = SWIZZLED | LOG2_WIDTH = 0 | LOG2_HEIGHT = 2 } ? (nv44)
06:03 imirkin: skeggsb: i'm getting a DATA_ERROR with that =/
06:03 imirkin: seemingly it doesn't like LOG2_WIDTH == 0?
08:29 imirkin_: skeggsb: btw, another hole on nv30 are msaa resolves... i'm not actually sure how those are supposed to work... can you bind a MS texture to a regular sampler slot?
08:55 imirkin_: glennk: any idea how msaa resolves worked in the bad old nvfx days?
08:56 imirkin_: [or even the gf 6/7 days]
08:57 imirkin_: there appears to be a commented out call to a transfer_rect, which is roughly speaking a custom resolve... but a really bad one because it probably places the samples at different coords than where they were rendered
08:58 skeggsb: imirkin_: nvidia resolves using NV_SCALED_IMAGE_FROM_MEMORY iirc
08:58 skeggsb: but, it's been a *long* time since i looked at that
08:58 imirkin_: skeggsb: oh hmmm... ok
08:58 imirkin_: ;)
08:58 glennk: i think the blob had an env var for correct vs fast...
08:59 imirkin_: haha
09:00 imirkin_: skeggsb: any ideas about this dude's acpi vbios being read out wrong?
09:00 imirkin_: skeggsb: https://bugs.freedesktop.org/show_bug.cgi?id=90626
09:00 skeggsb: i haven't had a chance to look at that one yet, but i've been following the bug
09:00 imirkin_: it's weird.
09:00 imirkin_: it's esp weird that it even sees that ce73 address -- nvbios identifies it as "Some script", aka "i have no idea wtf script this is"
09:02 imirkin_: hm, one of the pointers in the 'I' entry
09:14 imirkin_: skeggsb: looking at sifm, it doesn't seem to know anything about MSAA... so it's just a scaled blit right?
09:14 skeggsb: yep
09:14 imirkin_: ok cool. so that's the wrong way, but faster ;)
09:15 imirkin_: seems better than printing an error and doing nothing
09:38 imirkin_: pmoreau: could i trouble you to run 'glxinfo -l -s' against mesa 10.6-rc on your G96?
11:00 tobijk: imirkin_: should the failed to idle channel bug introduced in 4.1-rc be resolved with kernel 4.1-rc5+?
11:00 imirkin_: tobijk: i'm not aware of such a bug
11:01 imirkin_: tobijk: but there have been no nouveau patches pushed upstream, so if it's a new bug, then unlikely
11:01 tobijk: it was introduced in 4.1rc for me, or something in X hcnaged, but i'm not aware of it
11:02 imirkin_: ok. well, i'm sure you're right, but... i'm not aware of any such bugs having been filed, bisected, etc
11:03 tobijk: i see them o shutdown, its not that critical, just takes like 30sec for it to recover
11:03 imirkin_: like system shutdown?
11:03 tobijk: yep
11:03 imirkin_: weird.
11:04 imirkin_: perhaps you can get it to trigger on module unload?
11:04 imirkin_: then it'd be a lot easier to bisect
11:04 tobijk: right, i'll see what i can do :)
11:05 imirkin_: not a lot of drm api changes recently, so you can probably do it on the out-of-tree one
12:08 pmoreau: imirkin_: Hum... I... don't know... :D
12:08 pmoreau: imirkin_: Any rc or a specific one?
12:08 imirkin_: pmoreau: well, there's only 1 so far
12:09 pmoreau: Oh really? I'm probably confused by having 10.7-devel being displayed when using a git build
12:09 imirkin_: yeah, 10.6-rc1
12:09 pmoreau: You're right: I should have looked at the tags first
12:09 imirkin_: ;)
12:10 pmoreau: Ok, building it right now
12:11 imirkin_: pmoreau: oh, and if you have a few mins (and a fat inet pipe), can you try replaying the trace at https://bugs.freedesktop.org/show_bug.cgi?id=90513 on either the nv96 or nvac and see if it has the same red rendering issue as on fermi+?
12:11 pmoreau: If you need other information / testing / piglit tests, feel free to ask! :)
12:11 pmoreau: Ok
12:12 imirkin_: i'm curious to know how wide-spread the issue is...
12:12 pmoreau: Afraid it could be an epidemy?
12:12 imirkin_: hehe, unlikely
12:12 imirkin_: but nv50 and nvc0 share a compiler
12:12 imirkin_: and also the hw is pretty similar
12:12 imirkin_: but e.g. the constbuf submission is different
12:13 imirkin_: that's my most recent theory for fail
12:14 pmoreau: Downloading the trace. Can I test it against 10.6.0-rc1 or rather against latest git?
12:17 imirkin_: doesn't matter
12:17 pmoreau: Ok
12:18 pmoreau: brb
12:44 pmoreau: imirkin: It is not happy
12:44 pmoreau: http://pastebin.com/UDGWu1Nd
12:45 pmoreau: But I get: Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_TRANSFORM_FEEDBACK_BUFFERS)
12:45 pmoreau: glxinfo: ./nv50/nv50_context.h:183: nv50_context_shader_stage: Assertion `!"invalid/unhandled shader type"' failed.
12:48 imirkin_: oh crap, right
12:48 imirkin_: can you...
12:48 imirkin_: pmoreau: git cherry-pick e4201bb618f02a279fda59a1c528d7218e6900a5
12:48 imirkin_: on top of 10.6-rc1
12:54 pmoreau: Will it inpact the replay or not (not having it I mean)?
12:55 imirkin_: pmoreau: well your glxinfo output is incomplete coz it died part-way
13:00 pmoreau: I mean, I replayed the trace and got lots of misrendering.
13:00 imirkin_: pmoreau: hmmmm crap
13:00 imirkin_: pmoreau: not just a red frame here and there?
13:00 imirkin_: but i would like you to cherry-pick that commit so i can get a complete glxinfo ;)
13:01 pmoreau: Some red quads, some gloomy yellow surfaces, some gloomy white circles, the ground turning completely black, the sky going into dark mode, some weird white dots all over the place
13:01 pmoreau: And rendering at 0.3 fps
13:01 imirkin_: hmmmm
13:01 imirkin_: that's a lot more than on nvc0 =/
13:01 pmoreau: Sure, I'll do it
13:01 imirkin_: blehhhh
13:01 pmoreau: But it could come from the card
13:01 imirkin_: no.
13:02 pmoreau: I mean, it's not like I need to PCI-reset it to get it to work ;)
13:02 imirkin_: hehe
13:02 pmoreau: I'll check on the MCP79
13:02 imirkin_: it _could_ be some feature silently being used that's not supported by fermi
13:02 imirkin_: but i dunno what it would be
13:02 pmoreau: But I'll get a proper glxinfo first
13:03 imirkin_: i *have* pushed some small fixes to master that haven't made it to the -rc series yet
13:03 imirkin_: but i doubt they'd have any effect o nthis
13:03 imirkin_: hakzsam_ also fixed some questionable query logic... perhaps related
13:05 pmoreau: I'll test on git
13:05 imirkin_: but give me the glxinfo from -rc
13:05 imirkin_: :)
13:10 pmoreau: "My precious glxinfo... Oh yes, we want it!" :D
13:11 imirkin_: we wants it
13:12 pmoreau: Meh...
13:12 pmoreau: Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_TRANSFORM_FEEDBACK_BUFFERS)
13:12 imirkin_: expected
13:12 pmoreau: And a few others
13:12 imirkin_: ignore that
13:12 pmoreau: Ok
13:12 imirkin_: just do 'glxinfo -l -s > foo' which will skip over those errors
13:13 pmoreau: glxinfo -l -s | xclip won't work?
13:13 imirkin_: that's fine
13:13 pmoreau: http://pastebin.com/y50zv3qw
13:13 imirkin_: Mesa 10.7.0-devel
13:13 imirkin_: oops?
13:13 pmoreau: Hum
13:14 pmoreau: I did recompile, reinstall and restart X
13:14 imirkin_: why restart X?
13:15 pmoreau: Just in case
13:16 pmoreau: Weird... Why don't I get 10.6.0-rc1
13:17 imirkin_: did you type 'checkout' instead of 'cherry-pick'?
13:17 pmoreau: I didn't
13:17 pmoreau: And I'm still on top of the 10.6.0-rc1 tag
13:17 imirkin_: very odd
13:17 pmoreau: With the modifications from the patch you linked
13:17 imirkin_: well wtvr. good enough.
13:19 pmoreau: I stashed the changes, I'm back to the error, but still on 10.7-devel...
13:19 imirkin_: probably something funky in your build
13:19 imirkin_: don't worry about it
13:19 pmoreau: Ok
13:20 pmoreau: Going back to git, and I'll replay on the MCP79
13:26 hakzsam_: imirkin_, did you take a look at the trace related to League of Legends with wine, btw?
13:26 imirkin_: hakzsam_: nope, he said it didn't repro the hang
13:26 hakzsam_: yeah, that's strange
13:26 imirkin_: hakzsam_: although perhaps it repros the validation issues
13:27 imirkin_: in which case it's sufficient
13:27 imirkin_: but i haven't checked...
13:27 hakzsam_: I'm going to take a quick look at it
13:27 imirkin_: me too :)
13:28 hakzsam_: :)
13:29 hakzsam_: the patch I submitted to that bug is quite useless I think..
13:29 imirkin_: wasn't sure where you got that from
13:30 hakzsam_: from here http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c#n135
13:32 imirkin_: replays fine on my GK208, no errors
13:34 hakzsam_: 91596 @1 glXSwapIntervalMESA(interval = 1) = 0
13:34 hakzsam_: 91596: warning: unsupported glXSwapIntervalMESA call
13:34 hakzsam_: but no errors in dmesg
13:34 imirkin_: right
13:35 hakzsam_: tested on NVD9
13:38 imirkin_: oh interesting, it's a free game
13:38 imirkin_: didn't realize that
13:39 hakzsam_: but not supported on Linux ;)
13:39 imirkin_: sure... but wine
13:39 hakzsam_: yes
13:53 hakzsam_: I just asked for a new trace, but well if you want to directly play with it, have fun :-)
13:54 imirkin_: well... getting people to provide traces only goes so far
13:54 imirkin_: i've fixed at least a few bugs by reproducing with the original game
13:55 imirkin_: notably http://cgit.freedesktop.org/mesa/mesa/commit/?id=d06ce2f1df54edd234b1abde37bba524ed599acb
13:56 hakzsam_: okay
13:56 imirkin_: a lot easier to poke around when you have a repro
13:56 imirkin_: and sometimes traces don't do it
13:56 hakzsam_: sure
13:56 imirkin_: due to timing or who knows what
13:58 tobijk: ah lol...
14:00 tobijk: that semi works with wine? interestinf :)
14:00 imirkin_: hm?
14:01 tobijk: expect the nouveau bug ;-)
14:05 imirkin_: joi: btw, you need to varinfo_set_variant(var, "gf100"); for the nvc0 case
14:06 imirkin_: joi: some of the images stuff is nvc0-only
14:07 joi: really? before aae5fcf7e8 there was no varinfo_set_variant(var, "gf100") either
14:07 imirkin_: joi: yeah, and it was buggy then too :)
14:08 imirkin_: looks like i haven't made any images traces available on fd.o, but i had to hack it in manually at one point
14:09 imirkin_: otherwise both F_GF100 and F_GK104 are false in the envydis logic
14:14 joi: heh, none of my traces hit this case
14:14 imirkin_: yeah... you need something with image loads/stores
14:15 imirkin_: i have some in my private collection ;)
14:15 imirkin_: i'll try to remmeber to upload tonight
14:44 pmoreau: imirkin: Just tested the trace with mesa git + MCP79: rendering is way worse, but it might be explained by the overflow of "nouveau E[ PFB][0000:03:00.0] trapped write at 0x005315aa00 on channel 0x0000f96f [glretrace[1159]] PGRAPH/PROP/RT0 reason: PAGE_NOT_PRESENT" and other PGRAPH error I get
14:44 pmoreau: I didn't check if I had any similar errors on the G96
14:45 imirkin_: could be a TF issue
14:45 imirkin_: nva0 has some sort of TF-related breakage
14:46 pmoreau: And some "fail ttm_validate"
14:46 pmoreau: TF? Team Fortress?
14:46 imirkin_: transform feedback
14:46 imirkin_: but close ;)
14:46 pmoreau: Ok :D
14:46 imirkin_: fail ttm_validate is probably the actual cause of that
14:46 imirkin_: i'm guessing vram_list?
14:47 imirkin_: that means that you ran out of vram :)
14:47 imirkin_: we really shoudl be calling nouveau_validate_pushbuf
14:47 pmoreau: validating bo list, validate: -12
14:47 imirkin_: uhhh
14:47 imirkin_: full error please
14:47 pmoreau: It completely overrun
14:47 pmoreau: I'll redo it
14:48 imirkin_: do you have libdrm 2.4.60? coz that causes some bo list errors
14:48 hakzsam_: what bug are you talking about?
14:48 pmoreau: 2.4.61-1, should be fine
14:49 pmoreau: The Talos Principle one
14:50 pmoreau: hakzsam_: https://bugs.freedesktop.org/show_bug.cgi?id=90513
14:53 hakzsam_: okay
15:01 pmoreau: imirkin: Apparently the bo validation failed is the first error (pastebin incoming)
15:02 imirkin_: gah! i think i see what's wrong with at least the kepelr tess stuff
15:02 imirkin_: $invoc stores some funny business in the upper 2 bits!
15:02 pmoreau: At some point, everything breaks and I get to see the content of the shadow maps ^^
15:03 imirkin_: their sequence appears to be mov x $invoc; shl x, x, 2; shr x, x, 2; and then use *that* in the ld p[]
15:08 pmoreau: imirkin_: I did remove some PAGE_NOT_PRESENT error messages to get the size down; http://pastebin.com/qqTe2TVJ
15:20 hasenov: hello everyone, using darktama branch I compiled on my system successfully
15:21 hasenov: and startx works from root, however does not work from regular user
15:22 hasenov: had to install from darktama branch since using NV117 chipset which is not supported in package manager
15:23 tobijk: hasenov: care to paste dmesg and xorg log?
15:24 tobijk: but mabe you are just not in the video group or something?
15:26 imirkin: hasenov: linux 4.1-rcN should contain GM107 accel support as well
15:26 imirkin: hasenov: note that you're best off using xf86-video-modesetting, *not* xf86-video-nouveau
15:26 imirkin: unfortunately the glamor support is hooked up very poorly into nouveau and is ~broken
15:27 imirkin: but it's hooked into modesetting just fine
15:27 tobijk: imirkin: i guess its just a problem with rigts, if it works fine while beeing root?!
15:27 hasenov: umm, i hope so
15:27 imirkin: tobijk: well, the incorrectness is that dri2 is unsupported
15:28 imirkin: tobijk: and with dri3, you must have access to the rendernode
15:28 imirkin: but... it's just broken all around. use xf86-video-modesetting :)
15:28 tobijk: yeah hence the get into video group :)
15:29 tobijk: and modesetting wont hurt, sure :)
15:30 imirkin: pmoreau: i think the "fail ttm_validate" means that we asked it to move bo's around, and it couldn't meet the constraints.
15:31 imirkin: pmoreau: we handle this case *quite* poorly in nouveau, unfortunately.
15:31 hasenov: adding user to group "video" did not work
15:32 tobijk: hasenov: well then follow imirkin :)
15:33 hasenov: does that mean I need to install a new package, xf86-video-modesetting?
15:33 hasenov: instead of xf86-video-nouveau?
15:33 tobijk: right
15:33 hasenov: and forget the whole compilation from source business?
15:34 imirkin: hasenov: well, you still need an up-to-date kernel or kernel module
15:34 pmoreau: imirkin: Ok. Maybe I could try to help debugging that, but I'll first to have to investigate to lock up when switching from igd to dynoff dis, so that I can later push the v2 of my patches.
15:34 imirkin: hasenov: either 4.1-rcN, or the module built from the tree that you have.
15:35 imirkin: pmoreau: still have to do the pci reset? or do your patches solve that?
15:35 tobijk: hasenov: well you need a compatible one to the X servers abi you are running
15:35 imirkin: pmoreau: it's semi-likely you're meant to execute some vbios script when switching
15:35 pmoreau: imirkin: Still have to: I can't do anything involving the G96 without PCI-resetting it.
15:36 pmoreau: I always load with config=NvForcePost=1, but I guess you're not talking about those scripts, right?
15:37 imirkin: pmoreau: the nice thing about scripts
15:37 imirkin: is that there are so many to choose from
15:37 pmoreau: :D
15:37 hasenov: lol, my package manager does not seem to have xf86-video-modesetting in its repository, maybe I should just run as root in Xorg
15:37 imirkin: hasenov: it comes as part of X now
15:38 imirkin: hasenov: if you have X 1.17 or later
15:38 imirkin: (maybe it was even integrated into 1.16? i forget)
15:38 hasenov: imirkin: how do I switch, in Xorg.conf file?
15:38 pmoreau: imirkin: I'll do some more testing, like powering the G96 back on and then try to switch. But that will be for tomorrow :-)
15:38 imirkin: hasenov: just use an empty xorg.conf file and remove xf86-video-nouveau
15:38 pmoreau: See you!
15:38 imirkin: pmoreau: fyi, the original line is about standards :)
15:39 imirkin: grrr. and naturally fermi doesn't have that stupid tess $invoc shift/unshift thing.
15:39 pmoreau: imirkin: Which original line are you talking about?
15:39 imirkin: pmoreau: the nice thing about *standards* is that there are so many to choose from
15:39 pmoreau: Ah! Not scripts, ok :)
15:40 pmoreau: Well, the more the merrier!
15:40 hasenov: imirkin: sorry imirkin, remove xf86-video-nouveau from where?
15:41 imirkin: hasenov: your computer :)
15:41 hasenov: oh the actual package u mean
15:41 imirkin: yeah, that's really the easiest thing
15:42 imirkin: you could also force modesetting using an xorg.conf, but... meh
15:44 hasenov: okay, i have Driver "nouveau" in Xorg set
15:44 hasenov: should I comment it out?
15:45 hasenov: or should it try to load the nouveau driver?
15:45 hasenov: it says it cannot find the driver
15:45 imirkin: hasenov: you should just not have any xorg.conf driver stuff
15:45 imirkin: it will autoload modesetting
15:49 hasenov: so I generated new xorg with "Xorg :0 -configure"
15:50 imirkin: you don't need an xorg.conf at all
15:50 imirkin: having one is actively hurting you
15:50 hasenov: oh, i tried that
15:50 imirkin: pastebin xorg log from when you do that
15:50 hasenov: did not get me anywhere
15:50 imirkin: and we can move on from there
15:53 hasenov: http://www.pastebin.ca/3010947
15:54 hasenov: my Xorg log
15:54 hasenov: with no xorg.conf set in /etc/X11
15:54 imirkin: that looks great
15:54 imirkin: what was wrong with that?
15:55 imirkin: oh wait
15:55 imirkin: (EE) modeset(0): glamor initialization failed
15:55 imirkin: EGL_MESA_drm_image required
15:56 imirkin: hasenov: do you have 'eglinfo' installed?
15:56 hasenov: I saw that before but could not make sense of it
15:57 hasenov: no, I can try installing it
15:57 imirkin: it's part of the mesa demos
15:57 imirkin: although most distros don't end up installing it
15:57 imirkin: anyways
15:57 imirkin: i'm guessing that your libEGL is somehow messed up
15:57 imirkin: perhaps left over from a blob install?
15:58 imirkin: also can you check that you have a nouveau_drv.so somewhere? like /usr/lib64/dri ?
15:58 hasenov: i did a whole bunch of things to get X11 to work
15:58 hasenov: not sure what that touched
15:59 imirkin: anyways, modesetting without glamor should still work... it should just be super-slow
15:59 imirkin: is that what you were seeing?
16:00 hasenov: well, i am seeing it start to come up and goes black for a second but then gives up and goes back to the command prompt
16:01 imirkin: well, it seems to just exit on its own
16:01 imirkin: you probably don't have a xinitrc configured
16:01 imirkin: have you used 'startx' before?
16:01 imirkin: it's not a particularly intuitive way of using X
16:03 hasenov: I thought that if no xinitrc is present, the default in /etc/X11/xinit is called
16:04 hasenov: okay, I guess I was wrong
16:05 hasenov: oh no, I do have xinitrc
16:05 hasenov: in home dir
16:05 hasenov: ahh
16:06 hasenov: I accidentally ran startx from root and it worked and I got excited
16:06 tobijk: hasenov: the default is indeed used if you dont have one in your home dir :>
16:08 hasenov: the xinitrc file that was there does not work, however the one from /etc/X11/xinit works
16:09 hasenov: I just copied it over, I guess thats why on root it works but when used by home it doesnt
16:11 hasenov: so am I on the right track now? I am using my own nouveau driver i built using the special darktama branch
16:11 hasenov: and the nouveau driver actually shows up from lsmod
16:12 hasenov: but I do not have xf86-video-nouveau installed that is supplied by my package management
16:12 hasenov: can I safely unload "nouveau" that I built from source or will it mess everything up?
16:13 imirkin: hasenov: it will mess everything up
16:13 imirkin: xf86-video-nouveau has nothing to do with the nouveau module that you built
16:14 imirkin: they're entirely different things
16:14 imirkin: make sure you're in the video group so that you can access the render nodes
16:14 hasenov: also, I think that was the issue I was having originally, I can try reverting to not using modesetting and install xf86-video-nouveau
16:14 imirkin: no. you want modesetting.
16:14 imirkin: you don't want xf86-video-nouveau.
16:14 hasenov: imirkin: okay
16:14 imirkin: it just won't work well with maxwell
16:15 imirkin: (actually it'll work very poorly. whereas modesetting will work correctly and as intended.)
16:15 hasenov: right, I was able to start without modesetting from root user, trying to figure out which way to run is better
16:16 hasenov: i gotcha though, I will leave it as is
16:17 imirkin: normally X starts as root, via gdm or something
16:17 hasenov: question though, does modesetting allow for multiple monitors?
16:17 imirkin: however if you're in the video group, i _think_ you should be able to do it yourself
16:17 imirkin: yeah
16:17 imirkin: modesetting is what you want. trust me.
16:18 hasenov: I added user to video group already
16:18 imirkin: the nouveau ddx should just outright reject maxwell cards. but it doesn't and limps along with its broken glamor integration.
16:18 imirkin: did you log out/log back in?
16:18 imirkin: otherwise the group setting won't take effect
16:18 imirkin: you might literally have to be root to open the non-render node though and use KMS
16:19 imirkin: i forget how it works
16:19 hasenov: well, I did that way earlier back when tobijk was helping me
16:19 whompy: imirkin: all this talk about in-tree -modesetting has me curious; Is it a good option for older asics too?
16:19 whompy: I haven't really followed how well it behaves on nouveau outside Maxwell chips.
16:19 imirkin: whompy: depends who you ask. if you ask me, no. i don't trust glamor. it uses my shitty gl driver code ;)
16:20 whompy: always good to look at your own stuff with a grain of salt.;)
16:20 imirkin: whompy: i have an EXA support patch that's been 98% ready for the past... 6-12 months
16:21 whompy: Fine by me. Saves me from the hassle of building xserver from git. Too lazy to add that to the mix right now.
16:21 imirkin: whompy: although apparently some things go faster. but glamor on e.g. nv3x/nv4x would be disastrous.
16:22 whompy: I'd imagine so. Unrelated, but does it work on freedreno yet?
16:22 imirkin: mmmmmmmaybe? you should ask rob
16:23 imirkin: i just fix piglits :)
16:24 hasenov: i ran startx again, and am getting the same error on glamor initilization failed
16:24 imirkin: there's something screwy in your permission or library setup then
16:26 hasenov: oh okay, looks like I will give up for now, so far achieved success in able to run Xorg from regular user
16:26 hasenov: thank you imirkin i appreciate your time
16:33 dardevelin: imirkin, ping
16:33 imirkin: dardevelin: pong
16:37 dardevelin: imirkin, so i ended buying that laptop
16:37 imirkin: ok
16:37 imirkin: i think you overestimate my memory skills
16:37 imirkin: assume i have none and go from there :)
16:38 tobijk: meh time to invent direct brain to database access :>
16:38 imirkin: i swap things out, but unfortunately /dev/null is my swap device
16:39 tobijk: same here :D
16:39 imirkin: tobijk: are you going to be around for a little bit?
16:40 tobijk: not _that_ long today, whats up?
16:40 dardevelin: imirkin, sorry a leak got me into swapping and I was trying to reply but of course no possible
16:40 imirkin: tobijk: i was hoping i could get you to run some tests on your GK107
16:40 tobijk: imirkin: yeah sure
16:40 dardevelin: imirkin, alright so here it goes. it's currently using intel one which is fine. but you said that bumblebee should help/work fine
16:40 dardevelin: what was the command you wanted me to run on the machine for you to be sure ?
16:41 imirkin: tobijk: grab my gl4-integration-2 branch and build that
16:41 tobijk: @github?
16:41 tobijk: yep, found it
16:41 imirkin: tobijk: then run ./tests/spec/arb_tessellation_shader/execution/quads.shader_test and (a) let me know if you get out-of-bounds errors, and (b) if it renders properly
16:41 dardevelin: imirkin, i mean to know info about the 'card'
16:42 dardevelin: sorry if I am looking like impatient. Just excited
16:42 imirkin: dardevelin: i'm a bit hazy on what you're trying to achieve
16:43 dardevelin: imirkin, well making use of the max potential i can with the machine with little recourse to proprietary software. just trying to access which steps I should follow as I think currently the nvidia card is not being used
16:43 imirkin: dardevelin: if all you want to do is for the card to suspend, you could just load nouveau. it should suspend your card just fine.
16:43 imirkin: [assuming that nouveau loads]
16:44 imirkin: bumblebee can also be used to do this, but tbh i've never actually used bumblebee
16:44 imirkin: there's also a fairly user-unfriendly way of doing it which involves manually sending acpi calls
16:44 imirkin: if nouveau loads and you see DynOff in vgaswitcheroo/status, then that's really the simplest thing
16:44 imirkin: i'll bbiab
16:44 dardevelin: I think it does load. I installed debian uefi and. just added wifi and realtek firmware once it was up and running
16:47 dardevelin: asus n551jk cn220h is the machine : lspci to list all devices right ?
16:48 dardevelin: http://paste.zfg.pw/p3qftib1z
16:51 tobijk: git fetch imirkin <- sounds about right :D
16:53 imirkin: dardevelin: http://nouveau.freedesktop.org/wiki/Optimus/
16:53 imirkin: fyi you don't have a mux
16:54 imirkin: dardevelin: the main bits i'm pointing at are looking at the switcheroo status
16:56 tobijk: imirkin: see for yourself, i guess this is a bit wrong: https://homepages.thm.de/~tjkl80/tess.png
16:57 imirkin: yep
16:57 imirkin: do you see mem_out_of_bounds errors?
16:57 imirkin: (in dmesg)
16:57 tobijk: right, i do
16:58 tobijk: http://hastebin.com/qipotalapo.md
16:58 imirkin: excellent
16:58 tobijk: not enough registers? or else?
16:59 imirkin: i'm gonna have a patch in like 10 mins
16:59 tobijk: np, i'll be here for ~1h
17:11 imirkin: tobijk: http://hastebin.com/bujejoqome.coffee
17:11 imirkin: tobijk: i can't get nouveau_compiler to cooperate, so can you also provide me with the NV50_PROG_DEBUG=1 output for that?
17:12 tobijk: yep
17:16 tobijk: different but still oob and rendering problems :/
17:17 imirkin: hmmmm
17:18 imirkin: the differnet is expected, the corruption is random
17:18 imirkin: ok
17:18 imirkin: let's try another one...
17:18 tobijk: you still want the output?
17:19 imirkin: er yea
17:19 imirkin: just in case i messed up
17:20 tobijk: imirkin:
17:21 tobijk: argh where di my ctrl+c go
17:21 tobijk: http://hastebin.com/odocixejec.mel
17:23 imirkin: tobijk: alternate patch: http://hastebin.com/fesubijiso.coffee
17:25 tobijk: imirkin: still oob and render corruption
17:26 imirkin: bleh
17:26 imirkin: but it was such a good idea!
17:27 tobijk: maybe the last one before this was better, it startet with just MEM_OUT_OF_BOUNDS instead of MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
17:27 tobijk: but kooking at my dmesg again, this may have been just luck
17:28 imirkin: nah, those are the same
17:40 imirkin: joi: added some nvd9 traces which should demonstrate the need for that gf100 variant
17:42 imirkin: tobijk: well, thanks for testing
17:43 tobijk: no problem, if you got more, let me know i'm glad to help
17:44 tobijk: going to bed, gn8
23:35 RSpliet: skeggsb: ping, have you had the opportunity to look at the NVA0 reclocking patches I shoved to the ML?
23:36 skeggsb: RSpliet: hey, i've looked over the series quite a while back, but not this version yet
23:36 skeggsb: i'll likely do a quick sanity-check and just merge them, assuming there's no pending comments on the ml that need to be addressed
23:37 RSpliet: I don't think there are any unresolved issues... although I talked about one or two on IRC instead of on the ML
23:37 RSpliet: more importantly I was hoping for testers... but I guess NVA0 is simply too old :-P
23:39 mupuf: RSpliet: that is indeed a possibility, but the most likely one is that the nva0 was expensive!