00:02 mwk: well, it seems the pixel pipelines just hate me
00:05 mwk: everything that is on set 2 hates me as well
00:12 mupuf: not sure I ever got anything out of set 2
00:12 mupuf: are you already that advanced in your testing ? :o?
00:13 mwk: I'm using the perf signals to figure out the structure of the pipeline
00:13 mwk: with reasonable success on NV10/NV20/NV30
00:13 mwk: and not entirely reasonable success on NV40
00:14 whompy: From earlier discussion, FreeSync is in the DP standard to some degree, whereas G-sync requires proprietary hardware. It seems that the actual driver side requires nothing crazy from what I can understand. It'd be interesting to check AMD's DC implementation though.
00:15 whompy: Well, Adaptive Sync is in DO
00:15 whompy: DP. FreeSync is the AMD marketing thing. At least the first gen.
00:15 mupuf: mwk: oh, finally got to it! Great!
00:16 mwk: mupuf: http://0x04.net/~mwk/celsius.png
00:16 mwk: hmm
00:16 mwk: I should update that with a few fixes :p
00:16 mupuf: you mapped that based on the number of cycles it would take between all the signals would be fired?
00:17 mwk: no
00:17 imirkin: whompy: ok so both require different specialized hw?
00:17 mwk: I abused the reset register
00:17 mwk: kept various units in reset, sent commands to the card, watched which signals fired and which did not
00:18 mwk: if keeping some unit in reset makes some signal stop firing, it means it belongs to the unit or some downstream one
00:19 mwk: also... there may be forks & joins in the pipeline
00:19 mwk: the joins are places that tend to hang if you disable just one of the inputs, since they expect stuff to come on the other end
00:20 mwk: I need to make drawings for NV20 and NV30, these are way cooler
00:22 mwk: but... NV40 pixel pipelines refuse to appear
00:22 mwk: finding the IDX/XF/VTX trio, the raster pipe, and the attribute pipe was easy
00:22 mwk: then there's some weirdo join, and it immediately goes to PROP
00:24 mupuf: ah ah, fun@!
00:24 mwk: of course, I may be submitting the wrong commands...
00:24 mwk: but then, pixel pipelines so far refused to appear in all kinds of tests
00:25 mwk: PM is not the only thing I have in my toolbox...
00:33 mwk: whoa
00:33 mwk: I was submitting the wrong commands
00:34 mwk: sending texture state bundles lights up much more stuff
00:34 kuzetsa: $ chromium --single-process <<< apparently, fixes my GPU (hardware acceleration) issue -- at least according to chrome://gpu
00:34 kuzetsa: ... but various glitches occur
00:35 kuzetsa: and also --- OpenGL renderer string: Gallium 0.4 on NVC1 {~ [...] ~} Vendor: nouveau
00:35 kuzetsa: (0x10de) <<< glxgears says it's fine?
00:35 mwk: still nothing on set 2 though, maybe it's just that boring.
00:35 kuzetsa: is there something I need to do other than adding myself to the "video" usergroup?
00:37 nyef: Is chromium doing the same multi-threaded obnoxiousness as KDE?
00:38 imirkin: i dunno... don't think so
00:38 imirkin: maybe?
00:38 imirkin: they used to virtualize contexts for mesa
00:39 imirkin: however i don't see that anymore
02:31 kuzetsa: turns out it was just a glitched / corrutped chromium profile :)
02:31 kuzetsa: wiping it out fixed my issue, but apparently VLC has a known bug related to VDPAU acceleration (which doesn't cause issues for other things, but apparenty messed up on VLC real bad artifacts)
02:32 imirkin: well, i dunno about vlc, but there are known issues with decoding of some h264 videos
02:32 imirkin: separately, some players decided it'd be hilarious to decode using vdpau in one thread, and then do post-processing with GL in another thread, which also destroys nouveau
02:32 imirkin: afaik kodi and mov do that
02:32 imirkin: i personally stick to mplayer. works every time.
02:32 kuzetsa: heh
02:34 kuzetsa: https://forum.videolan.org/viewtopic.php?t=132705 <<< it's specific to H.264 in VLC -- good catch
02:35 kuzetsa: oh, that's the wrong thread
02:35 kuzetsa: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1512993 <<< that one is what i meant to link (I had a bunch of similarly-titled pages in my browser history and grabbed the wrong one)
02:36 imirkin: yeah - there are some undiagnosed issues in h264 decoding. i spent days trying to figure out without success. blocks get messed up, etc
02:36 kuzetsa: it acts up in the proprietary drivers too
02:37 imirkin: mmmm... not as bad as with nouveau
02:37 imirkin: probably separate bugs.
02:37 kuzetsa: nod
02:37 imirkin: the videos that have issues on nouveau replay just fine on nviida
02:40 kuzetsa: once I realized youtube, and even netflix HTML5 DRM-protected (widevine) video was working fine on chromium, but there were known issues with H.264 on VLC with nouveau, I sorta gave up
02:41 imirkin: originally it used to mostly be movie trailer videos that had issues
02:41 imirkin: something to do with the editing process of putting them together i guess
02:42 imirkin: regular movies were totally fine
02:42 imirkin: recently it's been more random i think
02:42 kuzetsa: nod
02:42 kuzetsa: I've occasionally had some funny issues after "rendering" (which ... I guess is what it's called) a video for upload to youtube -- done some content creator things
02:43 kuzetsa: like some encoders / acceleration methods for encoding are rubbish
02:43 imirkin: yeah that's a separate issue :)
02:43 kuzetsa: but I haven't done much of that since my windows dualboot died from bitrot finally
02:43 imirkin: nouveau doesn't provide any encoding capabilities
02:44 kuzetsa: well no - I mean some encoders produce output which is harder to decode without weird blocky artifact and motion compensation failures, etc.
02:45 kuzetsa: basically, I've used editing tools (nonlinear video editing tools ... where you can clip scenes out and add effects and get rid of dull footage to make a better upload)
02:45 kuzetsa: so I know some tools are worse than others at producing a "clean" video which will play smoothly for all decoders/players/devices
02:46 kuzetsa: [21:41:55] <imirkin> something to do with the editing process of putting them together i guess <<< was agreeing with you, mostly
02:47 imirkin: gotcha
02:47 imirkin: though like i said, those videos did play back fine on blob
02:57 kuzetsa: yeah I think I'm starting to notice issues after all
02:58 kuzetsa: netflix while a compile job is running (it's a "nice" compile job and everything) was having major stuttering/desync issues
02:58 kuzetsa: no artifacts, just unsteady framerates :(
02:58 imirkin: minimize the window with the compile job
02:58 kuzetsa: it's on a different virtual desktop
02:59 kuzetsa: but I did it in a screen sessio and could get away with detaching if you think it'll help
03:00 kuzetsa: there, gonna collapse the IRC client too (no other windows with output being updated other than the browser in which video playback is happening)
03:00 imirkin: well, mostly about minimizing the amount of screen updates
03:00 imirkin: compile jobs tend to print lots of lines in terms
03:00 imirkin: i've had that slow things down when playing something back windowed
03:10 kuzetsa: youtube @ 1080p was fine, apparently
03:11 imirkin: we're not driving the engines in parallel which loses some potential perf
03:11 kuzetsa: so I guess there's just some new limitations now that I'm on nouveau O_O
03:11 imirkin: also you probably haven't reclocked your gpu, which loses a lot of perf
03:11 kuzetsa: oh, I remember hearing something about that
03:12 imirkin: what GPU do you have?
03:12 kuzetsa: power/thermal/performance management stuff is handled by the driver rather than hardware for modern nvidia GPUs
03:12 imirkin: for all nvidia GPUs actually
03:12 imirkin: hw has safetys to avoid damage
03:13 kuzetsa: NVC1
03:13 kuzetsa: that is to say, Geforce GT 540M
03:13 imirkin: ah, too bad
03:13 imirkin: no reclocking for fermi
03:13 kuzetsa: oh, you mean nouveau can't do anything about it?
03:14 imirkin: yep
03:14 kuzetsa: so I'm stuck at whatever frequency it's at during boot... hmm
03:14 imirkin: yep. although on the bright side, some of those GF108's boot to a middle freq rather than lowest
03:14 kuzetsa: nod
03:15 imirkin: although for a mobile version? dunno. cat /sys/kernel/debug/dri/0/pstate (or /1/pstate)
03:17 kuzetsa: I was curious and ran:
03:17 kuzetsa: sudo ls /sys/kernel/debug/dri ----> output says: 0 1 128 129 64 65
03:18 imirkin: either 0 or 1, depending on driver load order
03:18 kuzetsa: oh
03:18 imirkin: presumably your primary is intel
03:19 kuzetsa: oooh, yeah, then zero is my HD3000 (nVidia optimus... because I've got THAT particular sauce on this laptop)
03:19 imirkin: heh. SNB vs the GF108. tough call.
03:19 imirkin: both pretty much crap.
03:19 kuzetsa: ls /sys/kernel/debug/dri/1/ ----> output says: bufs clients DP-1 gem_names HDMI-A-1 name vbios.rom vm vma
03:19 kuzetsa: (there's no pstate in there)
03:19 imirkin: do you have an ancient kernel?
03:20 kuzetsa: no
03:20 kuzetsa: it's a fairly recent kernel.org mainline "longterm" kernel (4.4.x)
03:20 imirkin: yeah. so basically ancient.
03:20 imirkin: i think it's in there starting 4.5
03:20 imirkin: 4.4 it was in /sys if you boot with nouveau.pstate=1
03:20 kuzetsa: oh, you mean feature-wise
03:20 kuzetsa: not actual age
03:20 imirkin: i mean age-wise
03:21 kuzetsa: age-wise, 4.4.x is still maintained
03:21 imirkin: doesn't make it not ancient
03:21 imirkin: v4.4 was released a year ago.
03:21 kuzetsa: no
03:21 imirkin: Sun Jan 10, 2016
03:21 kuzetsa: 2 days ago
03:21 kuzetsa: 2017-01-12
03:21 imirkin: i'm looking at 'git show v4.4'
03:22 kuzetsa: 4.4.42 <<< the 4.4.x branch is just a feature free
03:22 kuzetsa: *feature freeze
03:22 kuzetsa: this is literally the latest "longterm" kernel from mainline / kernel.org
03:22 imirkin: you can call it what you want. v4.4 + some limited selection of bugfixes. either way, v4.4 was released a year ago. thus any 4.4.x is ancient.
03:22 kuzetsa: ...
03:23 kuzetsa: 2 days ago is not ancient
03:23 imirkin: so let me get this straight - i take linux 1.0, released 20 years ago, apply a patch, release it today - now the release is brand new?
03:23 kuzetsa: yep
03:23 kuzetsa: that's how redhat does it
03:23 imirkin: heh, ok
03:23 kuzetsa: they're still maintaining 2.6.x kernels
03:24 Mittttens: is there anything that can be done about mouse stuttering (seems to happen at high CPU usage)
03:24 imirkin: i don't really keep track of the state of the kernel tree from 1 year ago, or whenever
03:24 imirkin: which is effectively what the "stable" stuff is - branches that are unmaintained by the people who develop the software.
03:24 Mittttens: maybe it's GPU lag but it's been happening while playing a software rendered game
03:25 kuzetsa: imirkin: well from an OS development standpoint, having a stable / reference platform to develop on goes a long way toward reducing feature creep nightmares
03:25 imirkin: kuzetsa: maybe so. doesn't make the tree old and crusty.
03:25 kuzetsa: it's literally current
03:25 kuzetsa: the latest "longterm" branch
03:25 imirkin: er, doesn't make the tree NOT old and crusty
03:25 kuzetsa: there's not a newer longterm tree than this one
03:26 kuzetsa: it's the latest
03:26 kuzetsa: 4.4.x is current
03:26 imirkin: v4.10-rc3 is current.
03:26 kuzetsa: that's not a longterm branch
03:26 kuzetsa: that's a "run debian sid and watch things break" kernel
03:26 kuzetsa: 4.9.x is the newest I'd touch with a 10 foot pole
03:29 kuzetsa: if I had someone else to test compatibility (and wasn't maintaining my own built-from-source userland + kernel) I probably wouldn't mind a non-longterm kernel, etc.
03:30 imirkin: "longterm branch" and "current" are incompatible concepts in my mind.
03:30 kuzetsa: it's a personal preference -- when I do unit testing, I like to make sure I can build the entire OS (kernel, libc, compiler toolchain, bits to make a working package manager, drivers, etc. etc. etc.) from source without any stability or reliability regressions
03:31 imirkin: i'm not saying you have to live on the bleeding edge. but recognize that you're running an old version that is no longer supported in any way by upstream developers.
03:31 kuzetsa: 4.4.x is literally the latest stable kernel on gentoo
03:31 kuzetsa: it's still supported (actively)
03:31 imirkin: ... and if you came and said you had some sort of kernel issue with it, i'd say "does it still happen on a non-ancient kernel" :)
03:31 kuzetsa: you've got it backwards
03:32 kuzetsa: the way to think of it is -- "hey this bug is happening" --> "does it happen on the latest stable kernel"
03:32 imirkin: don't think so - i'd *definitely* say that.
03:33 kuzetsa: feature freeze is a good thing
03:33 imirkin: anyways, if you want to see a pstate file on that kernel, you want nouveau.pstate=1 iirc, and it comes up in /sys somewhere
03:33 kuzetsa: it means stablization can happen :)
03:34 kuzetsa: I didn't build any pstate support into the kernel, actually
03:34 kuzetsa: a couple ACPI-type features and CPUFREQ and a few other old-school / proper stable mechanisms
03:35 kuzetsa: ability to change governor policy and frequency and enter ACPI-type sleep modes is plenty
03:36 kuzetsa: also, I'm more than capable of backporting a feature to 4.4.x kernels :)
03:37 kuzetsa: https://github.com/kuzetsa/android_kernel_htc_msm8974 <<< I no longer work on that, but where it says >>> This branch is 3071 commits ahead, 71 commits behind CyanogenMod:cm-12.1.
03:37 kuzetsa: no joke, I've been around a backport or two :)
03:38 imirkin: so you know just how much fun it is
03:38 kuzetsa: 3.4.x kernel is actually plenty new enough for android
03:38 kuzetsa: 4.4.x is bleeding-edge by that standard
03:39 kuzetsa: I know that porting a large patchset from one major kernel version to the next is a nightmare
03:40 kuzetsa: #1 reason is all the changes and new things which get added in-between feature freezes
03:40 kuzetsa: I'm on 4.4.x intentionally -- I'm maintaining a kernel patchset for this hardware
03:41 kuzetsa: to each their own
03:53 kuzetsa: also, thanks
03:53 kuzetsa: you were right
03:54 kuzetsa: [22:00:14] <imirkin> well, mostly about minimizing the amount of screen updates [...] [22:00:32] <imirkin> i've had that slow things down when playing something back windowed
03:54 kuzetsa: ^ great suggestion :)
03:55 imirkin: heh, neat.
03:57 imirkin: kuzetsa: also ... your SNB should have perfectly fine h264 decoding capability via VA-API, and also h264 encoding should you need that.
04:04 imirkin: kuzetsa: btw, you should try to get freedreno going on that MSM8974 :)
04:04 imirkin: a330 should be reasonably well supported
04:14 kuzetsa: the device I was using for developing that broke
04:14 kuzetsa: so I sold it for cheap to someone who enjoyed handling ewaste to see if she could repair it
04:14 kuzetsa: the outcome made me laugh
04:14 kuzetsa: she managed to fix the damaged USB/charging port
04:15 kuzetsa: put it back together, but then noticed she forgot to put in an important component
04:15 kuzetsa: and was being a little too aggressive the second time taking it apart --> broke the screen
04:15 imirkin: doh
04:16 imirkin:is trying to remember how to cross-compile the kernel...
04:16 kuzetsa: you need a cross compiler
04:16 imirkin: i've done this 100 times
04:16 kuzetsa: hehe
04:16 imirkin: i just forgot the specific make var names
04:17 imirkin: aha, got it
04:17 imirkin: ARCH=arm CROSS_COMPILE=prefix
04:17 kuzetsa: ah yeah - various environment variables to coerce the toolchain into taking a particular action
04:18 imirkin: going to give the TK1 another shot. it was dying on basically any network activity before...
04:18 imirkin: i'm hoping that time has resolved my problems
04:18 kuzetsa: few years ago I wrote a wrapper (to go with the cross-development / cross-compiling libraries, headers, etc.) to automate a feature which gentoo has ... dot dot dot
04:18 kuzetsa: you can build arbitrary packages for arbitrary OSes/architectures using the regular gentoo package manager
04:19 imirkin: i use crossdev + the neat-o emerge-to-another-arch-and-root support
04:19 kuzetsa: yep
04:19 imirkin: might be stuck building yet-another one for arm64. we'll see.
04:19 kuzetsa: but all the environment variables and stuff you've gotta set - it's handy to...
04:19 kuzetsa: wait, you use gentoo haha okay
04:19 kuzetsa: I guess you're in the other gentoo camp
04:19 imirkin: for well over a decade...
04:19 kuzetsa: ~2003 or so for me, yeah
04:20 imirkin: time flies.
04:20 kuzetsa: gentoo camp 1>>> bleeding edge / new / latest is SO NICE!!!
04:20 imirkin: i generally stick to the non-prefixed packages.
04:20 kuzetsa: gentoo camp A>>> stable / reproducible / well-tested is SO NICE!!!
04:20 imirkin: except for the things i care about having a specific version of.
04:21 kuzetsa: IDK why I picked a number for one, or a letter for the other
04:21 kuzetsa: and both of them are like ... first index position
04:21 imirkin: 0-indexing...
04:22 kuzetsa: no, index position zero contains a value representing the number of elements in the data structure :3
04:22 kuzetsa: ... LUA 4-evah
04:22 kuzetsa: 4 evarrrr
04:26 kuzetsa: not even sure if it's weird that I have so much experience in node.js and lua, but mostly am language-agnostic and can handle working in code for just about any non-python language
04:26 kuzetsa: that whitespace flow control thing messes with my learning disabilities / perception issues (dyslexia and whatnot - related disorders)
04:27 imirkin: heh. there's an input processor hack for python that makes it use {} instead of spacing.
04:27 imirkin: i suppose you're not a big fan of the 'whitespace' language either?
04:28 nyef: ... Is it a programming language similar to 'unlambda', but where the combinators are represented by ascii codepoints 9 and 32 ?
04:28 imirkin: nyef: https://en.wikipedia.org/wiki/Whitespace_(programming_language)
04:29 imirkin: it's so much more than just 9 and 32
04:29 imirkin: there's also 10 :)
04:29 kuzetsa: um
04:29 kuzetsa: I don't think anyone does serrious development in that language
04:29 GaivsIvlivs: hallo
04:29 nyef: So I see. Neat.
04:29 kuzetsa: lua has practical uses
04:30 nyef: kuzetsa: I've heard the same about JavaScript, but I've yet to see any. d-:
04:30 kuzetsa: and node.js is a direct descendant / adaptation of the V8 javascript engine used in chrom[ium]
04:31 kuzetsa: there's more javascript (node.js or otherwise) on github than any other language
04:31 kuzetsa: you're just not looking
04:31 imirkin: sad comment on github
04:31 kuzetsa: rude
04:32 nyef: I was doing server-side javascript more than a decade ago. It wasn't particularly practical then, and it's not particularly practical now.
04:32 imirkin: it was particularly impractical then :)
04:33 nyef: It's particularly impractical now!
04:37 nyef: (Just, the particulars have changed.)
04:38 imirkin: nyef: how's your 3d adventure going?
04:42 nyef: I think I've gotten about as far as I can on the kernel side, modulo actually testing it on my gk104.
04:43 imirkin: nyef: so you have the kernel code all updated for properly setting the infoframe bytes?
04:43 imirkin: based on incoming modeline parameters
04:44 nyef: I don't know about modeline parameters, but definitely based on the EDID.
04:44 GaivsIvlivs: is renouveau still a thing?
04:44 nyef: At least for gt215, and I'm hoping gk104.
04:45 nyef: I have no hardware for gf119 or g84, so I'm somewhat at a loss there.
04:45 imirkin: GaivsIvlivs: not really
04:45 nyef: (Although the registers for g84 are at least documented, so I could put together an untested patch for it.)
04:46 imirkin: nyef: don't worry too much about it... if it's just infoframe contents, just update the data being sent over
04:46 GaivsIvlivs: Aw. Any way I can help nouveau's progress, as a noob?
04:46 imirkin: or are there additional regs that have to be set to configure the various items?
04:46 imirkin: GaivsIvlivs: what GPU do you have?
04:47 nyef: It's the "vendor" or "generic" infoframe that's the issue.
04:47 GaivsIvlivs: GM107
04:47 imirkin: GaivsIvlivs: well, that GPU should largely be working reasonably... with kernel 4.10-rcN you should be able to reclock it
04:47 GaivsIvlivs: I still have this problem with GNOME sessions resetting after a while
04:47 imirkin: and with a mesa tree from HEAD, you should get proper sched info being supplied alongside shader instructions
04:48 imirkin: the big missing feature on GM107 is video decoding and encoding
04:48 GaivsIvlivs: perhaps that's what triggers it?
04:48 nyef: It's not set up at all by the current code, and the regs aren't documented in rnndb or in the source for gf119. Or gk104, but it basically just took a full scan of the relevant register space while in operation and I found it.
04:48 imirkin: they changed the engine around significantly, however we're told that the data layout for all the I/O bits is largely unchanged
04:49 imirkin: nyef: ah. probably have to look at some GF119 traces.
04:49 imirkin: nyef: usually it's the base offsets that move around
04:49 imirkin: but the actual layout of the regs remains
04:49 GaivsIvlivs: I really don't know what causes my sessions to reset, but it doesn't happen on the proprietary driver
04:50 imirkin: GaivsIvlivs: there are tons of deficiencies in the nouveau software
04:50 nyef: Hardly need a trace, more need to read out all of the registers in the HDMI area and look for something that "seems like an infoframe control".
04:50 GaivsIvlivs: Any way I can help, with info?
04:50 imirkin: nyef: that requires the hardware... actually i think hakzsam_ has a GF119.
04:51 imirkin: GaivsIvlivs: not immediately that i can think of. fwiw i have a GM107 plugged in right now (as a secondary GPU)
04:51 GaivsIvlivs: imirkin how do you have it set up? nouveau?
04:51 imirkin: GaivsIvlivs: yes
04:52 GaivsIvlivs: Any problems? What kind of system? Outputting to monitors?
04:52 imirkin: heh. i don't have a monitor attached to it - i just have it plugged in for testing. my main monitor is powered by a GK208
04:52 GaivsIvlivs: that works with nouveau?
04:53 imirkin: worksforme
04:53 nyef: imirkin: Exactly. It requires the hardware. Hence, I've gotten about as far as I can on the kernel side. (-:
04:53 GaivsIvlivs: what's your distro
04:53 imirkin: nyef: but if you look at a trace that was already recorded, you could infer it by just looking at the trace without having the hardware
04:53 imirkin: GaivsIvlivs: gentoo, although i don't know how that might matter
04:53 nyef: If, and only if, it touches that infoframe usefully.
04:54 imirkin: nyef: yeah, that would matter.
04:54 GaivsIvlivs: who knows, with the ways things could be set up on the backend
04:54 nyef: And the only use that I'm currently aware of for that infoframe is 3D stereoscopy.
04:54 imirkin: GaivsIvlivs: i don't use gnome or anything of the sort made in the past 15 years :)
04:54 GaivsIvlivs: what DE?
04:55 imirkin: no DE
04:55 imirkin: i use WindowMaker as a window manager
04:55 imirkin: nyef: what am i looking for again?
04:57 GaivsIvlivs: I just don't know. I've tried fresh installs with kernels 4.5 through 4.9, all reset sessions after a while particularly when getting to heavy graphics loads.
05:01 nyef: imirkin: Something in the infoframe register space for whatever connector is active that "looks like" an infoframe control register, but isn't already accounted for. In my case, it was an 0x200 in a sea of zeros.
05:01 imirkin: i'm looking for 0x616714 + n*0x800
05:02 nyef: Yeah, about that. That'll be the AVI infoframe control.
05:02 imirkin: which means hdmi :)
05:02 nyef: Right.
05:03 imirkin: doesn't look like i have a GF119 trace plugged into hdmi =/
05:03 nyef: There may-or-may-not be a read+write of, say, 616730, as that's the next-likely-address, but that's pure guesswork and dark-stabbing.
05:04 imirkin: (and GF117's don't have a disp unit)
05:04 nyef: ... they don't?
05:04 imirkin: no, they're 3d-accel only
05:04 nyef: Ah.
05:05 nyef: nvd7?
05:05 imirkin: nvd7 == GF117
05:05 nyef: nvkm/engine/device/base.c sets them up as having a gf119 disp.
05:12 imirkin: yeah, but it's fused off
05:13 imirkin: none of them have an actual disp afaik
05:25 nyef: So, the registers are there, but they don't do anything useful?
05:29 imirkin: no, the whole disp thing is fused off
05:29 imirkin: and is reflected as such in 22100 or whatever that reg is
05:31 imirkin: nope. TK1 still dies pretty instantaneously.
05:33 imirkin: ok. final effort. let's try tegra_defconfig.
05:58 imirkin: hmmmmm.... tegra_defconfig just might be working
05:58 nyef: Good news / bad news, huh?
05:59 imirkin: gnurou: next time you need to tell me to stop trying to be clever and just do what you say.
05:59 imirkin: anyways, it's stayed up in the past. time will tell. so far it's encouraging though.
07:40 imirkin: gnurou: btw, i can't appear to get glamor to load with your renderonly patch - was it supposed to work?
07:43 imirkin: gnurou: oh i see... you have some extra stuff on your renderonly branch
07:50 imirkin: gnurou: hm. still doesn't work. fails with "failed to bind extensions"
08:00 imirkin: gnurou: ugh. rebuild issue.
08:05 imirkin: gnurou: drmPrimeFDToHandle() failed: Inappropriate ioctl for device -- seeing some of those in X
08:10 imirkin: fancy. TK1 gets ES 3.2 with my advanced blend patches.
08:33 pmoreau: (And images are building again!)
08:35 imirkin: yay!
08:45 gnarface: would it be possible for me to maybe use xvmc to accelerate video playback steam ("in-home" streaming feature that otherwise uses VDPAU)
08:46 gnarface: (assuming VDPAU isn't working, because its one of those G92 cards
08:46 gnarface: )
08:47 imirkin: gnarface: yeah, although xvmc only does mpeg1 and mpeg2
08:48 imirkin: gnarface: you will have to set NOUVEAU_PMPEG=1 in the environment to make use of that functionality (in addition to all the regular xvmc setup)
08:48 gnarface: hmmm, may not help for steam in-home streaming
08:48 gnarface: which i think is h264?
08:49 imirkin: highly likely, yeah
08:51 gnarface: i don't suppose we could just beg the nvidia people to show us what's wrong with the firmware initialization on that card?
08:51 gnarface: does that ever work?
08:51 imirkin: you can beg all you want
08:51 imirkin: i've asked questions in the past, a small fraction of which have gotten answered
08:52 imirkin: unfortunately as i don't have the hardware, it's much more difficult for me to experiment
08:54 gnarface: its not something you could do remotely, is it?
08:54 imirkin: not without complete access to the system, including power
08:55 gnarface: well, remote reboot would be easy to arrange
08:55 imirkin: tbh i've gotten too lazy for dealing with stuff like that
08:56 gnarface: i don't really blame you
08:56 gnarface: i'd consider sending it to you if i replaced it with something else
08:56 gnarface: but that doesn't help me much, if i have to replace it
08:58 gnarface: too bad there's no steam for raspberry pi
10:43 thum: Does Nvidia's NVS 810 work with nouveau? It is based on GM107 chips which are mentioned to be working on the wiki, I don't find information about the specific card though. Can someone help please?
11:18 aaaa: Hello i want know: if i set 1 pwm1_enable and 20 pwm1 and if temp of gpu is very high (example in game), whats happening ? fan switch to auto (secure mode ?) or stay on manualy 20 ?
11:18 aaaa: gtx 770, 4.10-rc3, thanks reply.
16:58 imirkin: gah. i think that 0x1690 lost its ability to control the zero_wins thing on nvc0 :(
17:00 imirkin: [6034965.735825] nouveau 0000:02:00.0: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] ch 6 [007f872000 X[1645]] subc 0 class a197 mthd 1690 data 00010000
17:00 imirkin: or maybe it's just gone on kepler+?
17:01 imirkin: ah yeah. gone on kepler+. super.
17:05 mupuf: what is this 1690?
17:05 mupuf: or, what is it doing?
17:05 mupuf: zero_wins is related to voting?
17:08 imirkin: mupuf: marked as ISA_FLAGS for nv50 iirc
17:08 imirkin: basically a few global options for stuff. but at least the zero wins flag appears gone on kepler. maybe the whole reg changed.
17:09 imirkin: no worries though - i'm just going to start setting the FMZ flag on FMUL/FFMA :)
17:09 mupuf: maybe that will fix some piglit tests
17:10 mwk: mupuf: zero_wins is a flag affecting mul instruction on Tesla and likely Fermi
17:10 mwk: it makes 0 * Inf and 0 * NaN return 0
17:10 mwk: and 0 * -0 FWIW
17:11 mupuf: ah! Got it
17:11 mupuf: thx
17:21 imirkin: gnurou: testing with your patches on a regular desktop gpu leads to crashes - renderonly_scanout_for_resource calls a null function.
17:27 imirkin: gnurou: the "ro" struct remains set to all NULL
18:15 imirkin: hakzsam_: what kind of testing did you have in mind?
18:16 hakzsam_: imirkin: monitor warps_launched with glxgears, and show me the value at least :)
18:17 imirkin: ok. i'll double-check that one. a bunch of stuff did seem to be returning values...
18:17 imirkin: it was in the 20-60k range, depending on the one i checked
18:18 hakzsam_: sure, the kernel should work, but the question is: do the values aren't crazy?
18:18 hakzsam_: if warps_launched is good, that's a good start
18:20 imirkin: what's a reasonable quantity?
18:20 imirkin: iirc it was 20k
18:20 hakzsam_: should be 2.5k IIRC
18:20 hakzsam_: 20k is not so crazy but a bit high
18:21 hakzsam_: you can also compare threads_launched vs warps_launched
18:21 hakzsam_: threads_launched = warps_launched * 32
18:21 imirkin: ok
18:21 hakzsam_: that's a good metric as well
18:22 imirkin: it's off now, but i'll boot it up in the next 30 mins
18:22 hakzsam_: but it's hard to be 100% sure without tracing the blob
18:22 hakzsam_: ok
18:22 imirkin: that's the problem though - how can i trace the blob?
18:23 imirkin: i don't think any of those dev tools are available for tegra. dunno
18:23 hakzsam_: I don't know tegra, but if blob exposes cuda+cupti we can trace it
18:23 hakzsam_: [with cupti_trace in envytools]
18:25 imirkin: ah ok. hm. i think L4T does have cuda. dunno about cupti, but seems reasonable that it's there too
18:25 hakzsam_: cupti should be part of cuda
18:25 imirkin: although i won't have time to play with that
18:25 imirkin: but we could leave it to someone else at a later time.
18:26 hakzsam_: yep
18:26 imirkin: [i'm kinda guessing mmt won't work on arm...]
18:29 mwk: imirkin: that's an interesting question, actually. tried it?
18:30 imirkin: mwk: no, just assuming.
18:30 mwk: valgrind supports a lot of arches...
18:30 imirkin: i have used valgrind on there - works ok.
18:30 imirkin: [not on the tegra specifically, but on some qcom boards]
18:38 mslusarz: iirc mlankhorst used mmt on arm
18:50 mwk: well
18:50 mwk:got bored
18:51 mwk: http://0x04.net/~mwk/gpu.png
18:51 imirkin: thum: GM107 should work. each chip is used in tons of diff cards with different names, but what's important is the chip. it's very rare that some specific board doesn't work whereas others using that same chip do work. it does happen on occasion though.
18:51 imirkin: mwk: hahaha
18:52 mwk: well, bored
18:52 mwk: I really need that drawing to make sense of the NV10-NV40 clusterfuck :p
18:52 imirkin: mwk: i thought GF110 came out before GF114/GF116...
18:52 imirkin: mwk: and where's GF117? :(
18:52 mwk: oh, forgot about GF117.
18:53 mwk: right
18:53 mwk: it's all speculative on Fermi and up anyhow :(
18:53 mwk: and I gave up on Maxwell
18:53 imirkin: hehe
18:53 imirkin: note that GK20A has SM35 ISA, like GK110/GK208...
18:55 mwk: it has different classes though, right?
18:55 mwk: it may warrant an "unreleased common ancestor" node...
18:55 imirkin: than either, yes...
18:55 imirkin: but NVEA_3D_CLASS > NVF0_3D_CLASS
18:55 mwk: curiouser and curiouser.
18:56 imirkin: e4 = 0xa097, f0 = 0xa197, ea = 0xa297
18:56 mwk: IIRC GK20A is missing something that's on GK110 though...
18:56 mwk: but I may be misremembering
18:56 mwk: well, aside of the fact that GK20A is missing a lot by virtue of not being a full GPU
18:57 imirkin: but it somehow has the a0c0 compute class, not a1c0
18:57 mwk: ah, right, that
18:57 mwk: so... dashed GK110 -> GK20A line?
18:57 imirkin: so apparently ISA isn't tied to the class :)
18:57 mwk: oh, and I missed GK210 as well
18:57 mwk: not that anybody actually knows wtf that is
18:58 imirkin: and like GK208 it uses fuc5 while iirc GK110 still uses fuc3 for ctxsw fw
18:58 imirkin: it's a K80 :)
18:58 mwk: yeah, but I don't think we even know the NVxx id
18:58 imirkin: yeah, dunno
18:58 mwk: let alone what it looks like :p
18:59 mwk: ok then
18:59 mwk: I'll add a GK208 - - -> GK20A line
18:59 imirkin: i think that's sensible
19:00 mwk: and as for GF110
19:01 mupuf: mwk: wow, you indeed did get bored :D
19:01 mwk: I found no difference at all between GF104/GF106 and GF114/GF116
19:01 mwk: while GF110 has a new compute/3d class duo
19:02 mwk: mupuf: yup, and discovered https://draw.io/
19:02 mupuf: oh, nice!
19:03 mupuf: hey, it really is quite good!
19:04 mwk: yeah
19:06 mwk: the google drive integration is supremely annoying
19:07 mwk: actually, all storage backends are
19:07 mwk: but the drawing functionality itself is great
19:08 mwk: *and* it works offline
19:10 mwk: anyhow
19:10 mwk: drawing a schema didn't help NV10-NV40 at all :p
19:22 mwk: updated
19:39 mwk: well
19:40 mwk: and now let's try to find out something about ZCULL
19:40 mwk: it's about fucking time
19:45 mupuf: mwk: yeah, it is pretty high on the list of stuff that need to be implemented :)
19:45 mupuf: no idea what this would require
19:46 mwk: mupuf: um, you know I'm talking about Celsius ZCULL, right? :p
19:48 mupuf: I know ;)
19:48 imirkin: mwk: fwiw nouveau supports operating those methods to a limited extent
19:48 mupuf: but hey, I guess that once one is figured out, that should teach us the basics
19:48 imirkin: mupuf: it varies greatly between generations
19:49 mwk: imirkin: I saw what nouveau is doing with these methods, and it doesn't match what I already know about Celsius
19:50 mwk: so something is horribly wrong
19:50 imirkin: mwk: that's excessively likely.
19:50 mupuf: imirkin: well, maybe if I knew what it is trying to do, then it would make more sense
19:51 imirkin: mupuf: same thing as HiZ (in function, not always in impl)
19:59 mupuf: So, ZCULL requires to render the frame first with depth-only as an output. Then make mip-maps of this resulting texture and use it to know which objects should be culled or not?
20:00 mwk: um what?
20:00 imirkin: mupuf: heh. no, it does not require that.
20:00 mwk: no... it's completely transparent
20:00 mupuf: ok, then I really do not know :D
20:00 mwk: it sort of caches min/max Z values for each tile of the screen
20:00 mwk: and if the rendered primitive is guarenteed to be occluded, it's rejected immediately
20:01 mupuf: I see, quite nice
20:01 mwk: otherwise, it goes on
20:01 mupuf: then yes, no wonder it is heavily chipset-dependent
20:01 mwk: so, no texture fetches, no pixel shaders, no per-pixel memory reads
20:01 mupuf: and everything is fixed function
20:02 mwk: yeah, zcull is most definitely not programmable
20:02 mupuf: how many tiles are there?
20:02 mwk: *shrug*
20:02 mupuf: ~16, more?
20:02 mwk: fuckloads, I'd guess
20:02 mwk: 8x8 pixels or something
20:02 mupuf: oh wow, and where is this stored then?
20:02 mwk: that's a good question
20:03 mwk: on NV17-NV3x, you have a buffer in VRAM
20:03 mwk: on Curie and Tesla, there's special SRAM on the GPU that you've got to manage specially
20:03 mupuf: and here is our texture fetch :D
20:03 mupuf: SRAM makes sense
20:03 mwk: and on Fermi, there's a buffer in VRAM again, maybe?
20:04 mwk: except Curie clearly still has *something* in VRAM
20:04 mwk: and Fermi seems like it still has *something* in SRAM
20:04 mwk: so, who the fuck knows
20:04 mwk: it could be a weirdo mixture
20:04 mwk: and I'm not entirely certain that Celsius/Kelvin/Rankine don't have SRAM
20:05 mupuf: :p
20:05 mwk: oh, and all signs on heaven and earth tell me that NV20 has some sort of ZCULL too, even though it clearly doesn't store any data in VRAM
20:06 mupuf: well, maybe they used 4 tiles ;)
20:06 mupuf: and used registers
20:06 mwk: so - mysterious.
20:06 mupuf: even one tile would be quite good
20:07 mupuf: not for outside maps
20:07 mupuf: but for doom-like levels, that could work
20:14 mupuf: fuck, can't remember what is word to say that you consolidate two implementation that were mostly the same into one
20:14 mupuf: what is the word for this?
20:15 imirkin: refactor
20:15 mupuf: hmm, not exactly the word I was looking for
20:16 mupuf: but that will do, thanks Ilia!
20:17 mwk: mupuf: single tile is no good, the only way you could usefully update that is if you had the whole screen covered by one primitive
20:17 mupuf: or if you have corridors, it is not one primitive, but it may still hide a lot of other primitives
20:17 mupuf: oh! I just got why you need both the min and max value
20:18 mupuf: didn't think about culling what is behind
20:18 mupuf: oh, but you can just cull everything that is behind, always
20:21 mwk: yeah, but the important thing is, you have to keep your values up to date
20:22 mwk: which can only be done when a tile is covered by a single prim
20:22 mwk: or at least a small amount
20:33 imirkin: this is crazy! i finally fixed the tomb raider: underworld issue!
20:33 glennk: from what i recall early gen zcull/hiz on nv/radeon only supported a single framebuffer at a time, with a small on chip memory for either min or max z value per tile
20:33 imirkin: apparently depth bias was being applied without a depth buffer and upsetting some assumptions
20:34 imirkin: although from everything i can tell in the GL spec, the bias should actually be applied when there's no depth buffer...
20:34 glennk: and z was reduced precision
20:36 mupuf: imirkin: oh dear, how did you figure this out?
20:37 imirkin: mupuf: i didn't - the nine guys tracked down an issue to something similar, and i figured i'd implement it properly and see if it fixed tr:u, since i remembered that being a weird depth issue
20:37 imirkin: and it did ;)
20:38 thum: imirkin: thank you! =)
20:44 mupuf: kuddos to them then, yeepee!
21:18 imirkin: heh. nevermind. it just magically fixed itself.
21:18 imirkin: the depth bias thing was a red herring
21:44 mwk: eh.
21:44 mwk: of course things can't be sane
22:07 nyef: Heh. I haven't heard of non-8-bit bytes outside of a Lisp context in ages. (-:
22:10 mwk: nvidia has plenty.
22:10 mwk: I've seen 16-bit, 32-bit, 30-bit, 40-bit, 128-bit
22:10 mwk: oh, and 24-bit
22:34 imirkin: urgh. the thing that fixed that tomb raider bug was a compiler rejiggering of something.... gr.
22:35 imirkin: commit b04ef3c08a288a5857349c9e582ee2718fa562f7 :(
22:40 RSpliet: is that the one that broke Shadow Warrior?
22:40 RSpliet: "broke"
22:42 RSpliet: Oh, from the sound of it there's probably still some problems with complex control flow. Surely pmoreau will hunt those down with his OpenCL work ;-)
22:45 imirkin: no, shadow warrior is unrelated
22:45 imirkin: shadow warrior is a RA failure
22:46 imirkin: none of these have complex control flow
22:53 kuzetsa: other than scheduler things ... is there any change to x11-drivers/xf86-video-nouveau by using a different kernel?
22:54 kuzetsa: like the modesetting stuff doesn't really do any heavy-lifting, I thought
22:55 kuzetsa: or is there a portion of kernel code used by nouveau which will have major performance impact if I switch to a 4.9.x kernel?
22:55 imirkin: can you try to rephrase your question? you're mixing a ton of different and seemingly unrelated concepts and i'm having trouble telling what it is that you're really asking...
22:55 kuzetsa: either way - for the sake of development, I'm updating kernels and not sure if I'll need to rebuild nouveau or what
22:56 imirkin: changing kernels should not require changing any userspace components.
22:56 kuzetsa: nod
22:56 imirkin: and similarly, userspace components should be compatible with "all" kernels
22:56 kuzetsa: allright
22:56 imirkin: (excepting kernel module versions from before nouveau was mainlined, but that was a while back)
22:56 kuzetsa: hmm
22:57 imirkin: iirc 2.6.36 or so
22:57 imirkin: either way, i would not expect that you'd get any serious improvement in nouveau from updating from 4.4.x to 4.10-rcN
22:58 kuzetsa: well I'm [re]building a newer kernel, and I'm not entirely sure what impact this will have on nouveau since I don't actually know why the kernel has to be configured to enable support for nouveau if [most of?] the relevant code is actually userspace code
22:58 kuzetsa: other than providing a syscall interface or whatever
22:58 imirkin: there have been a handful of stability fixes, although it's likely they were tagged for stable, and also likely that they were included in 4.4.x
22:58 imirkin: isn't that the purpose of all drivers... to provide a syscall interface?
22:58 kuzetsa: huh?
22:59 kuzetsa: but the nouveau drivers seem to be userspace not kernelspace
23:00 kuzetsa: lspci -k | grep nouv ---> Kernel driver in use: nouveau
23:00 kuzetsa: I'm super confused
23:01 imirkin: nouveau is not a single piece of software
23:01 kuzetsa: so is the driver itself reside in the kernel (as a module or otheriwse) but the x11-drivers/xf86-video-nouveau package is just the interface to use it?
23:01 imirkin: it is a collection of pieces of software working in tandem.
23:01 kuzetsa:head-desks
23:02 kuzetsa: at this rate, reading the relevant kernel source might give me my answer quicker :(
23:03 imirkin: i'm still unsure as to what the question is.
23:04 imirkin: is the question, "what is nouveau"?
23:04 imirkin: or is the question "what is the purpose of a kernel driver"?
23:04 kuzetsa: a little of both?
23:04 imirkin: or is the question "why do we have userspace software instead of doing everything in the kernel"?
23:04 kuzetsa: sure, that too
23:08 kuzetsa: partly, I'm trying to account for some criticism (at some point in the past 36 hours) where you called 4.4.x an ancient kernel -- if the kernel portion(s) of nouveau are responsible for a fair bit of the "heavy lifting", this seems a lot more relevant suddenl
23:08 kuzetsa: *suddenly
23:08 imirkin: kuzetsa: this seems like a non-terrible explanation of what's going on - https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/
23:08 imirkin: kuzetsa: my main argument was that 4.4.x was ancient, not that there was anything wrong with it
23:08 kuzetsa: thanks
23:09 imirkin: and when talking to upstream developers, the only thing of relevance is what's in Linus's HEAD, the tree with the "next" pull you're sending to him, and maybe, just maybe, the last-released kernel version Linus tagged.
23:10 kuzetsa: uhg
23:10 kuzetsa: that particular article doesn't seem to even mention nouveau :(
23:10 imirkin: coz your questions have nothing to do with nouveau
23:10 kuzetsa: and it covered things I already knew
23:10 kuzetsa: ...
23:11 imirkin: it's the same answer for intel, radeon, nouveau, every single graphics driver [with an accel component]
23:11 kuzetsa: I give up
23:11 imirkin: it's the same components, they all interact in the same ways with each other, etc
23:12 imirkin: or perhaps i still haven't understood your question :)
23:12 kuzetsa: I'm reading the kernel source portion which gets flipped on when nouveau is enabled via menuconfig - as well as the source for the kernel object, and running a diff from 4.4.x to 4.9.x
23:12 kuzetsa: it'll be a less frustrating (and far more informative) answer to what I'm wanting to know :)
23:12 imirkin: excellent.
23:12 kuzetsa: not really
23:12 kuzetsa: it's your fault I'm doing this
23:13 kuzetsa: :P
23:13 imirkin: you can also look at 'git log v4.4..origin/master -- drivers/gpu/drm/nouveau' if you're interested in what changed
23:14 imirkin: although obviously nouveau also relies on a lot of helpers in drm and ttm
23:14 imirkin: [ok, maybe not obviously. but it does.]
23:15 kuzetsa: I'm familiar with the drm acronym (in this context, it ironically isn't related to digital-rights-management) but haven't really looked at a lot of background info about ttm
23:16 kuzetsa: searching for "drm video" in a search engine would almost certainly give some kind of license/encryption-related answer
23:16 kuzetsa: do you think ttm video is unambiguous enough that I won't run into issues?
23:17 kuzetsa: translation table maps?
23:18 kuzetsa: https://lwn.net/Articles/257417/ <<< this thing, right imirkin?
23:18 kuzetsa: something about memory management?
23:20 mwk: yay, I finally got the "clear clipid" command to do something
23:20 mwk: too bad it only happened once in 100000 random testcases, and I have no idea which one
23:21 glennk: clip id? is that related to window id?
23:21 mwk: yeah, same shit, different name
23:22 glennk: do they still actually have that in hardware these days, or is this just on the earlier chips?
23:23 mwk: still there as of Kepler
23:23 mwk: no idea about Maxwell/Pascal
23:23 glennk: guess there could still be some workstation apps using it
23:23 mwk: *shrug* I suppose it's cheap...
23:27 mwk: alright, so "clear clipid" does, in fact, write to the clipid buffer, good
23:28 mwk: I suppose I'd have to figure out valid settings for that before I get a better success rate than one in 100000
23:28 mwk: but the "clear zeta" command doesn't even bother to validate whether the zcull memory or zeta surface are set up
23:29 mwk: so... it works entirely by writing the top level of zcull pyramid in SRAM? that'd make some sense
23:31 glennk: i think its just two levels on the first few chip generations, sram and then regular z buffer, with a single test per tile
23:32 mwk: well
23:32 mwk: this is NV17, and it definitely has something extra in VRAM
23:33 mwk: and since clear doesn't affect it, nor the normal z surface, this means there should be SRAM as well
23:33 mwk: so... 3 levels at least?
23:33 mwk: but then, the first generation with zcull would probably be NV20, which doesn't have anything in VRAM...
23:35 glennk: nv17 came after nv20 afaik
23:35 mwk: yeah, it did
23:35 mwk: a crazy frankenstein of NV11 and NV25
23:35 glennk: i think it more or less has the same zcull as nv2x
23:36 mwk: nv2x is kind of ambiguous
23:36 mwk: NV20 and NV25/NV28 are clearly very different when it comes to zcull
23:37 mwk: I think NV17 zcull should be based on NV25's, but not as well-integrated?
23:37 mwk: I mean, Celsius didn't even have a "clear" command, they just bolted a simple one on for zcull..
23:38 mwk: and you still have to clear the color buffer on your own, with the 2d enginre
23:38 glennk: i just remember there being all sorts of restrictions what apps had to do to get zcull
23:39 glennk: well many games don't really need to ever clear color buffer, only z, so that would make sense
23:39 mwk: true
23:44 mwk: well
23:44 mwk: guess I'd better add the RDI memories to my hwtest model
23:46 imirkin: kuzetsa: ttm is used for managing vram and gart memory and moving buffers back and forth
23:49 kuzetsa: hmm
23:50 imirkin: (between system, vram, and gart memory)
23:50 kuzetsa: optimus hybrid graphics, so I should really pay attention to the internal kernel gizmos and bits which make PRIME possible
23:51 imirkin: that'd be dma-buf for DRI3 and flink for DRI2
23:51 kuzetsa: like - my non-nouveau GPU (intel HD3000) probably does use some of that gart/TTM stuff
23:51 imirkin: no
23:52 kuzetsa: no?
23:52 imirkin: i915 doesn't use ttm at all, and implements the gem api directly
23:52 imirkin: also it's a UMA controller, so the whole memory domain distinction stuff is a little lost on it
23:52 kuzetsa: hmm
23:53 RSpliet: skeggsb: ping on pushing forward the fix for NVAA/NVAC HDMI display regression to current 4.8, 4.9 and 4.10 branches?
23:54 skeggsb: RSpliet: yeah, it'll go in my next req to airlied
23:55 RSpliet: skeggsb: Thanks. be advised that current Fedora kernels are broken too... you might get labbott mad enough to just shoehorn the fix into the current kernel tree?