00:00 skeggsb: it turns out, that with both the binary driver devinit trace, and our own devinit.. it actually works randomly
00:00 imirkin: but the binary driver is able to work reliably
00:00 imirkin: if you look at the bug, it indicates some sort of timing situation might be at hand
00:00 skeggsb: yes, but i'm executing a trace blindly, without proper delays etc
00:00 skeggsb: so, yes, timing looks likely now
00:01 imirkin: coz people were able to "fix" it by futzing with rcu
00:02 imirkin: which clearly has nothing to do with anything except random time intervals thrown in all over
00:03 skeggsb:hates these kind of bugs
00:04 gnurou: so I guess all version checking should be done in Mesa, not libdrm itself, correct?
00:04 skeggsb: gnurou: personally, i'd be ok with that
00:04 imirkin: so i guess your patch is good as-is :)
00:04 imirkin: just have to wait for ben's tree to hit linus
00:04 gnurou: since libdrm apparently reports the version given by the kernel driver in dev->drm_version
00:05 gnurou: imirkin: right, thanks for the heads-up though, I haven't thought about this problem TBH
00:06 imirkin: gnurou: yeah, it's an annoying one... what happens when someone isn't updating software in lock-step.
00:06 gnurou: indeed
00:07 imirkin: anyways... i'm out
00:09 gnurou: imirkin: 'night!
00:09 pmoreau: Good night
00:11 gnurou: last thing: with the introduction of this new flag, Mesa will require libdrm >= 2.4.60 to even build, I guess that's ok?
00:11 gnurou: i.e. I will have to update configure.ac
00:12 skeggsb: gnurou: yep, that's fine, just need to update minimum versions in configure.ac
00:12 skeggsb: yep :)
00:12 gnurou: good, we should be safe then
00:13 gnurou: will just need to wait for the next libdrm release before sending the patch to Mesa
00:13 gnurou: ouch, that might mean wait a while actually
00:14 airlied: release libdrm, then amke mesa depend on it
00:14 skeggsb: as long as there's nothing else pending for other drivers, we can probably just bump the version anyway.. worth asking on dri-devel
00:14 airlied: it just got released a few dayas ago, so should be little to do
00:14 gnurou: nice, thanks guys
00:15 gnurou:is still not too familiar with the user-space side of things...
00:15 gnurou: so shall I re-send as a two patches series, the second of which increases the libdrm version?
02:43 pmoreau: skeggsb: Do you plan to do a pull request for Nouveau for 4.0? In that case, what would be part of it?
03:42 xexaxo: guys wrt the coherent BO attribute, shouldn't there be a DRIVER_PATCHLEVEL bump ?
03:42 xexaxo: grr scratch that, there already is one :\
05:43 nv7300gs: hello
05:43 nv7300gs: i have an nvidia 7300 gs with 256MB RAM and when i boot, i directly get an black screen when KMS starts
05:44 nv7300gs: i cant check logfiles, because i did not have ssh to the system or anything else. Its a windows system that should switch to linux
05:44 nv7300gs: is there any iso with ssh enabled by default?
05:45 nv7300gs: or did you have here an idea how i can debug that to provide you logfiles?
05:47 nv7300gs: i also think of flashing the bios of the card with an other one: http://www.techpowerup.com/vgabios/index.php?architecture=NVIDIA&manufacturer=&model=7300+GS&interface=PCI-E&memType=&memSize=256
05:48 nv7300gs: does anyone here know what bios version is been supported from nouvau?
06:00 pmoreau: nv7300gs: You can use nouveau.modeset=0 to boot your computer with nouveau disable, start SSH / whatever you want, and then modprobe Nouveau
06:00 pmoreau: s/disable/disabled
06:00 nv7300gs: pmoreau: ah, okay. VESA is working. i already tested that
06:01 pmoreau: Ok
06:01 nv7300gs: pmoreau: so just "modprobe nouveau" as root?
06:01 pmoreau: Probably need to add modeset=1 to override the modeset=0 passed at boot :)
06:02 nv7300gs: "modprobe nouveau modeset=1"
06:02 pmoreau: So, `modprobe nouveau modeset=1`
06:03 pmoreau: After that, grab a dmesg and paste it somewhere so we can have a look at it
06:03 nv7300gs: it is not possible to start vesa, run modprobe nouveau, turn nouveau off again and read the logfiles on the same computer with vesa running?
06:03 pmoreau: What kernel version are you using by the way?
06:03 nv7300gs: pmoreau: 3.16-3.19
06:04 pmoreau: I don't think so... But not sure
06:04 pmoreau: There is a wiki page on that, let me find it
06:04 nv7300gs: what i would like to test first is something like this: video=DVI-I-1:1024x768@85 video=TV-1:d
06:05 nv7300gs: how can i set the color depht?
06:05 nv7300gs: and what does video=TV-1:d mean?
06:06 nv7300gs: its exactly this card here: http://www.bloodys.com/wp-content/uploads/old/vegea-pret15.jpg
06:06 nv7300gs: XFX Nvidia 7300 GS 256MB
06:06 pmoreau: Have a look here: http://nouveau.freedesktop.org/wiki/KernelModeSetting/
06:08 nv7300gs: pmoreau: is there "everything off exept of DVI"?
06:10 pmoreau: Maybe `video=:d video=DVI-1:e` ?
06:11 pmoreau: But I'm not really familiar with that.
06:11 pmoreau: gtg sorry. I'll look at the logs when I come back to see if you find something
06:13 nv7300gs: could someone here quickly run following and tell me if it works?: for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
07:30 nv7300gs: any dev here? i got the 7300 gs working with an VGA cable
07:31 nv7300gs: and atfer boot i removed the vga and attached dvi. still no monitor screen working, but i have much logfiles. the DVI monitor is been find when connected
07:32 nv7300gs: nouveau finds the VGA card as TV-1
07:32 nv7300gs: i mean vga-connector
07:33 imirkin: nv7300gs: that's very surprising... are you using the original vbios that came with the card?
07:33 nv7300gs: when connecting DVI i get: nouveau 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
07:33 nv7300gs: imirkin: in windows everything works fine. Maybe also with nvidia-binary-legacy-304. Have not tested this legacy driver now
07:34 imirkin: that wasn't the question i asked :p
07:34 nv7300gs: the vga bios seems to be normal. i cant remember to have flashed it and everything is working with binary drivers
07:35 imirkin: k
07:35 nv7300gs: nouveau E[ DRM] DDC responded, but no EDID for DVI-I-1
07:36 nv7300gs: booted up recent 3.18 system (lubuntu 15.04 alpha)
07:36 nv7300gs: i am writing with this system at the moment here with you ;)
07:37 nv7300gs: over VGA cable connected
07:38 imirkin: yeah, unfortunately i have no clue why something like that would happen
07:39 nv7300gs: imirkin: can i help debugging?
07:39 nv7300gs: the result of this: for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
07:40 imirkin: i assume it says 'connected' for DVI-I-1
07:40 nv7300gs: is DVI-I-1: disconnected | TV-1: connected | TV-2: disconnected
07:40 nv7300gs: TV-1 is VGA cable
07:41 imirkin: that's _very_ surprising
07:41 nv7300gs: when i remove first VGA cable from the card and then connect the DVI Cable, i get 3 times "disconnected"
07:41 imirkin: wait wtf -- it's detecting *2* tv outputs?
07:42 imirkin: nv7300gs: can you file a bug with your vbios attached (and dmesg)?
07:42 nv7300gs: imirkin: the card have one TV-output, one VGA output and one DVI output
07:42 nv7300gs: this is the card: http://images10.newegg.com/NeweggImage/ProductImageCompressAll300/14-150-410-02.jpg
07:42 imirkin: you can get vbios from /sys/kernel/debug/dri/card0/vbios.rom
07:43 nv7300gs: imirkin: should i send you the bios?
07:43 imirkin: you should file a bug
07:43 imirkin: and attach the relevant info
07:44 imirkin: bugs.freedesktop.org, product = xorg, component = Driver/nouveau
07:44 nv7300gs: so you are not a dev that knows directly where the problem is?
07:45 nv7300gs: did you know how i can force nouveau to turn on DVI with one exact resolution and so on?
07:47 imirkin: you could feed it an edid with just one resolution...
07:48 imirkin: that seems unlikely to be the thing you want though
07:48 nv7300gs: what is this edid?
07:48 imirkin: blob of data that describes the monitor
07:49 imirkin: supplied by the monitor over DDC
07:50 nv7300gs: booting with video=.... can do this?
07:51 nv7300gs: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 225
07:51 urjaman: no
07:52 nv7300gs: https://pastebin.mozilla.org/8825668
07:56 nv7300gs: https://pastebin.mozilla.org/8825670
07:57 nv7300gs: this is the xorg output when booting up with an VGA cable connected
07:58 nv7300gs: monitor is 1920*1200
07:59 nv7300gs: now runnig over VGA with detected 1024*768 detected by nouveau
08:00 nv7300gs: any dev here who could tell me what additional information is needed for fixing?
08:02 nv7300gs: imirkin: you seem to know a bit more about nouveau :) https://github.com/imirkin/nouveau
08:03 imirkin: having a git tree that's a clone of someone else's tree implies knowledge?
08:05 imirkin: in any case, i gave you my advice. feel free to take it or ignore it.
08:05 nv7300gs: imirkin: what is exactly the bios?
08:05 nv7300gs: https://pastebin.mozilla.org/8825671
08:06 nv7300gs: i have it 3 times
08:06 imirkin: get it from 0
08:06 imirkin: i suspect it's the same data in each one though
08:07 nv7300gs: i check sha512sum and tell you in a sec
08:08 nv7300gs: imirkin: yes - https://pastebin.mozilla.org/8825673
08:39 nv7300gs: imirkin urjaman , here the bug: https://bugs.freedesktop.org/show_bug.cgi?id=89571
08:39 nv7300gs: thanks so far :)
10:32 hakzsam: imirkin, I could be a lucky man if you also have time to review gl_amd_perfmon :)
10:32 imirkin: hakzsam: happy to look at the nouveau patches once the core stuff is "approved"
10:33 imirkin: i have no domain knowledge though... i dunno what all these counters are or how they'd be used
10:33 imirkin: i am the proud owner of an nvc1 though, so if you provide some instructions, i could play around with it
10:34 hakzsam: yes, sure, I'm waiting for a review of Kayden (because he is the man who introduced core support for that extension)
10:35 imirkin: did he say he'd look at it?
10:35 hakzsam: he didn't anwser yet
10:36 imirkin: even though he introduced support for it doesn't mean that he forever wants to be its owner...
10:36 hakzsam: yes, but nobody seems to want to be the owner :)
10:36 hakzsam: that's the problem actually
10:37 pmoreau: Do you want to become the new owner? :D
10:37 hakzsam: hehe :)
10:38 imirkin: well so that's the thing... i dunno the first thing about counters...
10:38 imirkin: seems like you do :)
10:40 hakzsam: sure, and I'm currently working to implement nouveau-perfkit, that will be a lot of code to review too.. ~1.5K
10:41 hakzsam: I'll wait for gl_amd_perfmon to be upstream before submitting new patches :)
10:41 pmoreau: That's half the gk20a PMU patch, should be fine :)
10:41 hakzsam: seems to be quite reasonable
10:41 hakzsam: yes, I saw that
10:43 imirkin: hakzsam: ah yes, but a much lower standard for review
10:43 imirkin: hakzsam: here we have to make sure we get the interfaces right and make them sensible
10:43 imirkin: whereas there it's like... does it look like it could work? yes? then go.
10:43 imirkin: [at least that's how i'd approach it... heh]
10:44 hakzsam: sounds good to me
10:44 imirkin: and that gk20a pmu patch was ridiculously long, i think everyone agreed on that :)
10:44 imirkin: [except, perhaps, the author]
10:44 hakzsam: that's crazy indeed
10:45 hakzsam: I could try to submit gl_amd_perfmon+perfkit in one patch :p
10:45 imirkin: yeah, squash them for good measure
10:45 pmoreau: :D
10:45 imirkin: also run it through a variable shortener to reduce the number of bytes the code takes
10:45 imirkin: (increase compilation speed?)
11:12 mlankhorst: bah stupid overscan
11:12 imirkin: on the ethernet cable?
11:36 mlankhorst: nah, the hd tv
11:37 mlankhorst: that I was using for the tegra board
11:37 imirkin: :)
11:38 mlankhorst: connected the older one, it has a lower resolution but at least it's usable
11:39 mlankhorst: Xorg's crashing on it though, something I should look at :/
11:39 mlankhorst: being the xorg maintainer for ubuntu and all
11:40 imirkin: hehe
11:57 drowfx: hello
11:57 mlankhorst: ah that's why it was crashing :P
11:57 mlankhorst: yeah thought so, stupid xorg patch
11:57 drowfx: i opened a bug (https://bugs.freedesktop.org/show_bug.cgi?id=89572), and was told to come here to help track it down
12:00 imirkin: drowfx: do you have any development and/or video/h264 experience?
12:00 drowfx: i have experience with c programming including kernel development, but more on embedded systems than x86
12:01 drowfx: so i know my way around kernel debugging. Xorg and h264 experience, not so much
12:01 imirkin: cool
12:01 imirkin: that's more than i had when i started RE'ing VP2 :)
12:02 drowfx: i don't know if it really is an issue specifically with the video decoder, or a deeper issue with the nouveau driver in general
12:02 imirkin: so... at a high level, the VP2 engine takes commands which tell it like "here is a buffer with things, compute, and output to other buffer"
12:02 mlankhorst: it's likely related though :p
12:03 imirkin: apparently i fail at telling it "things" though
12:03 mlankhorst: depends on how spammy it is..
12:03 drowfx: i had issues with this graphics card in the past, various machine hangs in 3d games. It always worked fine under windows, so i don't think the hardware is broken
12:03 imirkin: but sadly it's not a total failure
12:03 imirkin: which would be much easier to debug
12:03 imirkin: it's a very data-dependent failure
12:04 imirkin: basically some (many?) video frames in that video have something in them that i either didn't see during my RE or i didn't handle properly
12:04 drowfx: ok. so i suppose i compile some debug code into the kernel to see what commands get sent for the failing video?
12:05 imirkin: so step 1 is to familiarize yourself with some of the tools
12:05 imirkin: the main tool is going to be valgrind-mmt
12:05 imirkin: http://nouveau.freedesktop.org/wiki/Valgrind-mmt/
12:05 imirkin: this works for tracing both nouveau and the blob
12:05 imirkin: also make a tiny tiny tiny version of that video which still exhibits issues
12:05 imirkin: and run that through e.g. VDPAU_TRACE=1 mplayer
12:06 imirkin: you'll see a bunch of information
12:06 mlankhorst: must.. get.. xorg.. running
12:06 imirkin: basically all the h264 parameters
12:07 imirkin: and if you run that through mmt, you'll also see what the driver does in response to each one
12:07 imirkin: so the idea is to do that trace on the shortened file for nouveau, do it for the blob, and compare
12:08 imirkin: one source of eternal sadness is that i never quite managed to figure out the blob's reference frame management strategy. i have my own which i'm fairly sure works, but that can make it tricky to diff the data.
12:08 mlankhorst: imirkin: yeah same..
12:09 imirkin: mlankhorst: but your thing works :)
12:09 mlankhorst: mostly :P
12:09 mlankhorst: is vp2 that different that the same strategy doesn't work?
12:10 imirkin: i dunno, i couldn't understand your strategy
12:10 imirkin: i made the one that made sense to me at the time
12:10 drowfx: ok. for the tiny version of the video, do i have to cut the video file or is something like mplayer -endpos .5 sufficient
12:10 imirkin: it's HUGELY wasteful
12:10 mlankhorst: same here..
12:10 imirkin: drowfx: well, the fewer frames the better
12:10 drowfx: ok, so i generate traces for the blob and nouveau, and hopefully you/someone can find the error from the differences?
12:10 imirkin: drowfx: that allows less things to go wrong
12:11 imirkin: drowfx: i can glance at them, but chances are you're going to have to do the heavy lifting
12:11 mlankhorst: imirkin: well I allocate max_references + 1, then some kind of lru i think
12:11 mlankhorst: dno i would have to look at the source
12:11 imirkin: mlankhorst: i allocate 2 ref frames per frame :)
12:11 mlankhorst: you're right, that is wasteful
12:11 imirkin: ;)
12:11 drowfx: imirkin: if i cut the video i have to do it without reencoding otherwise it won't work for debugging, so i can only cut at keyframes, right?
12:11 mlankhorst: each video buffer gets an index into the reference crap
12:11 imirkin: something with an intermediate frame or... something.
12:12 imirkin: drowfx: yeah, cut it at an I-frame and then leave one or two frames after that... the key is that you must see corruption
12:12 drowfx: imirkin: ok, i'll try to get the tools setup and see if i find anything and come back if i have more questions
12:12 imirkin: if you don't see corruption then it's all for naught
12:12 imirkin: mlankhorst: yeah... that's the better way to do it. i was just plowing through it to make shit work
12:13 mlankhorst: imirkin: you can always copy paste from vp3 if still interested :D
12:15 imirkin: mlankhorst: i don't think it'd quite work
12:15 mlankhorst: why not?
12:15 imirkin: coz i need 2 ref frames
12:15 imirkin: or rather, 2 ref-frame-sized things
12:15 mlankhorst: for each ref?
12:15 imirkin: and they attach to data in a somewhat different way
12:15 imirkin: i forget exactly tbh :)
12:16 imirkin: this was like... a year ago
12:16 mlankhorst: if it's for each ref it works the same way..
12:16 imirkin: or 2
12:16 mlankhorst: just make the size 2x as big
12:16 mlankhorst: meh I'll commit the libdrm patches, about time now
12:17 imirkin: gnurou wanted a patch too, if you're doing a release, stick his in
12:18 mlankhorst: [PATCH] nouveau: add coherent BO attribute ?
12:18 imirkin: ya
12:19 mlankhorst: I think it will require being in a linus kernel
12:19 mlankhorst: I'll accept drm-next too
12:19 imirkin: meh, it's in ben's tree
12:19 imirkin: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=8c281ab4ddda8208dfe4ba4899553da1dc19fc48
12:20 mlankhorst: imirkin: yeah but in case of intel etc it's the same policy for them
12:21 imirkin: k wtvr. i don't really care :)
12:23 mlankhorst: ugh for some reason the patch shows up as flowed.. meh! >:(
12:24 imirkin: grrr
12:25 imirkin: i hate that flowed bs
12:26 mlankhorst: same
12:26 mlankhorst: thought I sent it with git-send-email though
12:43 mlankhorst: bleh mesa with the official instructions builds wrongly, it needs tls
12:47 mlankhorst: gnurou: argh, the scripts for building mesa need --enable-texture-float --enable-glx-tls
12:52 mlankhorst: oh bah, not enough space :(
13:04 mlankhorst: io(EE) no screens found(EE)
13:04 mlankhorst: ah that's better
13:13 pmoreau: What is the point of `dmac->ptr[put] = 0x200000000` in evo_wait?
13:18 imirkin: hopefully that's not _literally_ what it says...
13:19 imirkin: dmac->ptr[put] = 0x20000000
13:19 imirkin: yeah ok, that's better
13:19 imirkin: your version had too many 0's :)
13:19 pmoreau: Oops, indeed! :D
13:20 imirkin: i'm guessing it's a fifo channel command... let's see
13:20 mlankhorst: ok new xorg-server seems easy to build on trusty.. saves me from updating the tegra :P
13:21 imirkin: pmoreau: that appears to be a "jump to 0" command. not sure if i'm understanding things right though.
13:22 imirkin: pmoreau: http://envytools.readthedocs.org/en/latest/hw/fifo/dma-pusher.html#the-commands-pre-gf100-format
13:23 pmoreau: Ah, thanks!
13:24 pmoreau: I guess I'll need to re-read that page again. It seems I still don't understand correctly how dma buffers work.
13:24 imirkin: well, i'm going off the theory that evo pushbufs use the exact same format
13:25 imirkin: i'm fairly sure they do
13:25 imirkin: but who knows
13:25 imirkin: basically the way the fifo works is that there's a "get" and a "put"
13:25 imirkin: "get" is where it's reading commands from
13:25 imirkin: "put" is where you write commands to
13:25 imirkin: so having that jump in "put" is saying "go back to start of pushbuf"
13:26 pmoreau: Ok
13:26 pmoreau: But then isn't writing 0 to put redundant?
13:26 imirkin: hm?
13:27 imirkin: well the fifo processes commands in order
13:27 imirkin: it couldn't care less what 'put' is set to
13:27 imirkin: except that it stops fetching when get == put
13:27 imirkin: the idea is that you write to put, and then change the value of put (usually increment by 4)
13:27 imirkin: obviously that doesn't work forever, so every so often you go back to whence you came :)
13:28 pmoreau: Right, as put - at least for EVO - goes from bits 2 to 11.
13:28 imirkin: but obviously you want the fifo puller to jump at the same time as you do, hence the jump
13:28 pmoreau: Ah, makes sense! :)
13:28 imirkin: s/time/point/
13:32 pmoreau: So, the way I planned to reset things when put is garbage won't work.
13:35 imirkin: nothing wrong with put being garbage
13:35 imirkin: just means that it'll keep getting forever
13:35 imirkin: processing random commands
13:35 imirkin: which is... not great
13:35 imirkin: basically the page backing the commands probably gets overwritten, which is the suck
13:36 pmoreau: Well, depends on how much garbage it is
13:37 pmoreau: Oh wait, maybe it should still work
13:37 imirkin: not really
13:37 imirkin: as long as its processing garbage commands, you're screwed
13:38 imirkin: what you want to do is reset it somehow
13:38 pmoreau: In my case I receive a put = 2^30, but it should still be within the limit of a PAGE_SIZE
13:39 pmoreau: By work, I mean not generate a "unable to handle page request"
13:39 imirkin: hehehe
13:40 pmoreau: nothing fancy :)
13:41 imirkin: aiming high i see
13:42 pmoreau: ;)
13:45 pmoreau: Meh... My brain isn't working great tonight... I was thinking that 4k == 2^32... --"
13:46 pmoreau: So yeah, obviously array[2^30] with array of size 2^12 is going to fail!
13:50 imirkin: not quite
13:50 imirkin: only off by 20 bits :)
13:51 pmoreau: Who cares about them :D
15:20 mlankhorst: bleh
15:20 mlankhorst: Xorg lacks the language to pick up on platform devices properly
15:21 imirkin: i thought you could add platform support to drivers...
15:21 mlankhorst: you can, but it won't help
15:23 mlankhorst: http://paste.debian.net/161180/ is sort of the config I will need for tegra, either that or use DRI3 + DRI_PRIME environment variable
15:23 imirkin: hm, well i'm running X on the ifc6410 and it works fine with msm
15:23 mlankhorst: yeah but on tegra you have a separate device for rendering and output
15:23 imirkin: uhm, does that work?
15:24 mlankhorst: no, there's no devicepath match
15:24 imirkin: right
15:24 imirkin: did you mean card128?
15:24 imirkin: er, renderD128
15:24 imirkin: or whatever
15:24 imirkin: and use modesetting for both?
15:24 mlankhorst: oh nm, card0 is the nouveau one
15:25 imirkin: lol
15:25 mlankhorst: hm probably not
15:28 tobijk: mh note, that on setups with multiple cards, either of these cards can be probed to the first one (card0)
15:28 mlankhorst: yeah, but I need to specify it for platforms somehow
16:59 Omar007: I have a VBIOS from a Gigabyte 970 G1 Gaming. Where do I send it? (assuming they are still wanted)
23:51 mlankhorst: same address as always, forgot which one though :P