02:38AndrewR: imirkin, this is ..interesting. Old mesa (11.1.4) can be compiled against new libdrm, and glxgears works. But xvmc failed with xvmc_bench: nouveau_buffer.c:691: nouveau_buffer_create: Assertion `buffer->domain' failed.
02:39AndrewR: imirkin, and at the same time I already can see some ers in dmesg (on kernel 4.2)
02:40AndrewR: imirkin, nouveau E[ PMPEG][0000:01:00.0] ch 4 [xvmc_bench] 0x01000000 0x00000010 0x00000190 0x00004000
02:40AndrewR: imirkin, my guess old interface between libdrm and xvmc (for this old hw) somewhat broken ....
02:41imirkin: that buffer->domain assert sounds familiar... i think that was a mesa bug i introduced at one point or another
02:43AndrewR: imirkin, I'll try to compile next stable branch (11.2, where whole new libdrm conversion landed) and see how it will fare ..
02:44AndrewR: https://lists.freedesktop.org/archives/nouveau/2015-December/023591.html - this patch was probably dropped, and you fixed mesa independently in mid-2016 ...
02:47imirkin: i'd recommend previous stable ;) like ... 10.3 or something.
02:47imirkin: AndrewR: that's a separate issue than what's happening
02:47imirkin: it has to do with the fact that the old code was buggy-but-worked-anyways
02:48imirkin: and newer kernel clamped down on it a bit
03:03AndrewR: imirkin, then it will be interesting to learn what exactly broke ...
03:10imirkin: basically in the nv50 and nvc0 code, we were selecting the wrong class. the old kernel would allow that, but newer kernels clamped down on that behavior. however the nouveau_video.c is definitely picking the right class - NV31_MPEG for pre-g84, and G82_MPEG for g84+
03:12AndrewR: imirkin, still, I'm not sure about this whole stuff with libdrm. It seems to emulate both new and old interface for mesa, but does it translate new mesa to old (pre 4.3) kernel?
03:13imirkin: it should.
03:13imirkin: perhaps skeggsb would have some better ideas off the top of his head
03:13AndrewR: I think no...but may be I used too old mesa / libdrm snapshot when I tried to test 4.2 kern + mid-2006 mesa/drm on some kepler card..it failed to create decoders despite firmware files put into lib/firmware ...
03:14imirkin: ok ... could have been some specific bug given your exact software combo
03:14imirkin: in general it should work ;)
03:16AndrewR: imirkin, thanks ... I think i'll try to turn on more debug via module param for new kern (4.10) and look at errs
03:16AndrewR: I prefer to move forward :}
03:22AndrewR: imirkin, I think there was env. variable for turning on more libdrm_nouveau debug msgs at runtime ....
03:22imirkin: yeah, that sounds familiar, although i never use it
03:26AndrewR: imirkin, NOUVEAU_LIBDRM_DEBUG=1
03:34AndrewR: imirkin, also, because xvmc tied to textured video, and this one comes from ddx, and ddx compiled against new libdrm...hm..I need to recompile it too, while it will not fix kern issue
03:36imirkin: the ABI didn't change iirc
03:40AndrewR: imirkin, well, it still works as in displays stuff via xv, and regular x (EXA) so..it can use 3d, definitely. But...may be something broke exactly at interaction between those two classes (pmpeg and others), but I don't have my new machine to retest with nv92.
03:42imirkin: no worries
11:27mupuf: how about giving Echelon9 commits right on envytools?
11:35mwk: mupuf: go for it
11:39mwk: ok, great
11:39mwk: gl hf
11:39mupuf: same to you ;)
11:40mwk: cheers from Japan :)
11:40mwk:is going back to Poland tomorrow, through Helsinki
11:40mwk: wish I had some time there..
11:50mupuf: next time!
11:51mupuf: I may actually consider coming back to your home city ... for a concert of Riverside!
13:32Echelon9: @mupuf @mwk: thanks, accepted
15:41Shred00: i'm starting to get display artifacts and outright hangs with latest nouveau/kernel. there's messages in dmesg about it too. here's everything matching "nouveau" from dmesg: http://brian.interlinx.bc.ca/nouveau-errors
15:41Shred00: there seem to be lots of
15:41Shred00: Jan 29 10:35:33 laptop kernel: nouveau 0000:05:00.0: fb: trapped write at 0100800000 on channel -1 [0fee0000 unknown] engine 06 [BAR] client 0a [TEXTURE] subclient 01 [IN] reason 00000002 [PAGE_NOT_PRESENT]
15:41Shred00: with some:
15:41Shred00: Jan 29 10:35:34 laptop kernel: nouveau 0000:05:00.0: disp: ERROR 7 [INVALID_HANDLE] 00  chid 0 mthd 0874 data ffff007a
15:43imirkin: Shred00: did you only update the kernel, or anything else as well?
15:43Shred00: i'm not convinced it's related to a kernel update. i can't specifically correlate it starting to happen the day a kernel was updated for example.
15:45imirkin: the fact that the channel is unknown is quite odd.
15:46imirkin: any particular reason you're using a custom vbios?
15:48imirkin: [not that it matters, you haven't suspended, so the card init came from the onboard vbios run during boot]
15:51Shred00: custom vbios was for some errors i was getting with nouveau previously. probably a few years at this point.
15:52Shred00: May 24 2014 is the date on it.
15:54Shred00: you helped me with that. :-) https://people.freedesktop.org/~cbrill/dri-log/?channel=nouveau&date=2014-05-24
15:56imirkin: hm. of course i don't say *how* i determined that magical fixup...
15:57imirkin: well, wtvr
15:57imirkin: i'd recommend trying to find a working software arrangement. if you can't, consider the possibility that the lifetime of hw isn't infinite.
15:58imirkin: esp the G86 times involved bad solder joints
15:58imirkin: and those GPUs tend to run really hot on top of that.
15:58imirkin: not saying that's necessarily what's happening, but something to keep in the back of your head
15:59Shred00: shit-on-a-stick. one of the reasons i hate laptops. one bad thing and the rest is junk too.
15:59Shred00: is there any way to be more sure it is hardware?
16:00Shred00: since this is a many hundreds of dollars replacement rather than just fifty or so for a new video card.
16:01Shred00: there's even artifacts in the grub menu. :-(
16:14Shred00: nothing else we can test/do to be sure it's a hardware problem? granted that the video starts to go flaky even at grub time is a smoking gun.
16:21Tom^: i had two g86 die on me, and that was at the time those actually were the top notch cards
16:21Tom^: silly solder joints :(
16:21Tom^: both lived at most 1 year
16:21Tom^: Shred00: but why not try boot up an old windows xp install? :D
16:24imirkin_: Shred00: before ditching the laptop entirely, you can try the toaster oven approach
16:24imirkin_: some people have gotten good mileage out of that one.
16:24Shred00: is that what i think it is?
16:24imirkin_: pretty much.
16:24imirkin_: poor man's flow soldering technique ;)
16:25imirkin_: [if you have access to a real flow soldering setup, use that one ;) ]
16:25karolherbst: imirkin_: how should it be done? 2 hours at 200°C?
16:25nyef: I wouldn't want to do the toaster oven thing with a toaster oven that has been/will be used for food. Even if it's RoHS hardware, there's a good chance of *something* coming off the board that wouldn't be fun in food.
16:25imirkin_: lol no
16:25imirkin_: nyef: but silicon tastes so gooood
16:26imirkin_: or more to the point, PVC :)
16:26nyef: imirkin_: Right. And some of the materials used to glue FR4 sheets together, as well.
16:28imirkin_: i remember the laser cutter training pretty well. "UNDER NO CIRCUMSTANCES ARE YOU TO CUT PVC" :)
16:28karolherbst: sentences like that are only for the weak
16:28imirkin_: ... and those who like to live.
16:28imirkin_: a cholrine-gas-free life
16:29nyef: Right, vinyline gas is lethal. (-:
16:29karolherbst: as I said: for the weak
16:30nyef: I have some hardware that could do with a good reflow, though I'm hoping it's not BGA hardware that needs reballing.
16:30imirkin_: is it the V that kills? i thought it was the C...
16:30nyef: Maybe it's the P that kills?
16:33imirkin_: Vinyl chloride is a gas with a sweet odor.
16:45nyef: Mono-Vinyl Chloride? MVC? Where have I seen that acronym before?
17:15Tom^: i wonder if you cant google some bad points where the solder usually died
17:15Tom^: i mean it was quite normal on those boards, and simply check them out and resolder
17:15Tom^: fun tinkering :)
17:55mupuf: Echelon9: you're welcome ;)
22:36MarcinWieczorek: Hey mwk
22:37MarcinWieczorek: I'd like to report poor performance with CS:GO, is there anything I can do to help?
22:42karolherbst: MarcinWieczorek: figure out why it is slow, that would help
22:43karolherbst: there are some counters exposed through GALLIUM_HUD which might hep
22:43imirkin: MarcinWieczorek: you reclocked your gpu to max speed right?
22:43karolherbst: but usually we are as clueless as everybody else
22:43karolherbst: imirkin: csgo has terrible perf with nouveau
22:43karolherbst: well "terrible"
22:43imirkin: karolherbst: ah ok. didn't realize that.
22:43karolherbst: it ain't that bad, but it's around 60-70% I think
22:44imirkin: hakzsam: hey, do you remember why we put LateAlgebraicOpt where we did? do you think it'd suffer if we put it after LoadPropagation + IndirectPropagation?
22:51MarcinWieczorek: imirkin: I have not done anything with the gpu
22:52imirkin: MarcinWieczorek: remind me which gpu you have?
22:54MarcinWieczorek: GTX 750 Ti
22:54MarcinWieczorek: 4.9.6 with -git driver
22:55imirkin: you want to grab 4.10-rc
22:56imirkin: which will allow you to reclock it, which should get you an extra 10x or so
22:58MarcinWieczorek: The GPU sounds like a jet already. The performance on lowest details is not acceptable. It's hard to aim
22:58MarcinWieczorek: Overclocking it doesn't seem like a solution
22:59imirkin: i don't think anyone's suggesting overclocking
23:00imirkin: i'm suggesting making it go from the boot clocks, which can be as low as 50mhz, to the max clocks, which can be in the 1ghz range for shaders. ram speeds are obviously also very important.
23:01imirkin: starting with tesla, nvidia provides multiple perf levels, and reclocking is the mechanism to switch between them
23:02MarcinWieczorek: The sad thing is that I have no clue what it does mean
23:02imirkin: starting with kepler or so, gpu's boot to the lowest perf level. fermi tended to boot to a middle or lowest perf level depending on the board, tesla was kind of all over.
23:03imirkin: ok, well, you know how (modern) CPUs have adjustable frequencies?
23:03imirkin: well, GPUs do too
23:04imirkin: tbh i'm not 100% sure on the CPU details, but your GPU is booting into its lowest frequency
23:04imirkin: reclocking, at a high level, is the act of changing between such frequencies.
23:04MarcinWieczorek: Isn't that automatic?
23:04imirkin: with CPUs, the ratio between highest and lowest is about 3x. with GPUs the ratio is much greator.
23:04imirkin: no, it is not.
23:05imirkin: and with kernel 4.10, it is still not automatic. but at least you can do it.
23:05imirkin: while with earlier kernels, there's just no support for it at all for your gpu.
23:05MarcinWieczorek: ok. Why do nvidia drivers give me the performance I need and nouveau does not?
23:05imirkin: because nvidia drivers reclock automatically
23:06imirkin: turns out that having access to hw docs makes it easier to implement functionality. odd, right?
23:06MarcinWieczorek: Yeah and we don't have hw docs
23:06MarcinWieczorek: Do we?
23:06karolherbst: we don't
23:06imirkin: no for the important bits
23:06MarcinWieczorek: But the kernel can reclock the GPU, and we know the kernel's source
23:07imirkin: the nvidia kernel driver is closed
23:07MarcinWieczorek: I know, it's not that easy :P
23:07imirkin: the open part of it is just a shim. the majority of it is in a pre-compiled nv-kernel.o blob
23:08imirkin: but we can trace it and so on
23:08imirkin: however memory is extremely finicky - proper procedure varies from board to board
23:08MarcinWieczorek: Really? You mean that in nouveau some parts are still closed?
23:08imirkin: no, nouveau is all open
23:08imirkin: perhaps i misunderstood what you said
23:08MarcinWieczorek: I don't mean that
23:09MarcinWieczorek: Does nouveau replace that closed blob?
23:09imirkin: nouveau is a separate driver
23:09MarcinWieczorek: So we can have nouveau and 4.10 kernel and reclock then?
23:09imirkin: a separate kernel module, that is.
23:09imirkin: which is why i'm suggesting you grab kernel 4.10
23:10imirkin: by echo'ing stuff into /sys/kernel/debug/dri/.../pstate
23:11orbea: i use this function to make it easier personally http://dpaste.com/070HZDH
23:11imirkin: [note that the exact perf levels vary from gpu to gpu]
23:13MarcinWieczorek: Ok. So I just echo a value and my GPU reclocks itself
23:13MarcinWieczorek: Can we do that automaticaly based on the load?
23:15imirkin: every time you reclock, there's a small probability that the gpu will hang
23:15imirkin: so we're taking things easy for now wrt automatic stuff
23:15nyef: The next step in the reclocking dance is probably to enable automatic reclocking... as a (non-default) option, so that the adventurous souls can give it a good test without the more risk-averse pitching a fit.
23:16imirkin: karol has a preliminary patchset to enable dynamic reclocking though.
23:16karolherbst: nyef: there is more
23:16karolherbst: I should finish it at some point
23:16karolherbst: automatic pstate selection was still missing, because I didn't know how to cpmute the memory load back then
23:18imirkin: MarcinWieczorek: long story short, try kernel 4.10. when you reclock, you should be able to get about 60-80% of blob speed, depending on the game.
23:23MarcinWieczorek: Where can I find additional information on reclocking? I don't know how to adjunst the frequency to the needs
23:24imirkin: MarcinWieczorek: just echo values into that file. cat the file to see the list of legal values.
23:24imirkin: [look at orbea's script]
23:25MarcinWieczorek: What's the exact path?
23:25MarcinWieczorek: To the pstate file I mean
23:25imirkin: look at the link orbea pasted above.
23:25karolherbst: imirkin: there is no path ;)
23:26MarcinWieczorek: he used a variable
23:26imirkin: oh heh
23:26MarcinWieczorek: Can I reclock on NVIDIA drivers this wa?
23:27MarcinWieczorek: Ok that file does not exist but probably because I have an older kernel
23:27karolherbst: or debugfs isn't mounted
23:27karolherbst: or because you didn't try as root
23:28MarcinWieczorek: clients gem_names name
23:28karolherbst: MarcinWieczorek: is this a laptop?
23:28imirkin: the pstate file should be there... i think. you have a 4.5 or later kernel right?
23:28imirkin: is there a /1/... directory?
23:28MarcinWieczorek: 0 and 128 only
23:28karolherbst: no 64?
23:29imirkin: the control nodes were removed
23:29karolherbst: I have all three
23:29MarcinWieczorek: I'm on NVIDIA driver now btw. Does that matter?
23:29karolherbst: well I am on 4.9, so maybe the nodes got removed in 4.10
23:29imirkin: karolherbst: i don't remember...
23:32MarcinWieczorek: If only there was a 4.10 package somewhere in the repository
23:32imirkin: all in good time. 4.10's not release yet. there are RC's though.
23:32MarcinWieczorek: I know
23:33MarcinWieczorek: from 40 minutes ago
23:36MarcinWieczorek: Ok I'll compile 4.10-rc6 tomorrow
23:37MarcinWieczorek: I'm going to be sleeping in 70 minutes :)
23:50MarcinWieczorek: Thank you guys for help, I'll come back with feedback soon