04:05 mew007: hello. Is anybody here?
04:05 mew007: Are*
04:08 mew007: skeggsb_: r u here?
04:23 skeggsb_: mew007: only very briefly
05:40 imirkin: mlankhorst: "drm/nouveau: dont switch vt on suspend" -- what does that fix?
05:41 mlankhorst: nothing, just gets rid of switching to suspend console..
05:41 mlankhorst: similar to i915 :p
05:42 mlankhorst: * Drivers can indicate support for switchless suspend/resume, which can
05:42 mlankhorst: * save time and flicker, by using this routine and passing 'false' as
05:42 mlankhorst: * the argument. If any loaded driver needs VT switching, or the
05:42 mlankhorst: * no_console_suspend argument has been passed on the command line, VT
05:42 mlankhorst: * switches will occur.
05:43 imirkin: ah ok. there are some people for whom fbcon is broken on resume
05:43 imirkin: i wondered if it was in reaction to that
05:44 mlankhorst: naw
05:44 mlankhorst: it just prevents switching to the suspend console
05:57 mlankhorst: hm woops turns out the screen blacking needs to be removed then :P
06:00 mlankhorst: oops some more pieces are missing
06:08 imirkin: yay for testing
06:14 mlankhorst: worst part was copy/pasting from the manual then finding out you had no_console_suspend specified because of serial console..
06:14 mlankhorst: :-/
06:21 mlankhorst: actually it works on fbcon, but not with Xorg..
06:24 imirkin: it's really annoying when debugging features prevent you from doing debugging...
06:24 mlankhorst: well it works, sort of, but I get a black screen until I vt switch
06:24 mlankhorst: and mouse seems to be a fully 32x32 white spot in the upper left corner until I move it
06:25 imirkin: sounds like init of some things is lacking
06:25 mlankhorst: yeah, mouse cursor and page flipping probably
06:27 mlankhorst: when no vt switching Xorg doesn't know suspend/resume occured, so we have to be more careful in that case..
06:28 imirkin: well presumably on init back you should restore whatever fb/cursor were being displayed before...
06:29 mlankhorst: yeah, one thing at a time..
06:35 mlankhorst: hm crazy enough it seems that nv04 display supports restoring cursor, but nv50 doesn't :p
06:37 imirkin: nv04 hasn't been refactored/rewritten as much :p
06:41 mlankhorst: true, but this makes things harder.. tons of places I could stuff the cursor suspend/resume, but not sure which one is right
06:43 imirkin: where does nv04 do it?
06:43 imirkin: sounds like something for nv50_display.c
06:43 mlankhorst: in nouveau_display.c
06:45 mlankhorst: I guess the cheating way out is to hide the cursor..
06:45 mlankhorst: but probably not
07:14 tobijk: hey imirkin, have you already had a look why the unigines are broken with the nv50 backend?
07:14 imirkin: tobijk: is it broken? i thought it just ran out of ram on whoever's box was testing
07:14 imirkin: er, vram
07:14 imirkin: did it ever work on that particular machine?
07:14 tobijk: well yeah, all unigines run out of vram
07:15 tobijk: i *think*, but am not sure
07:16 imirkin: i would guess that it's an older kernel, not an older mesa
07:16 imirkin: i'd try a pre-3.11 kernel
07:16 tobijk: 3.18.1
07:16 imirkin: i mean -- that it used to work with an older kernel
07:16 tobijk: mhm
07:16 imirkin: i doubt anything in mesa would have changed to affect this
07:30 mlankhorst: oh and my other test system was optimus :P
07:47 mlankhorst: ok cursor works I think..
07:48 imirkin: that's like 50% of it :)
07:50 Leftmost: I'll be getting a GTX 970 in the next few days. I notice the feature matrix shows most things in that family as being WIP. Wondering if there's low-hanging fruit that someone new to nouveau could tackle reasonably.
07:51 mupuf_: Leftmost: There are many low-hanging fruits for this chipset ... but first, you would need to have acceleration
07:51 mupuf_: and right now, this is not available because of nvidia's fw-signing situation
07:52 imirkin: Leftmost: i wouldn't expect anything outside of modesetting to work for a while
07:53 Leftmost: Alright. Anything I can do to help, or is my best bet just to wait for now?
07:54 imirkin: Leftmost: the current hurdle, like mupuf said, is getting acceleration going.
07:55 Leftmost: Right. Just wasn't sure if there was data that could be gathered for that or if it's a matter of people more clever than I working on it.
07:56 Leftmost: Anyhow, thanks for the feedback.
07:56 imirkin: tbh i'm not really sure what the issue is wrt loading blob fw... seems like it should work
08:15 mlankhorst: imirkin: well wasn't it possible to load nouveau fw as long as we don't need to access physical memory?
08:15 imirkin: mlankhorst: no clue what the latest is
08:16 mlankhorst: oh well, EOD :-)
08:41 linas: Hi all ... So .. I've got recurring issues with a dual-card setup, with lots of [TTM] Failed to find memory space errors
08:41 linas: and thought it ws time to get more proactive on this.
08:42 linas: I'm an ex-kernel programmer, and do fancy stuff, but have little/no time ... any suggestions on how to best tackle this?
08:44 imirkin: linas: why dual-card?
08:50 linas: I've got three monitors
08:51 linas: and I'm a cheap-skate and so both cards are old - NV40
08:51 imirkin: ah ok. and how are you using this? xinerama? reverse prime?
08:51 linas: and one is PCI-E and one is plain-old PCI
08:52 linas: don't know what reverse prime is. I guess I'm using xinerama, because randr doesn't work for this setup
08:52 imirkin: hmmm
08:52 imirkin: can you pastebin xorg log?
08:53 imirkin: just want to double-check :)
08:53 imirkin: reverse prime is when primary gpu A renders image to be displayed on secondary gpu B
08:53 imirkin: prime being the usual offloading case (i.e. optimus)
08:53 linas: sure: but first, let me explain: right now X is mostly usable for 1-3 days
08:54 imirkin: sounds like a leak i guess
08:54 linas: then the TTM messages show up, thigs get very slow, and if I don't restart X, it seems to lock up eventually
08:58 linas: its happening right now this may take a moment :-)
08:59 linas: funny thing is, if I step away from the system for a ew hours or overnight, it clears up on its own, for a while
09:00 imirkin: weird
09:01 linas: seems to be some bad interaction involving the desktop-switcher; switching desktops exacerbates the problem
09:01 imirkin: wait, you mean errors like 'Failed to find memory space for buffer 0x%p eviction' ?
09:01 linas: yes
09:01 imirkin: that means it can't find space in system memory to move vram contents into
09:02 imirkin: (so that it can move other contents into vram)
09:02 linas: !?
09:02 imirkin: are you very memory-constrained?
09:02 linas: 32 GB
09:02 linas: and about half of that is marked 'free' at the moment
09:03 imirkin: ok, that's what i was looking for :)
09:03 imirkin: just coz you have 1TB of ram doesn't mean you're not memory-constrained :p
09:03 linas: 27GB free right now, according to top
09:04 imirkin: right, so that should be plenty
09:04 imirkin: but that's what the message means
09:04 imirkin: oh, i bet it's trying to evict from VRAM into GART
09:04 imirkin: which is a _much_ more limited space
09:04 linas: Ahhh!
09:04 imirkin: i think all the info should be in dmesg
09:04 imirkin: if you could pastebin that...
09:05 linas: you still want the Xorg.log pastebin?
09:05 imirkin: wouldn't hurt
09:08 linas: http://pastebin.com/QBen2dqK is xorg.0.log
09:09 imirkin: G72 + NV4A -- guessing the latter is the PCI one (since it's an AGP chipset)
09:11 linas: here's the boot dmesg http://pastebin.com/A1vZKEaY it doesn't show the TTM errs though
09:11 imirkin: well the ttm errors would confirm that it was trying to migrate vram into gart
09:12 linas: I will have to google on how to increase the gart space ... unless you want to give me a clue
09:12 imirkin: how hard would it be for you to flip which gpu was the primary one?
09:12 imirkin: you can't increase gart space
09:13 linas: ah.
09:13 linas: not sure what you mean by "the primary one"
09:13 imirkin: actually, perhaps it'd be sufficient to rearrange the xorg config s.t. NOUVEAU(0) is the NV4A card -- that has 512MB vram (vs 128MB of vram on the G72)
09:13 linas: or "flip".
09:13 linas: I can re-do the xorg.conf file and move the cables around
09:14 imirkin: i don't think you'd even have to move cables around
09:14 imirkin: just redo the order of the Device sections in the xorg config file
09:14 imirkin: s.t. the NV4A one comes first
09:14 linas: OK .. but otherwise leave the left-right ordering alone?
09:16 linas: re gart: no way to change that, even if I recompile the kernel? I guess the cart is limited by what the card can touch, as declared in the pci config registers?
09:16 imirkin: i think it's fine
09:17 imirkin: it's a hw thing
09:17 imirkin: GART was a real thing in AGP-land, however the term was repurposed
09:18 imirkin: basically it's "system memory that the GPU can read/write directly"
09:18 linas: yes, right ... and that's usually declared in pci config rgs
09:18 linas: and is usually read-only :-)
09:18 imirkin: with AGP this was configurable in the BIOS, however with PCIe, all system memory is accessible (or up to the first TB). however gpu restrictions can limit that.
09:19 imirkin: in this case, nv4x limits it to 512MB due to... dma object silliness. might be possible to do more, but nouveau doesn't
09:20 imirkin: nv50+ has gpu-side vm that abstract all that away and can address any system memory
09:23 linas: OK, I've reordered xorg.conf .. now to restart X .. this will take a moment
09:23 linas: any last words?
09:23 imirkin: try to grab dmesg when it happens so that we have some logs to go off of
09:24 linas: ?
09:24 imirkin: the eviction errors
09:24 linas: I've got the existing ones, somewhere in syslog.
09:24 linas: I can dig them out now
09:25 linas: let me do that, before I restart, will be less confusing.
09:33 linas: http://pastebin.com/AJpWhJbY is the very first TTM message, after reboot. I'm surprised it showed up 3 minutes in .. it usually takes days to get to there. anyway, no more TTM messages until the next day (today)
09:33 linas: restarting X now.
09:34 imirkin: whoa
09:34 imirkin: 29MB??
09:35 imirkin: and it's trying to stick it, sequentially, into the 128MB of vram on the G72 card
09:35 linas: ?
09:35 imirkin: can't say i'm _terribly_ surprised it fails
09:35 imirkin: i don't think we ever do any sort of repacking
09:36 imirkin: what's your totaly resolution across the 3 screens?
09:37 linas: 29M. Each screeen is .. I forget 1680x1280 or something like that
09:38 linas: desktop manager loads a dorky background on login .. that could be tiriggering the 29M but even so 29M seems like a lot
09:38 imirkin: ah, so 1680 * 1280 * 3 * 4 = 25M
09:38 imirkin: so... seems "reasonable"
09:39 linas: Ah! OK, yes
09:39 imirkin: but hopefully by reordering the devices in your xorg config, the first gpu would be rendering that bs
09:39 imirkin: and it has 512mb vram
09:40 imirkin: so... more likely to not suck
09:40 imirkin: er
09:40 imirkin: the NV4A gpu
09:40 RSpliet: tobijk: I suspect your texture compression patch added another 2fps to portal perf on my laptop. Nice, we're only 4fps behind the blob now! ;-)
09:41 imirkin: RSpliet: awesome... i guess it uses MS? i think 4x MSAA is the sweet spot wrt maximizing texture compression gains
09:41 imirkin: when you go to 8x some stuff gets disabled
09:41 RSpliet: imirkin: no idea, default settings O:-)
09:42 imirkin: er wait, i lied -- 4x and 8x are always supported
09:42 imirkin: 2x sometimes isn't
09:42 RSpliet: I was about to launch dota2 instead to see what happens
09:42 imirkin: (for color RB's)
09:43 imirkin: RSpliet: also perhaps the mul sat modifier improved things? =]
09:43 RSpliet: imirkin: you mean those 3 instructions shaven off the shaders? :p
09:43 tobijk: RSpliet: nice to know, my system is way to memory constrained to really test something useful :)
09:44 imirkin: RSpliet: hehehe. maybe it was my change to let sub use sat too
09:45 tobijk: mh would be good to know, what brought the improvement
09:45 RSpliet: I'm just gonna go with tex compression :p
09:47 imirkin: yeah, i was just kidding ;)
09:47 imirkin: those sat's just make for slightly cleaner code, i'm sure that outside of very contrived workloads, they have no effect
09:48 tobijk: somebody, not me, should go fix the "spill code inserter" now
09:48 tobijk: i failed in doing that :/
09:50 imirkin: what's not working about it?
09:50 tobijk: i run out of spill candidates...
09:50 imirkin: shader
09:50 tobijk: erm wait
09:50 imirkin: file a bug with the TGSI that triggers the issue (and specify the target arch)
09:51 tobijk: oh no, it was with a change i tried to make ;-)
09:51 imirkin: ah
09:51 tobijk: the sort uses thingy, if you remember
09:52 imirkin: yeah
09:53 tobijk: i guess that would bring some performance, as we'd have to wait for less memory cycles
09:53 tobijk: RSpliet: hint -^ :D
09:57 imirkin: only for giant slow shaders
09:58 tobijk: well at least dota got some of these
10:16 imirkin: RSpliet: if you want a more involved optimization to work on, try the one i allude to in http://lists.freedesktop.org/archives/nouveau/2015-January/019645.html
10:16 imirkin: RSpliet: basically if we're comparing a value with an immediate, and that value comes from a cvt int -> float (or vice-versa), then we can get rid of the convert by changing the arguments to the set
10:17 RSpliet: imirkin: I was just looking at that patch :p
10:19 imirkin: i looked at doing that opt for a bit last night but decided i was lazy
10:26 imirkin: RSpliet: you can look at bin/shader_runner tests/shaders/glsl-fs-frontfacing-not.shader_test -fbo -auto
10:26 imirkin: for a simple example
10:32 RSpliet: imirkin: shouldn't there be a 4-byte encoding for MAD in NV50?
10:32 RSpliet: for FMAD
10:32 RSpliet: or actually
10:33 RSpliet: that one seems to be there
10:33 RSpliet: but no with IMM
10:42 imirkin: there's never a 4-byte encoding with an imm...
10:59 linas: imirkin: I'm back. multiple remarks, though ...
11:00 Leftmost: I'm guessing there's also not much non-chipset-specific stuff I could work on and actually test with a Maxwell card.
11:00 linas: 1) I never had the TTM problem with ubuntu 12.04, with the same exact card setup & xorg file. So this is a regression in 14.04
11:01 linas: 2) reading dmesg more carefully, I see that TTM claims that here is 2GB available to it ...
11:01 imirkin: Leftmost: certainly not until acceleration is working...
11:01 imirkin: linas: different ttm domains have diff quantities of memory... there's vram, gart, and sysram
11:01 Leftmost: Right. Ahh well, thanks.
11:02 linas: 3) Reading dmesg further, it cleams that both the 128MB and the 512MB card both have a 512MB GART
11:02 imirkin: linas: that's right
11:03 linas: 4) I needed to re-order not the Devices sections, but the order of the cards in the XServer layout section
11:04 imirkin: ah yeah, that makes sense
11:04 linas: 5) I've tried newer kernel.org kernels, but these fail with variety of different errors ...
11:05 imirkin: that's... unfortunate
11:05 imirkin: all the buffer management stuff has seen a bunch of changes in... 3.16 or so, iirc
11:06 linas: So what concerns me most is pint 1) it seems to be a regression, somewhere, and 5) random new kernels aren't happy with default ubuntu 14.04 X11+mesa
11:06 imirkin: what kernel did 12.04 ship?
11:06 linas: I tried 3.17rc2 ...
11:07 linas: (back when 3.17rc2 was new)
11:08 imirkin: perhaps try a released kernel?
11:08 imirkin: i.e. non-rc
11:10 linas: I may try that come a rainy day and i'm desperate .. but usually its very unlikely that a nouveau bug would get fixed between the rc and the final version
11:11 imirkin: depends on the bug
11:11 linas: I'm not sure what kernel ubuntu 12.04 had ... it currently seems to be running 3.2.0 (based on oanother machine I have)
11:12 imirkin: esp e.g. nv40 gets broken a lot in initial dev since nobody tests with it
11:12 imirkin: and then -rc1/2 come around, and people notice bugs
11:12 linas: ah!
11:12 linas: so your advice is to just do it, and make waves if it doesn't work?
11:12 imirkin: sometimes takes longer
11:12 imirkin: e.g. AGP was broken for a full release or two
11:13 imirkin: yeah
11:13 imirkin: there's a lot of diff hw combinations, we don't have all of them, and don't test on all the ones we do have
11:13 linas: and the newer kernels should work, in theory, with the stock mesa+glx+xorg+drm
11:13 linas: ?
11:14 imirkin: that's the idea
11:14 imirkin: sometimes stuff gets broken, but ideally we fix it
11:14 imirkin: when we find out about it :)
11:16 imirkin: not to say that the stock userspace you have is bug-free either, but kernel changes should ideally not make it more or less buggy
11:17 linas: OK. Is it best to chat here, or open bug reports on freedesktop.org ?
11:17 linas: or maybe both .. I guess
11:18 imirkin: start here
11:18 imirkin: then move up to filing bugs depending on the discussion
11:18 imirkin: there isn't some giant team at play here...
11:19 imirkin: a small handful of volunteers + 1 ~full time paid dev
11:19 linas: Well, either my ttm problems will recur shortly .. or they won't ... I think I'm done for now
11:19 linas: heh I understand. I maintain some packages myself
11:20 linas: moving my sources to github has completely, totally changed how people interact with me, w/ the project. For the better. quite amazing, actually
11:21 imirkin: is your project RE'ing hardware? :)
11:22 RSpliet: imirkin: there is if you take away the actual imm
11:22 imirkin: RSpliet: hm? there's a 4-byte fmad
11:22 imirkin: RSpliet: what are you saying is missing?
11:23 RSpliet: 4byte fmad with IMM behind it (8 byte total)
11:23 linas: one is, one isn't ... the hardware one is ROS-related
11:24 imirkin: RSpliet: yeah, look at tabi
11:24 imirkin: { 0xe0000000, 0xf0000000, N("add"), T(sm1sat), N("f32"), SDST, T(sm2neg), SESTART, N("mul"), T(isw), IMM, SEEND, T(sm3neg), SDST },
11:24 mlankhorst: imirkin: precise has up to 3.13 kernel :p
11:25 imirkin: mlankhorst: and precise is... 12.04? 14.04?
11:25 mlankhorst: 12.04
11:26 mlankhorst: it officially shipped with 3.04 or something, but had updates
11:26 imirkin: is there a cheat sheet for all this stuff?
11:26 imirkin: people tend to come in assuming others have some concept of what all these versions mean
11:29 RSpliet: imirkin: I figured... I'd better implement that one too, dota2 has some shaders that would love to use MAD with IMM :)
11:29 imirkin: RSpliet: awesome =]
11:34 linas: at the very bottom of http://en.wikipedia.org/wiki/List_of_Ubuntu_releases is a list of ubuntu releases+kernel versions.
11:35 imirkin: linas: ah cool, thanks
12:52 pmoreau: imirkin: Bad news... You traded 4 fails to get 4 crashes with c01bb89
12:53 imirkin: wtf?
12:53 imirkin: what's the crash??
12:53 pmoreau: Sending the results
12:54 imirkin: hope you didn't run it over all piglit...
12:54 pmoreau: Nop, only the arb_transform_feedback
12:54 pmoreau: (I made a custom test for them)
12:54 imirkin: k
12:54 imirkin: you can just do
12:54 imirkin: -t transform_feedback
12:54 imirkin: :)
12:55 pmoreau: Send
12:55 pmoreau: Too easy! :D
12:55 pmoreau: Well, I din't know, thanks for the info
12:56 imirkin: :)
12:57 imirkin: bleah, apparently i failed at something really basic
12:57 imirkin: although i have to say
12:57 imirkin: [ 5377.634964] nouveau E[ PFIFO][0000:03:00.0] DMA_PUSHER - ch 5 [arb_transform_f[27392]] get 0x0020018190 put 0x002001819c ib_get 0x000000
12:57 imirkin: 03 ib_put 0x00000004 state 0x80000000 (err: INVALID_CMD) push 0x00400040
12:58 imirkin: this is most intriguing
12:58 imirkin: previously we were never able to trigger this on-demand
12:58 imirkin: perhaps i've finally cracked the code? :)
12:58 pmoreau: Cool! :)
12:59 mew007: hello all
12:59 mew007: I'm about my 550Ti
13:00 mew007: It seems I have hardware problem... One of SMD-capacitors burnt...
13:02 mew007: that cause all problems I mentioned here: https://bugs.freedesktop.org/show_bug.cgi?id=87830
13:02 imirkin: how do you know?
13:02 mlankhorst: imirkin: shrug, it's complicated, on shipping hw you can have various i915 drivers too :P
13:03 mew007: Most interesting thing: 550 still works perfectly with proprietary drivers.
13:03 imirkin: mlankhorst: not sure how that's supposed to make me feel better
13:03 mlankhorst: oh uname -r is mostly accurate if the drm backport is not enabled, i don't think it's the default
13:04 imirkin: perhaps i should just refuse to talk to people who don't run an upstream kernel?
13:04 mlankhorst: naw
13:05 mlankhorst: just ask for uname -r
13:06 mew007: imirkin: I've watched under loupe my video card and found one SMD-capacitor foiled by radiator on motherboard. Maybe I pluged it too roughly...
13:06 imirkin: mew007: right, but what makes you think it's in any way responsible for the nouveau issues?
13:06 imirkin: did you replace it with a new one and the problems went away?
13:06 mew007: why not? Or you really think that it cannot cause such problem?
13:07 imirkin: i can't make that determination either way...
13:07 mew007: i didn't replace it with new one. I've just soldered it back
13:07 imirkin: does nouveau work now?
13:08 mew007: I hope it was bipolar one
13:08 mew007: no
13:08 mew007: nouveau doesn't work
13:08 imirkin: so you have no information to tie nouveau's not working to the cap...
13:09 mew007: but I think it's hardware problem anyways
13:09 imirkin: ok
13:09 mew007: but, yeah, it's interesting why video card works perfectly with proprietary drivers
13:10 imirkin: it's almost as if your analysis that the cap messed up the hw like that was off...
13:12 mew007: imirkin: could you translate it to russian? i'm not sure i got it... too hard sentence for me
13:12 imirkin: как будто твой анализ, что это все из за капаситора, не правильный
13:13 mew007: дай Бог
13:13 mew007: capacitor - конденсатор
13:14 imirkin: yeah, i'm weak on tech terms
13:16 mew007: dunno wut 2 do... I want video card working with linux-libre...
13:16 imirkin: what was the bug you filed?
13:16 imirkin: (aka place link here)
13:17 pmoreau: https://bugs.freedesktop.org/show_bug.cgi?id=87830
13:17 mew007: I asked someone who has 550Ti to try Linux Mint 17 Xfce. He said that it works very nice. I've tried that LM17Xfce too, but same problem
13:18 imirkin: skeggsb_: ---^ take a look at that bug when you get a chance... something in the fifo submission seems off, but it's way beyond my understanding of fermi pfifo
13:18 mew007: pmoreau: don't hurry. I gonna replace that capacitor soon, and if it solve problem - then I'll file it there
13:19 pmoreau: mew007: Wasn't it the bug you filed?
13:19 mew007: pmoreau: yes
13:21 mew007: and are SMD-capacitor too sensitive for usual soldering-iron? May I burn it with it?
13:21 mew007: capacitors*
13:24 imirkin: just be quick about it
13:24 imirkin: i think you can heat them up to like 140C for about a second
13:25 imirkin: they're designed for reflow soldering
13:25 mupuf_: imirkin: if they were that sensitive, they could never be soldered
13:25 mupuf_: Are there chemical SMD capacitors ?
13:26 imirkin: afaik just ceramic ones
13:26 imirkin: can't fit a lot of that goo in a 0402 size
13:27 mupuf_: ;)
13:27 mupuf_: ceramic ones should not be very sensitive
13:27 imirkin: they can crack
13:27 imirkin: from the heat
13:28 imirkin: i guess i dunno specifically about smt caps
13:28 mupuf_: and they have no thermal inertia, so I guess they have to be designed handle ~240°C
13:28 imirkin: but definitely silicon chips shouldn't be heated up for too long
13:28 mupuf_: oh, right, reflow ovens need to follow a controlled increase/decrease in temperature
13:28 mupuf_: ~3°C/10s IIRC
13:28 imirkin: yeah, those things are pretty intense
13:29 imirkin: uhh... i thought it was more of a flash
13:33 mew007: take a look: http://postimg.org/image/4umrwcw7f/2fc86155/
13:34 mew007: there you can see that capacitor
13:35 imirkin: looks like just a cleanup capacitor
13:35 imirkin: probably not super-important
13:36 mew007: not super-important? hehe, not for me...
13:38 mew007: imirkin: how can I ask nvidia hardware devs?
13:38 mew007: is it possible at all?
13:38 imirkin: sure, buy 1M units, i'm sure they'll give you that sort of support
13:39 imirkin: of course in this case, it's actually gigabyte you should be asking. and they certainly aren't going to tell you that some cap isn't important :)
13:44 tobijk: yeah they'll send you a new card with an even less enduring capacitator :D
13:46 mew007: imirkin: what is 1M unit?
13:46 tobijk: one million :>
13:47 mew007: huh?! imirkin; are you crazy?!!!
13:47 tobijk: thats the joke ;-)
13:47 mew007: 1 million of 550ti... Yeah, I got it (about joke)
13:48 imirkin: it's not really a joke
13:48 imirkin: but that's the level of purchasing you need to be at if you want direct assistance from nvidia
13:48 mew007: I'll ask gigabyte
13:48 imirkin: at that sort of level. i dunno. maybe merely 50K units buys you that. but it's definitely millions of $
13:53 pmoreau: imirkin: Do you have something else to test on NVAC? Otherwise I'll reboot and test the other patches you linked.
13:54 imirkin: pmoreau: what patches did i link?
13:54 pmoreau: Can't remember either, but I wrote them on my Mac partition
13:54 imirkin: i pushed a bunch of stuff last night
13:55 imirkin: hopefully texel fetch offset is all good now
13:55 pmoreau: http://lists.freedesktop.org/archives/nouveau/2015-January/019636.html
13:55 imirkin: yeah, that's in master now
13:55 imirkin: + RSpliet's tested-by
13:55 pmoreau: Ok
13:56 tobijk: imirkin: any idea about the failing of "arb_texture_multisample-sample-depth"?
13:56 imirkin: tobijk: nope
13:56 imirkin: tobijk: beyond the fact that i also noticed that it was failing :)
13:56 tobijk: :)
14:00 imirkin: seemed a lot easier to stick my head in the sand
14:00 tobijk: good choice :D
14:39 mew007: imirkin: r u ostrich?
14:40 imirkin: i am not an ostrich, no
14:40 imirkin: i am, in fact, a human being
14:40 imirkin: or a really advanced ai... dunno.
14:41 imirkin: https://www.google.com/search?q=define+ostrich
14:42 imirkin: huh, fun second meaning. didn't know it.
15:21 Leftmost: imirkin, not a really advanced AI implanted in an ostrich?
15:22 imirkin: always a possibility
16:56 mew007: LOL
16:56 mew007: good night
16:56 mew007: all
17:00 mew007: sorry
17:00 mew007: I'm back
17:00 mew007: How do I know bios version of my video card?
17:01 imirkin: dmesg | grep VBIOS
17:04 mew007: imirkin: thx, but it doesn't show me anything...
17:04 imirkin: hmmm
17:05 imirkin: oh, coz nouveau's not loaded
17:05 mew007: I'm on Linux Mint 17.1 Mate 32-bit with proprietary nvidia drivers
17:05 imirkin: oh, nvidia-smi should produce that output
17:05 imirkin: or nvidia-settings
17:09 mew007: have no nvidia-settings...
17:10 mew007: and nvidia-smi doesn't show me VBIOS... I tried: nvidia-smi -h | grep VBIOS
17:10 imirkin: you can extract the vbios... see http://nouveau.freedesktop.org/wiki/DumpingVideoBios/
17:11 imirkin: i don't think it literally says VBIOS
17:11 imirkin: i think it says something else... like Version? dunno
17:11 imirkin: pretty sure it's in there somewhere
17:11 mew007: and what means: X.Org: 1.15.1 drivers: (unloaded: fbdev,vesa) FAILED: nvidia Resolution: 1280x1024@60.0hz
17:11 mew007: it's output of inxi -Gxx
17:11 mew007: FAILED <--
17:12 imirkin: no idea what that program does
17:13 mew007: man inxi
17:13 imirkin: No manual entry for inxi
17:14 mew007: I've just found how: cat /proc/driver/nvidia/gpus/0/
17:14 mew007: Video BIOS: 70.26.3a.00.01
17:26 mew007: imirkin: как будет грамотнее перевести "я случайно сорвал конденсатор с видеокарты" ?
17:26 mew007: гребанный радиатор на материнке... надо же было южный мост прям под видюху подсунуть...
17:42 mew007: good night!
17:51 diamondman: I have a beginner question on how video cards are accessed through the pei/e 'bus'. I know video cards usually have memory mapped IO, but what is mapped? I think for the old VESA mode operation the frame buffer was mapped for raw drawing by the CPU, but when it comed to 2d or 3d acceleration with texture loading, etc I have no idea how it is mapped
17:57 diamondman: Found mupuf's phd 2012 paper on deeper looks into linux graphics stack. If I get my answer I will give it for anyone who may want to know.
18:03 imirkin: diamondman: what's your question?
18:04 imirkin: in 3 words or less, explain all the details of how modern gpu's work?
18:06 diamondman: haha, no not at all
18:06 diamondman: I am reading up on how pci express works. Currently reading about BARs and mapping in general
18:07 diamondman: I was just curious if there is a piece of documentation in the nouveau wiki, etc, that shows what the memory addresses (relative to the BARs of course) do
18:08 diamondman: I know this is not for ALL cards, I just would like to get an idea of how it can be done
18:08 imirkin: you may be interested in http://envytools.readthedocs.org/en/latest/
18:09 imirkin: and also https://github.com/envytools/envytools/tree/master/rnndb
18:10 diamondman: Ah rightawesome. I will read through this. and try running the tools on my quadro k2000m
18:11 diamondman: Thanks. I do have one more question for now. I read that VESA has been depricated with UEFI. What should I look up to read how a video card exposes itself to the BIOS to supply a frame buffer?
18:17 imirkin: mmm... dunno
18:19 diamondman: amn, that is a big missing piece in my understanding
18:19 diamondman: damn*
18:19 diamondman: thanks for the resources anyways
18:19 imirkin: i wouldn't terribly worry about that part
18:20 imirkin: it's the least interesting bit, i would think
18:23 diamondman: Fair, but I am doing a lot of FPGA stuff and toying with building embedded systems. Admittedly I am dealing a bit with arm for my embedded testing so I don't deal with UEFI or PCI standards at all, but I would like to fill in the missing pieces so in theory I could build a motherboard in the future, or build a toy graphics card in an FPGA pcie board
18:26 imirkin: well, with stuff like VESA, the card has firmware that's set up by the vbios which is able to perform high-level operations like changing resolutions, etc
18:26 imirkin: with UEFI, it's the same thing... just different api
18:27 imirkin: so basically the firwmare comprises a mini-driver
18:34 diamondman: ah, that is the part of pci that mapps firmware into memory I suppose
18:34 diamondman: I wonder if the bars have to be changed for say, the frame buffer if it is mapped directly into the memory spaece
18:35 diamondman: And maybe the graphics card just uses its class identifier or something to specify to the BIOS that it is a valid endpoint to drive a display
18:36 imirkin: heh
18:37 imirkin: if only
18:37 diamondman: hehe that is the hopeful optimism that comes from having just done a lot of USB work :)
18:38 imirkin: in a BIOS system, the BIOS identifies which video card (based on pci class i think) is the 'boot' video card
18:38 imirkin: and executes its option rom
18:38 imirkin: i _think_ that this option rom is supposed to install a int 10h handler
18:39 imirkin: which is a semi-specified interface
18:39 diamondman: makes sense, VESA controlled through int 10 and it would make sense to handle that interrupt directly with the VBIOS
18:42 diamondman: I read that ACPI does something similar with having x86 code on roms that the OS has to run to dudpend/etc
18:44 imirkin: well, the instructions execute on the CPU
18:45 diamondman: I know that is how it is in ACPI.... are you saying it DOESN'T also do that for the VBIOS? I assume there was just a miscommunication
18:47 imirkin: but in 16-bit real mode you just overwrite the IDT and go
18:48 imirkin: i believe that ACPI is done in a theoretical language that you have to interpret
18:48 diamondman: oh right, it is in some bytecode thing
18:49 imirkin: ASL as i recall
18:49 diamondman: A friend of mine was dealing with that a few months ago in Plan9 lol
18:50 diamondman: so the VBIOS stuff, even in modern cards running in UEFI, are real mode instructions?
18:52 diamondman: If so, is that a leftover from VESA
18:54 imirkin: VBIOS is just the option rom
18:56 diamondman: sorry... _option_ ram?
18:56 imirkin: i'm not 100% sure where ACPI tables come from, but i think it's the BIOS, which knows nothing about the video card in a generic setup
18:56 imirkin: in e.g. a laptop or other platform, it might have stuff baked in
18:56 imirkin: option rom
18:56 imirkin: it's a pci thing
18:59 diamondman: oh, ok, I see what you were saying. It does feel a little weird coming from software that these physical devices have code that execute on the cpu in elevated privledge modes just by being in the computer, but it makes sense at this level
19:00 diamondman: Though Darmawan Salihun has a good article of how to exploit this safety assumption http://resources.infosecinstitute.com/pci-expansion-rom/
19:00 imirkin: yeah, esp when you plop one of those cards into, say, a ppc box
19:01 diamondman: Oh yeah that is particularly weird and likely why ACPI went with their bytecode thing, but still weird feeling having to execute device specific code on the CPU to control evices. Well, that is outside the scope of this conversation so whatever :)
19:02 imirkin: of course ACPI is really only a thing on x86 afaik
19:02 imirkin: although it's starting to get used on arm, in theory
19:04 diamondman: interesting, I did not know that ARM was maybe picking it up
19:06 diamondman: Well I will see if I can figure out how the card registers to the BIOS that it is able to provide a buffer. thanks for all the help and a nice conversation
19:08 mjg59: Options ROMs don't typically contain ACPI tables
19:08 mjg59: Modern cards will have a UEFI driver embedded in them
19:08 mjg59: Which can either be x86 code or UEFI bytecode
19:10 diamondman: I didn't think there were ACPI tables in the option rom, but now that I think of it, idk where I thought it would be for the card. And that is cool. Kind of forgot that UEFI is you know... extendable