00:03 karolherbst: imirkin: ohh do I have to use the config module parameter for stuff inside nvkm?
00:04 imirkin: for those helpers to work, yea
00:11 karolherbst: okay
00:11 karolherbst: I slowly understand how that works now :D
00:14 imirkin: skeggsb_: hmmmm... it looks like nouveau_pushbuf_space() can call ->kick_notify() before updating push->cur. is that expected?
00:17 karolherbst: imirkin: I think I ignore perf modes like powersave, performance for now, allthough it is pretty easy to add support for them. The algo just need to be more safe or more aggressive before downclocking
00:39 imirkin: skeggsb_: if you're around, would really appreciate some thoughts on this :)
01:14 karolherbst: imirkin: what is the way with the smallest latency to read multiple regs out in the kernel?
02:04 pmoreau: qq[IrcCity]: IIRC, you are the one having *some* troubles with a 8600 GTS (rev a1)?
02:05 pmoreau: qq[IrcCity]: If so, could you please give me the output of `nvapeek 0x8807c`?
02:07 qq[IrcCity]: one minute.
02:07 pmoreau: Sure, no hurry :-)
02:08 qq[IrcCity]: pmoreau, what should I install for nvapeek?
02:08 pmoreau: envytools
02:08 pmoreau: https://github.com/envytools/envytools
02:09 pmoreau: If you are running Arch, there is an AUR package
02:19 karolherbst: ohh pmu is gt215+, right, what was used before that?
02:21 neoraider: Ah, I found a clue regarding my tearing issues: whenever a GL or VA-API application is running on the reverse PRIME screen, my kernel logs gets spammed with "[drm:drm_wait_vblank [drm]] *ERROR* Unsupported type value 0x9d, supported mask 0x7400003f" messages.
02:21 neoraider: Does anyone here have an idea about that?
02:22 neoraider: Occurs with both Kernel 4.2.2 and the HEAD of http://cgit.freedesktop.org/nouveau/linux-2.6/?h=linux-4.3
02:26 qq[IrcCity]: pmoreau, 0008807c: 012c84e0
02:27 pmoreau: qq[IrcCity]: And for 0x88080?
02:28 pmoreau: (Are those the default values: you didn't load Nouveau nor the blob before taking them?)
02:33 qq[IrcCity]: pmoreau: all modules are loaded and run. do you mean to start the system without nouveau?
02:34 qq[IrcCity]: all modules pertaining to FOSS drivers.
02:34 pmoreau: If it's with Nouveau, it should be fine as it shouldn't enable some flag I'm looking for, while the blob would. :-)
02:35 pmoreau: Could you give me the output of `nvapeek 0x88080` as well please?
02:36 qq[IrcCity]: 00088080: 00002900
02:36 qq[IrcCity]: not the active nouveau is from people.freedesktop.org/~darktama/
02:36 qq[IrcCity]: note
02:37 qq[IrcCity]: I didn’t load proprietary drivers for months.
02:37 pmoreau: :-( The EXT_TAG flag is enabled by default it seems, so that's not the issue.
02:38 pmoreau: FYI, there is an open bug report about a 8600 GTS (rev a2): https://bugs.freedesktop.org/show_bug.cgi?id=82714
02:42 qq[IrcCity]: pmoreau: quelques conditions très spécifiques.
02:42 pmoreau: Certes
02:43 pmoreau: qq[IrcCity]: Did you try to mmiotrace the binary driver and figure out what it does differently from Nouveau?
02:45 pmoreau: This is probably your best bet at getting this problem fixed, as it seems quite card specific (maybe the VBIOS doesn't perform the same init as all other VBIOSes out there for that card?).
02:45 pmoreau: It doesn't mean you won't be helped
02:46 qq[IrcCity]: the binary driver = the one from Nvidia? no, didn’t investigate anything at all, after it hung the entire system dead (not only its console).
02:46 pmoreau: Sorry, got to go. bbl
02:46 pmoreau: Yes, exactly
02:49 qq[IrcCity]: so, there is a suggestion that config=NvForcePost=1 fails at 8600 GTS because of some software malfunction?
02:52 qq[IrcCity]: certainly I saw how UEFI revived my 8600 GTS during a software (not reset!) reboot.
02:54 qq[IrcCity]: if it’s a software malfunction, then such one that doesn’t manifest during pre-boot operations.
03:12 karolherbst: qq[IrcCity]: yeah, but nobody is able to figure that out as long as you don't trace the prop driver ;)
03:13 qq[IrcCity]: karolherbst: what is an equivalent of config=NvForcePost=1 for Nvidia’s driver? or it runs the stuff unconditionally?
03:15 karolherbst: just trace the prop driver
03:17 karolherbst: usually the driver takes care of everything itself
03:18 karolherbst: qq[IrcCity]: do you know if NvForcePost=1 is fine after with a cold boot?
03:22 qq[IrcCity]: I never saw a usable result after NvForcePost=1. once it produced a kind of signal (with TUI console), but VTs won’t work and anything console-related. other tries resulted in either no signal or unusable signal (but the system ran).
03:23 karolherbst: are you sure it also did this after a cold boot?
03:27 qq[IrcCity]: «cold» boot = actual cold start? unlikely ever tested this condition, but saw it after reset button.
03:45 ratherDIfficult: hi boyz and gurls, what format is the cubin cuda object code in, is that a format for card specific object code or some intermediate representation?
04:41 karolherbst: imirkin: okay, found another issue in another game (Interstellar Marines). Some type of transparent effect, which is just black with mesa and works with the prop nvidia driver :/
04:53 ratherDIfficult: karolherbst: do i understand right that cubin binary files are as close to real underlying hardware as possible?
06:09 qq[IrcCity]: pmoreau: «0008807c: 012c84e0», «00088080: 00002900» after a cold start without loading nouveau proper. the same as with nouveau.
06:13 pmoreau: qq[IrcCity]: Yeah, so the EXT_TAG is enable by default. So my patch enabling it on hardware which supports it is not going to help you.
06:13 pmoreau: Thanks for checking!
06:18 qq[IrcCity]: karolherbst: insmod nouveau config=NvForcePost indeed loads after a cold start (without garbling the console), but refuses to work either. possibly I botched something in dependencies.
06:18 karolherbst: yeah, then posting is not the issue
06:19 karolherbst: there is something in the init routines messed up compared to the blob
06:19 karolherbst: so have to trace the blob
06:19 karolherbst: *you
06:20 karolherbst: the blob does something nouveau does not, and only the trace can show this
06:32 ratherDIfficult: https://eprint.iacr.org/2012/137 .. cubin probably does not map to hardware overly much still
06:49 qq[IrcCity]: karolherbst: «dpkg-reconfigure nvidia-304» f⋯ removed all binaries for Linux 3.16, but failed to build anything for Linux 4.3.
06:51 karolherbst: 304 is too old
06:52 karolherbst: I even doubt that 355.11 will build against 4.3
06:52 karolherbst: but there may be some patches around
06:54 pmoreau: For Tesla, you should use 340.xx
07:36 ratherDIfficult: basically those folks say that nvidia's software is entire crap, never imagined this thing RSpliet see i was wrong about scheduling, i rather thought its called register allocator that lifts perf, but yeah lots call it scheduler as well, the scheduler i described does something else
07:37 ratherDIfficult: but yeah this cudasm stuff is not available for my kepler card that i got today, it supports sm2 level only, it raises cryptograhical computations well yeah magically
07:38 ratherDIfficult: it should mine faster then say the most powerful rigs, when code is scheduled correctly
07:41 pmoreau: ratherDIfficult: You could be interested by this https://github.com/NervanaSystems/maxas/wiki/Introduction. It's for Maxwell cards, but he references some similar projects for Kepler.
07:49 karolherbst: pmoreau: so they do instruction sceduling for maxwell?
07:51 ratherDIfficult: pmoreau: interesting thanks, well thanks, i read my previous pdf, karloherbst: correct question i have not yet looked if from that qhasm-cudasm pdf there is ome code on the web, then their stuff could be integrated to assemblers
07:52 karolherbst: perl is really horrible :D
07:52 pmoreau: karolherbst: There is a basic scheduler (item 2.)
07:53 karolherbst: yeah I know, I try to find the important parts in the code
07:53 pmoreau: :-)
07:53 karolherbst: but the code is perl and perl... well either you wrote it or you can't understand what's going on :D
07:54 karolherbst: especially stuff like this: my $latency = $src =~ m'^P\d' ? 13 : $parent->{lat};
07:54 karolherbst: ....
07:54 pmoreau: I only read the Introduction text, and a quick look at the SGEMM one (which looks pretty cool).
07:54 pmoreau: Meh... Is it some kind of regexp thingy the "m'^P\d'"?
07:54 karolherbst: yeah
07:55 karolherbst: perl is just horrible... I totally understand why a lot of people are flaming against it. If you don't know perl you really can't understand it
07:56 karolherbst: okay, but I basically understand how they order
07:56 karolherbst: in fact it is pretty simple
07:57 karolherbst: but this algorithm is so generic, that well
07:58 pmoreau: It's a basic one ;)
07:58 karolherbst: yeah
07:58 karolherbst: maybe the best thing todo when you don't know anything is, is to reduce register usage
07:59 karolherbst: because whatever you do, as long as you guess, you don't know which order is in fact faster
08:05 ratherDIfficult: guys did you find some scheduler code, or what were you talking about?
08:06 pmoreau: The GitHub repo I linked to includes a basic scheduler
08:07 karolherbst: and another game with a graphical issue with nouveau :D
08:07 karolherbst: I am good at finding those
08:08 ratherDIfficult: i bought whole new computer, but have not installed software on it yet
08:09 pmoreau: karolherbst: But are those issues with games or with Nouveau? :-)
08:09 karolherbst: well it works with intel
08:10 karolherbst: okay
08:11 karolherbst: what is wrong, if a trace doesn't replace without issues on intel, but starting the game with intel does work correctly
08:11 karolherbst: gl extension issue?
08:12 karolherbst: pmoreau: mhhh replaying the intel trace on nouveau doesn't show any issues
08:12 pmoreau: Interesting..
08:12 karolherbst: will try to find which extension is causing this
08:12 pmoreau: And using the Nouveau trace on Intel does have issues?
08:13 karolherbst: yes
08:13 karolherbst: the same
08:14 karolherbst: by the way: is this okay? GL_MAX_TEXTURE_BUFFER_SIZE = 134217728
08:15 pmoreau: No clue
08:22 pmoreau: l1k: Ah ah, you were faster! :p He has an MBP mid '10 iirc.
08:23 l1k: pmoreau: oh ok. :) that would be a MacBookPro6,2 (15") or 6,1 (17") then...
08:23 pmoreau: l1k: He did some testing of my MBP Optimus patch serie, and I pointed him to your patch serie after you posted the first version some time ago.
08:24 karolherbst: pmoreau: the nouveau trace contains more calls in the faulty frames :o
08:24 pmoreau: karolherbst: Could the game behaviour be different depending on the GPU vendor?
08:26 pmoreau: l1k: My bad, it's an MBP9,1
08:30 karolherbst: pmoreau: maybe, maybe not
08:30 karolherbst: will check what is odd
08:30 RSpliet: karolherbst: what would be wrong with 128MiB?
08:31 karolherbst: ohh right, it is only MiB
08:31 RSpliet: presumably
08:32 karolherbst: okay, in nouveau glNormalPointer gets called
08:32 karolherbst: strange
08:32 karolherbst: the differences are kind of big
08:41 karolherbst: wierd
08:47 ratherDIfficult: 1gh/s is one trillion hashes in a second , 63m-25=48m iterations, 1gh/s / 25m/s = 40 h/s , 40*48mh = 1.920 gh/s + 1 = 3GH/s :D same as multiplied by three approx
08:47 ratherDIfficult: so gpu does not mine much it seems
08:56 ratherDIfficult: yeah, though Gh/s is bililon not trillion, to earn 100bucks in a day, it needs to be 50trillion not 3billions, so anyways
08:58 karolherbst: do you want to look over those trraces? http://filebin.ca/2I0rOHG3zevd/traces.tar.xz
08:58 karolherbst: one is done with intel, one with nouveau
08:58 karolherbst: and at the end of the traces there should be a difference in the loading screne
09:38 imirkin: karolherbst: some issues in mesa exist at head that don't with released versions... were you running the same mesa version?
09:38 karolherbst: imirkin: yes
09:39 karolherbst: git-3c6c4d4
09:39 karolherbst: for both
09:40 imirkin: ok
09:40 karolherbst: imirkin: anything unusual in the traces?
09:40 imirkin: dunno, didn't look, was just pointing stuff out
09:40 karolherbst: okay
09:41 karolherbst: anyway, ingame it is even worse, but I was trimming at the loading screen because it is the first obvious difference and the traces were only a few MB big this way
09:42 imirkin: is this an old game?
09:42 imirkin: glNormalPointer is GL2.0 stuff
09:44 karolherbst: don't know
09:44 karolherbst: imirkin: Release Date: 31 Jan, 2014
09:44 karolherbst: marked as "Indie" though
09:45 imirkin: ah ok
09:52 linkmauve1: Hi, this weekend I watched the XDC2015 presentation by Alexandre Courbot and Martin Peres, and at some point they said their platform requires some ioctls to make Nouveau and Tegra agree on the dmabuf format to use (tiled especially).
09:52 linkmauve1: Why is this an ioctl, instead of a modifier in the dmabuf itself?
09:53 linkmauve1: I’m currently working on dmabuf support in Weston, and I’d like to gather some information about the current usage of modifiers.
09:54 linkmauve1: I don’t have any mobile Nvidia platform though, so I can’t test that case myself.
09:54 imirkin: dunno if this is the reason, but there are a LOT of tiling possibilities on nvidia
09:55 linkmauve1: And not each of those is supported by the Tegra display controller, I guess.
09:55 linkmauve1: are*
09:55 imirkin: dunno
09:56 imirkin: iirc the desktop gpu one doesn't do tiled formats at all
09:56 imirkin: could be misremembering
09:57 linkmauve1: I don’t see any defined modifier for Nouveau (either mobile or desktop) at the end of /usr/include/libdrm/drm_fourcc.h, but it could just be that you didn’t defined any yet.
09:58 imirkin: it's not there at all
09:58 imirkin: there'd be like 100k of them if they were all to be enumerated
09:58 linkmauve1: Ow.
09:58 imirkin: you can tile in various increments along each of the 3 dimensions
09:59 imirkin: in addition to that, there are so-called "memtypes" which can sometimes be used with some MS formats, etc
10:05 linkmauve1: Do you plan on exposing those kind of non-raw formats as modifiers though? There are 56 bits available per vendor in the modifier field, which I assume would be enough for all of the possible formats you may want to expose.
10:06 linkmauve1: And then the display controller driver (either Nouveau’s or Tegra’s) would need to expose which ones it support, or at least to reject the ones it doesn’t support.
10:06 linkmauve1: Currently in Weston we refuse a dmabuf containing any modifier different from 0, that means no tiling in any way, but I’d like to support some kind of renegociation.
10:14 linkmauve1: Maybe I’ll wait for mupuf. :)
10:17 imirkin: yes, 56 bits should be enough to cover it :)
10:31 imirkin: xexaxo: if you're interested in wiring up nouveau for ARB_shader_clock as well, let me know... should be pretty easy. on nv50 there's a 32-bit value, on nvc0+ there are 2 special regs for a presumably 64-bit value.
10:33 xexaxo: imirkin: is there glslir/nir intrinsics support for tgsi/gallium ?
10:33 imirkin: not really. i've started on it for the atomic stuff
10:34 xexaxo: from a quick look I cannot see any... ack.
10:34 imirkin: i was thinking this would just be a system value, but i guess it might not be such a great fit
10:34 imirkin: since sysvals are probably assumed to be constant
10:34 neoraider: Hi, I already asked a few hours ago, but maybe now there's someone here who can interpret my error message
10:34 neoraider: I have tearing issues on a reverse PRIME output (intel with nouveau)
10:35 neoraider: And my kernel log is spammed with "[drm:drm_wait_vblank [drm]] *ERROR* Unsupported type value 0x9d, supported mask 0x7400003f" whenever there's a GL or VA-API user
10:35 xexaxo: all the glsl/nir typedefs are starting to get a bit annoying though :\
10:35 imirkin: afaik tearing is expected with reverse prime
10:35 neoraider: imirkin, oh, okay, I see
10:35 imirkin: xexaxo: yeah. also i dunno what's up with all the intrinsics being added with ir_call's... gr.
10:35 neoraider: imirkin, Iasked yesterday if it was normal, and got the opposite answer ;)
10:36 imirkin: neoraider: ask again tomorrow... best 2 out of 3?
10:36 neoraider: Well, even when it is normal, having 20-30 messages per second in my kernel log is not really acceptable
10:36 xexaxo: maybe yesterday people missed on the reverse prime business.
10:36 imirkin: yeah, i have no idea what that unsupported type value thing is
10:37 neoraider: I also have found various ways to segfault Xorg with reverse PRIME, I'll open a few bug reports when I've investigated it further
10:37 imirkin: any reason you're assuming this is a nouveau issue btw?
10:37 xexaxo: the kernel message does seems to come from i915, so that's a relief (from nouveau pov)
10:38 neoraider: xexaxo, ah, thanks for the info
10:39 xexaxo: I lied - drm_irq.c
10:39 neoraider: imirkin, well, the Nouveau Wiki seems to be the best source of information regarding PRIME and reverse PRIME, so I asked here first ;)
10:39 imirkin: neoraider: ah. sad comment on the state of documentation for this stuff.
10:40 imirkin: neoraider: you can try #intel-gfx if you want to reach the intel guys
10:40 neoraider: imirkin, ok, thanks
10:40 imirkin: neoraider: basically the problem with prime/reverse prime is that outside of a handful of people, no one actually understands how it works
10:40 imirkin: (i do not belong to that handful, in case that wasn't clear)
10:42 imirkin: skeggsb_: what do you think about PUSH_SPACE always requesting size + # of slots required for a fence emit?
10:43 imirkin: skeggsb_: i wonder if nv50/nvc0 don't run into this because they use PUSH_SPACE a lot more than nv30
10:44 linkmauve1: Oh, this PRIME and reverse PRIME stuff is also an usecase I should consider for modifiers, but from what I understand it would require different vendors to understand each other’s modifiers for it to work properly.
10:46 imirkin: linkmauve1: which they usually don't
10:46 imirkin: linkmauve1: although once in a while, the stars align
10:46 xexaxo: and miracle happens... but don't fold your breath :P
10:47 linkmauve1: :D
10:47 imirkin: linkmauve1: it'd be reasonable to expect each vendor to know exactly which other vendor's formats match up -- that gives you the option of making it work, but leaves it up to be done for only the practical combinations.
10:48 linkmauve1: Maybe the receiver could expose a list of modifiers they support from a few other vendors, or something similar.
10:48 imirkin: exactly
10:49 imirkin: but even intra-vendor there are plenty of incompatibilities
10:49 imirkin: esp if you grab gpu's from diff generations
10:50 linkmauve1: Oh, you mean somebody with two different Nvidia GPUs, rendering a buffer on one, exporting a dmabuf, and trying to display it on the other? /o\
10:50 imirkin: yes
10:50 imirkin: not that that's particularly likely outside of a test environment
10:50 imirkin: but right now i happen to have a GF108 and GT215 plugged in :)
10:51 linkmauve1: Both display drivers would likely expose their planes as supporting only some specific modifiers, right?
10:51 imirkin: planes?
10:51 linkmauve1: DRM planes.
10:51 imirkin: no planes since nv30
10:51 linkmauve1: The ones on which the actual dmabuf import will be exposed.
10:52 linkmauve1: Err, how do you handle cursor or YUV overlays?
10:52 imirkin: yuv overlays -- no such thing
10:52 imirkin: there's a special cursor thing
10:52 imirkin: up to a certain size, i forget how big... 128x128 probably, but not sure
10:53 imirkin: there used to be yuv overlays back in the bad old days. but not since nv41
10:53 linkmauve1: Interesting.
10:53 linkmauve1: Not even on mobile?
10:53 imirkin: tegra might support them, but that's a whole separate chip
10:53 imirkin: completely unrelated to the nvidia desktop gpu chips
10:53 linkmauve1: Sure.
10:57 glennk: imirkin, how is time read on nv gpus? on egcm there's a special source value type for hi/lo time, so i guess a system value would work fine for that
10:57 imirkin: glennk: special regs
10:57 imirkin: glennk: but the thing is that you can't just read it whenever, you want to read it at a particular point in the shader
10:57 imirkin: glennk: so you can't reorder it, propagate it, etc.
10:58 imirkin: glennk: so an ir_call intrinsic might work better for glsl ir
10:58 glennk: well, the implementation would just set the source to the op using it
10:58 imirkin: huh?
10:59 imirkin: i mean if you have code like
10:59 imirkin: start = time(); stuff; end = time();
10:59 imirkin: you can't move the first time call after the stuff
10:59 imirkin: or CSE them
11:00 glennk: sure, but thats just the compiler knowing the op source isn't constant
11:01 imirkin: right
11:01 imirkin: which i think generally system values are assumed to be
11:04 glennk: seems like more of a de facto thing rather than a specified one
11:08 glennk: anyway, seems like nv and amd are similar in how its handled, so what does intel do?
11:14 imirkin: glennk: probably sends a message :) that's how they handle everything
11:14 glennk: they really love formatting messages around
11:28 glennk: seems like a special reg on intel as well
12:24 Guest77445: hello. screen flickers on vertical stripes
12:25 avi__: as well as the top bar
12:25 avi__: is this a known issue?
12:26 imirkin: not sure i understand what you're saying
12:29 avi__: I have screen flickers in portions of the screen
12:29 karolherbst: imirkin: can you think of any other use for the pdaemon counters than load measurements?
12:29 karolherbst: I think about to just start the counters preconfigured for the different load types and just expose one API which let them be read all out and reset the counters
12:29 avi__: imirkin, were you addressing me?
12:30 imirkin: avi__: i was.
12:30 avi__: so, some colors are rendered as flickering stripes
12:30 karolherbst: avi__: stupid question, but is your cable fine?
12:31 avi__: the tab bar of my chrome browser (I thought it was the top of the screen, but on, it moves with the window) also flickers
12:31 karolherbst: okay, so not the cable :D
12:31 avi__: the cable is hidden in the laptop body
12:31 imirkin: avi__: what gpu?
12:31 karolherbst: ahh it is a laptop
12:31 avi__: 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev a1)
12:32 avi__: some backgrounds (twitter) render as vertical stripes, which are flickering
12:32 imirkin: avi__: sounds like dithering fail maybe?
12:32 avi__: I can't tell if the stripes are there originally, or just rendered as stripes
12:33 avi__: quite possible, does it dither every frame individually?
12:33 imirkin: avi__: try something like 'xrandr --output LVDS-1 --set 'dithering mode' off
12:33 avi__: I'm ~20 years behind in graphics
12:33 imirkin: well, dithering is a 20-year old technology, so should be about your speed
12:33 avi__: magic!!!
12:33 avi__: we didn't render on every frame these days
12:34 imirkin: dithering is something you do when you have more colors than the display supports
12:34 avi__: how do I persist this the "right way"?
12:34 karolherbst: what the hell is dithering :p
12:34 imirkin: so if e.g. you have 8-bit color and a 6-bit display
12:34 imirkin: then... you dither
12:34 avi__: shouldn't I have zillions of colors?
12:34 imirkin: not all laptop panels have zillions of colors
12:34 karolherbst: is 32bit or 24bit these days default?
12:35 avi__: aha, so the card dithers for them?
12:35 imirkin: in fact most have 6bpc (i.e. 18 bit total) whereas you're trying to render 8bpc
12:35 imirkin: anyways
12:35 imirkin: nouveau sometimes misdetects the panel's capabilities
12:35 imirkin: which in turn causes it to turn on dithering when it shouldn't
12:35 imirkin: sounds like in your case, it shouldn't
12:35 imirkin: please file a bug and include your vbios
12:35 avi__: sure. is there a module parameter meanwhile? or xandr on startup?
12:36 avi__: do you use the kernel bugzilla?
12:36 imirkin: afaik there's no way to configure X to auto-set that
12:37 imirkin: i never look at the kernel bugzilla, only bugs.freedesktop.org
12:37 avi__: ok
12:38 avi__: anyway, thanks a lot! I was thinking of gauging my eyes out
12:40 avi__: imirkin, there's no nouveau component, shall I use xorg or what?
12:42 imirkin: avi__: xorg -> Driver/nouveau
12:42 avi__: yeah, found it
12:42 imirkin: avi__: you can get your vbios at /sys/kernel/debug/dri/0/vbios.rom
12:47 avi__: imirkin, filed as https://bugs.freedesktop.org/show_bug.cgi?id=92297
12:47 avi__: imirkin, can I persist the setting somehow? module parameter?
12:48 imirkin: avi__: not that i'm aware of.
12:48 imirkin: avi__: of course easy enough to patch the kernel
12:48 imirkin: given as how you maintain kvm, i suspect that shouldn't be too much of an issue for you :)
12:49 avi__: imirkin, ok. it's a big step forward for me, I was thinking of accidentally dropping the laptop from a roof or something
12:49 avi__: imirkin, I'm an ex-maintainer (not to be confused with an X maintainer)
12:49 imirkin: then it'd *really* need dithering :)
12:50 imirkin: ah ok. wasn't keeping track too closely.
12:55 imirkin: avi__: the relevant functions are nouveau_connector_detect_depth and nv50_crtc_set_dither
12:56 avi__: imirkin, I'm not going to dive in there (but will test patches if you need me to)
12:56 imirkin: avi__: looks like it assumes 6bpc for LVDS
12:56 imirkin: unless some straps are set... hm
12:56 avi__: imirkin, so the screen is better than it's supposed to be? strange, everything about this laptop is crappy except the memory
12:57 imirkin: well, keep in mind that this code works with hardware manufactured from 2000 as well
12:57 imirkin: you're not the first person to report this issue
12:58 imirkin: so i'm guessing there's some new thing going on
12:58 avi__: what's strange is that it used to work until about two weeks ago
12:58 imirkin: hmmmmm
12:58 imirkin: did you update kernels?
12:58 imirkin: nouveau got *major* updates in 4.3
12:58 imirkin: largely rewriting
12:58 avi__: then I lost brightness controls, and the screen was pretty dark
12:58 avi__: running 4.1.8
12:59 imirkin: ah ok
12:59 avi__: I update regularly, so I can't tell if it was related
12:59 imirkin: the whole brightness thing is a huge clusterf*ck too
12:59 imirkin: there are 10 diff mechanisms to do it, and never a clear way to tell which one's actually hooked up
12:59 avi__: disabling optimus got me my brightness back, but then I had the flickering
13:00 avi__: and now that's fixed too. should I emable optimus back, or is that useless under linux?
13:00 avi__: imirkin, at least in virt, everything has a spec
13:01 imirkin: well, with optimus that usually means using the intel gpu to render everything
13:01 imirkin: or rather, to drive all the displays
13:01 imirkin: and the nvidia chip can power off unless you want to use it for 3d accel
13:01 imirkin: which wouldn't be a wise idea unless you were actively working on nouveau
13:01 avi__: well, under gnome, isn't 3d always on?
13:01 imirkin: since it's a crap fermi chip and nouveau doesn't support reclocking it at all
13:01 imirkin: which makes it slower than the built-in intel gpu
13:02 imirkin: either gpu is more than powerful enough to run gnome-shell
13:02 avi__: well then, should I or should I not? I don't game
13:03 imirkin: if battery power is important to you, i'd recommend switching back to intel as main
13:03 avi__: ok, I'll try it
13:03 imirkin: if you don't care, then it doesn't matter. but intel has a full team of paid developers maintaining it.
13:03 imirkin: nouveau ... does not.
13:03 avi__: battery on this laptop only lasts enough to plug into the closest wall plug
14:26 BlueMatt: so ati drivers are being predictable unstable and crashing my workstation a bunch....for something who's displays exist almost exclusively to display a terminal on multiple 4k monitors, what gpu should I run and buy to fix my shit?
14:28 imirkin: BlueMatt: are you using the open-source drivers for radeon?
14:28 BlueMatt: yea
14:28 imirkin: BlueMatt: you should request help in #radeon for that one
14:28 BlueMatt: no, I've had too many issues there, I'm just gonna go buy an nvidia card
14:28 imirkin: they tend to be fairly responsive
14:28 imirkin: if you're comfortable running proprietary drivers, any nvidia board will do
14:28 imirkin: [that has the outputs you require]
14:28 BlueMatt: nope, hence why I'm here :p
14:29 imirkin: i can't recommend anything past kepler for use with nouveau
14:29 BlueMatt: ie, what old nvidia card will use little power and power multiple 4ks
14:29 BlueMatt: I dont even play video or have a web browser
14:29 imirkin: how many is multiple?
14:29 BlueMatt: on nouveau
14:29 BlueMatt: like, 2
14:29 BlueMatt: maybe 3 in a few months when I get bored
14:30 imirkin: well, 2 and 3 are a world of difference
14:30 imirkin: nouveau doesn't support MST
14:30 imirkin: so you're limited to the number of DP outputs
14:30 BlueMatt: hmm, indeed...guess I can live with 2
14:30 imirkin: i looked at this the other day, and it doesn't appear that any keplers have more than 2 DP outputs
14:30 BlueMatt: damn :(
14:30 imirkin: HDMI can't drive 4k @60hz
14:30 BlueMatt: oh, I dont need 60hz
14:30 BlueMatt: its just a terminal :p
14:30 imirkin: (well, HDMI 2.0 can, but kepler doesn't have HDMI 2.0)
14:31 imirkin: yeahhhh you say that now
14:31 imirkin: but then you'll be like "damn, i want 60hz"
14:31 BlueMatt: I dont even have a web browser on the thing
14:31 BlueMatt: I have been running 30hz for like...a year
14:31 BlueMatt: I would like to upgrade my kernel past like...3.16, and that makes radeon die
14:31 BlueMatt: so...nvidia it is
14:31 imirkin: well, then any kepler board should do the trick
14:32 BlueMatt: ok, thanks :)
14:32 imirkin: any 6xx or 7xx gpu except GTX 750, which is a GM107
14:32 BlueMatt: nice
14:32 imirkin: (they do this for the sole purpose of wildly confusing people, i'm sure)
14:32 imirkin: if you find a board you like, i can double-check that it's a kepler or not for you
14:32 BlueMatt: I'm just gonna run to central in sf and see what they have in-store
14:33 BlueMatt: I can google when I get there :)
14:33 BlueMatt: thanks, though
15:49 AndrewR: imirkin_, hello. Have you tried to launch GL Excess (3d opengl benchmark/demo) via wine on nv4x ? For me it part-broken, but may be I need to try newer wine first
15:51 imirkin: AndrewR: i don't do a lot of testing on nv3x/nv4x
15:51 imirkin: AndrewR: there are occasional fixes though, make sure you're using latest mesa
15:51 AndrewR: imirkin, I know you already have a lot to fix
15:52 AndrewR: imirkin, OpenGL version string: 2.1 Mesa 11.1.0-devel (git-93161be)
15:53 imirkin: what's the issue?
15:56 AndrewR: imirkin, http://www.glexcess.com/files.htm - using ver 1.2v I tried to see how far it will go until hang (at some point in the past it was hanging on 'waterfall' scene) . Now it can run until end, but some scenes not rendered (one of the first ones), and for example spaceship chase started like my VRAM broken - rainbow mess instead of scene. So, I'm sure it expose more than one bug
15:57 AndrewR: imirkin, I tried NV30_SWTNL=1, but problems was still here.
15:57 imirkin: AndrewR: do you get prints telling you that it's skipping depth?
15:57 imirkin: aka zsbuf
15:57 imirkin: due to a format mismatch
15:58 AndrewR: imirkin, not from what I recall. But let me retry
15:59 imirkin: will only show if you have debug enabled
16:06 AndrewR: imirkin, then I need mesa rebuild :}
17:21 AndrewR: imirkin, https://bugs.freedesktop.org/show_bug.cgi?id=92306 - but for now I think I can only go to bed (3am here) ...
17:31 imirkin: AndrewR: i'm afraid you'll have to do some debugging on it yourself if you want to resolve it
17:31 imirkin: AndrewR: i'm presently occupied with figuring out why some stuff is still broken on big-endian boxes...
17:31 imirkin: i'm sure it's something horrid
18:02 imirkin: heh. test run on nv30: [14413/14413] crash: 5, dmesg-warn: 1, fail: 178, pass: 361, skip: 13868 (be). urgh.
18:05 imirkin: http://hastebin.com/owexazuvej.rsl -- i *wonder* what might be going on there... ugh.
18:27 Jayhost: Thanks again imirkin, what are you working on?
18:30 imirkin: Jayhost: i semi-recently acquired a ppc g5 to fix up nouveau on BE
18:34 Jayhost: I'm not familiar with BE. Assuming something to do with powerpc architecture. Interesting.
18:35 imirkin: big-endian
18:36 imirkin: not strictly architecture specific, but ppc's tend to be BE (although esp new ones can be confirmed for LE)
18:44 Jayhost: Nice
18:45 Jayhost: Is that in high demand or just do it for completeness.
18:48 imirkin: exceedingly low demand, i'd say
18:48 imirkin: i'm semi-convinced i have the last such working machine that will use nouveau :)
18:53 Jayhost: Haha pure sport.
18:59 imirkin: i don't really go by demand... more like random fancies
19:06 Jayhost: Has to be interesting or else it's masochism
20:05 imirkin: skeggsb_: can you give me a refresher on how to read vram on a nv3x from the cpu?
20:56 Jayhost: The last time I used a PPC g5 I was loading the OS with a MB in firewire hard drive mode.
20:58 skeggsb_: imirkin: map bar1 (directly maps over vram)
20:58 imirkin: skeggsb_: are there nva* tools to do this?
20:59 skeggsb_: no idea, but nv_rf* in my repo will do it
20:59 imirkin: skeggsb_: and any opinion on whether that'd get byteswapped in BE mode?
20:59 skeggsb_: no idea on that, but my educated guess would be no byte-swapping
21:00 imirkin: skeggsb_: any opinion on whether m2mf-style things byteswap?
21:00 imirkin: ugh, i guess i need to write some programs to Just Try It (tm)
21:01 imirkin: i was hoping i could deduce this directly, but that may not work out
21:01 skeggsb_: i can't imagine m2mf does, it has no idea on the word size
21:02 imirkin: well, it could take a flag
21:23 imirkin: skeggsb_: btw, i pushed some stuff and mesa kinda-sorta works now on BE... far from completely though.
21:23 skeggsb_: yeah, i noticed the commits earlier
21:24 skeggsb_: having fun? ;)
21:25 imirkin: hehe a bit
21:25 imirkin: skeggsb_: could i trouble you to comment on the premise of http://patchwork.freedesktop.org/patch/61045/ ?
21:37 skeggsb_: imirkin: there's probably not any nicer way to do that, so, sure
21:39 imirkin: skeggsb_: but does the premise sound correct? the kick notifier happens *before* the swap to the new buffer?
21:42 skeggsb_: yes, that was intentional
21:42 skeggsb_: i'm strugging to recall the details however
21:42 imirkin: it actually seems like the right thing to do
21:43 imirkin: you want the fence emit to be at the end
21:43 imirkin: not at the beginning
21:43 skeggsb_: yes, but istr that mesa's fence handling is somewhat strange too, i couldn't remember how exactly that works
21:44 imirkin: yeah, i figure it out every so often and then promptly forget