00:00 Karlton: apitrace
00:00 Karlton: but I don't for sure the problem is mesa
00:01 Karlton: don't know for sure
00:01 Karlton: your ubuntu version is the latest lts one?
00:02 meeee: 14.04... so yes it is
00:05 dungeon007: Googling around a bit, seems to that black borders are quite common on unity http://askubuntu.com/questions/589552/black-spaces-around-windows-and-control-panels-ubuntu-14-04-unity-compiz-met
00:06 dungeon007: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1292830 ...
00:10 meeee: yes and the fix is to downgrade to the default super old mesa/nouveau? are u kidding me
00:10 meeee: the error is new to NOUVEAU
00:10 Karlton: try typing "DISPLAY=:0 unity --replace" in a tty while it is running
00:11 meeee: unity is not a window menager setsid might do it...next u will suggest to try metacity --replace... which might work
00:12 meeee: though the command is setsid metacity... after reseting compiz..forgot the command. thats the failsafe in case compiz totally dies. i know it and have used it
00:13 meeee: but the point shpuld be to fix the problem at the source..which is nouveau. the previous version mesa 10.1.... did not have it
00:13 meeee: and it was the same compiz
00:17 Karlton: but it was compiled and tested with that old version, and not with the new
00:18 meeee: yes
00:19 meeee: so back then it was issuing the right GL commands..which dont work today with th new nouveau. u see the paradox?
00:28 Karlton: I guess it is unlikely, but who knows
00:37 Karlton: http://www.phoronix.com/scan.php?page=news_item&px=MTY1NTU
00:55 gnurou: kisak: Lauri is one of our great GPUs dev, I hope (and expect) that he will continue contributing to Nouveau
01:07 meeee: dude..i hve a way newer version of the kernel
01:08 meeee: and whats ur point..to revert to precompiled stuff?
01:14 meeee: and for those who havent yet seen it..my new fashionable UI... perfectlz drawn > http://snag.gy/I7VpI.jpg
05:07 kisak: gnurou: that's neat, thanks for catching that question in the backscroll
05:58 meeee: anyone ideas? http://snag.gy/xJArM.jpg after rebuild over distros own ver 10.1....
06:05 pmoreau: meeee: Does switching back and forth from console like suggested in the bug report---that was pasted earlier---work for you?
06:06 meeee: no
06:07 meeee: so the shadows are just black squares arround the windows and popup boxes..the window frame and its buttons are also missing and not its not compiz' fault..this time at least
06:08 meeee: darkplaces engine quake works great.... doomsday for which i updated is still just black screen with sound
06:09 meeee: \i tryed tracing GL but glsl-debugger crashes if i restart compiz from it :(
06:09 pmoreau: With no errors I guess?
06:09 meeee: no none
06:10 meeee: dmseg was mostly fine except for one compiz crash
06:10 pmoreau: You could try using apitrace for tracing GL, not sure if it will better than glsl-debugger though.
06:10 meeee: [ 4055.688891] traps: compiz[2246] general protection ip:7fc187dce5d0 sp:7ffdd8ec8940 error:0 in libunitymtgrabhandles.so[7fc187db1000+27000] [ 4105.873000] nouveau E[ PGRAPH][0000:03:00.0] TRAP DISPATCH_QUERY [ 4105.873014] nouveau E[ PGRAPH][0000:03:00.0] no stuck command? [ 4105.873034] nouveau E[ PFB][0000:03:00.0] trapped write at 0x0020276000 on channel 0x0001fa52 [Xorg[1377]] PGRAPH/DISPATCH/QUERY reason: PAGE_NOT_PRESENT
06:11 meeee: gfault at 7 ip 00007fd4897e950d sp 00007ffe44ba5718 error 4 in libcompiz_core.so.[7fd489785000+ae000]
06:26 meeee: also glmesh test> _xgeWireToEvent: Unknown extension 148, this should never happen. - GPU0: NVIDIA GeForce 9600 GT
06:28 pmoreau: No idea what that is, sorry
06:38 meeee: gonna ask in compiz...see what thay know
06:39 meeee: #join #compiz
06:40 meeee: !join #compiz
06:40 tobijk: slash? :>
06:43 meeee: i havent used irc in years
06:43 pmoreau: Most likely slash
06:43 tobijk: hehe
06:44 tobijk: btw, should i mark cull_distance as wip? i'm getting emails about this :O
06:44 pmoreau: :D
06:44 meeee: it could have been .!#$*+ and so on
06:45 pmoreau: tobijk: Not sure I can weight on that, but probably yes
06:46 tobijk: mhm ok
06:47 pmoreau: That's the set of patches that were submitted this morning or yesterday, right?
06:48 tobijk: yep, they still hold several shortcomings though
06:48 pmoreau: Right, but it's not like you wanted to mark cull_distance as done. :p
06:48 tobijk: in that series the last patch does ;-)
06:49 pmoreau: Well, when it will be accepted, it should be the case, he's just preparing for the future. :)
06:50 meeee: tobijk... sahst du das? http://snag.gy/xJArM.jpg
06:50 tobijk: huh?
06:51 tobijk: nice black border :D
06:52 meeee: oh its perfect..thats the shadow..but the window border and resize/close buttons are completely gone!!!!
06:52 meeee: recompiled from source over the distros bins..to fix a problem..got more problems
06:54 tobijk: heh maybe you should try a live image of a different distro for once? :>
06:55 meeee: nice punch line
06:56 meeee: but seriously..how to trace and so on
06:56 meeee: im pretty sure its nouveau/mesa
06:57 meeee: also a live image of the nvidia bins will work. thats known
06:59 tobijk: pmoreau: can you push that oneliner to mark in progress?
07:00 tobijk: meeee: use one with recent nouveau's
07:01 Karlton: heh from Ubuntu's wiki about apitrace "Note that at present, it does not work with compiz because there is no support for GLX_EXT_texture_from_pixmap, a GLX extension that compiz requires"
07:02 pmoreau: tobijk: I only have write access to the wiki, that's all. :/
07:02 tobijk: pmoreau: we are sitting in the same boat then :D
07:02 pmoreau: ;)
07:03 Karlton: https://wiki.ubuntu.com/Unity/Bitesize/DebuggingUnity
07:03 pmoreau: tobijk: Except you're a Mesa developer whereas I never even tried to write a Mesa patch :D
07:04 meeee: the distro had gallium 3d disabled by default and used just enough accel to draw its shiny unity/compiz UI. which broke after i updated it
07:04 tobijk: pmoreau: i never tried to get an actual fdo acc, iM' not productive enough
07:04 meeee: i tried glsl-debugger..it broke spectacularly
07:05 tobijk: does gnome still use compiz, then you could really use other distros
07:06 meeee: its not gnome its ubuntus unity
07:06 meeee: btw ...why is everyone avoiding the real issue
07:06 meeee: ?
07:07 meeee: the nvidia drivers are known too work.. i just wanted to use nouveau and help devel. if possible
07:08 tobijk: meeee: well unbuntu is not really developer-friendly...
07:08 Karlton: meeee: because other people have had that problem and weren't using nouveau :P
07:08 pmoreau: Considering https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1292830, the blob doesn't work well in that case
07:10 Karlton: I recommend using a ppa that has git version of mesa along with other packages so breakage is less likely then if you just compile and install by source
07:12 meeee: u might have a point https://launchpadlibrarian.net/154246591/Screenshot%20at%202013-10-19%2019%3A51%3A44.png
07:12 meeee: those basstards
07:12 tobijk: meeee: tried the workaround there?
07:14 meeee: THAT sudo apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-core xserver-xorg-video-nouveau
07:15 meeee: workarround is just revert to their ooooold mesa
07:15 tobijk: no, the switch to console and back
07:15 meeee: that i tried
07:15 meeee: i might also try to reset compiz
07:15 meeee: see if that works...reset its settings
07:36 hakzsam: skeggsb, Hey, if you're interested, I rebased your patches for nvif support in libdrm http://cgit.freedesktop.org/~hakzsam/drm/log/?h=nouveau_nvif
08:32 hakzsam: tobijk_, pushed
08:35 tobijk_: hakzsam: thx :)
08:35 hakzsam: this was a nice trial :)
08:36 tobijk_: :D
08:38 imirkin: hakzsam: not sure how familiar with git you are, but i highly encourage you to use 'git push -n' first to double-check what all you're pushing.
08:44 hakzsam: imirkin, I cloned a new repo of mesa just for pushing, I don't really want to make mistakes :), but I'm going to take a look at git push -n
08:44 hakzsam: sounds a good idea to use -n
08:45 imirkin: another way to avoid silly mistakes is not to list 'origin' as the writable one
08:45 imirkin: (or otherwise not setting the default push dest)
08:45 imirkin: but with push -n, i've been able to avoid making silly mistakes
08:45 hakzsam: like this origin no-pushing (push) ?
08:45 imirkin: except once when i pushed a branch instead of a commit
08:46 imirkin: nowadays i always do 'git push -n origin commithash:master'
08:46 tacchinotacchi: hi, i'm a newcomer to this project
08:46 imirkin: [make sure you understand what that does before using]
08:47 tacchinotacchi: i've done various little programs but i never entered a serious projects
08:47 tobijk_: tacchinotacchi: welcome
08:47 hakzsam: imirkin, what is the meaning of commithash here?
08:47 tacchinotacchi: do you think it's possible to enter from here or before i should do something semplier?
08:48 imirkin: hakzsam: the commit hash ;)
08:48 imirkin: hakzsam: like f9b68040bd38584e3a063621613c4ea742ebacca
08:48 hakzsam: imirkin, btw, I ran this command to my personal repo "git remote set-url --push origin no-pushing"
08:48 hakzsam: imirkin, okay :)
08:48 imirkin: oooh, didn't know about that one
08:48 imirkin: but... that's too much. since i do want to be able to push :)
08:48 imirkin: just not by accident
08:49 hakzsam: okay
08:49 imirkin: tacchinotacchi: you can start whereever you want. however it helps to have a goal in mind.
08:50 tacchinotacchi: imirkin: if i work here my goal would be to help making reclocking code for fermi, since it's my gpu and reclocking is not at a good state for Fermi
08:50 imirkin: erm... how much time do you have to work on this?
08:51 tacchinotacchi: imirkin: the problem is this code looks pretty messy to me. It's easy to navigate through my code, but i find it difficult to understand how other people's code is organized
08:51 tacchinotacchi: imirkin: i've got plenty of time, that's not a problem
08:51 imirkin: ok. my estimate is that fermi reclocking will take ~6 months of full time work for a newcomer.
08:53 tacchinotacchi: imirkin: the thing is i don't know where to start to study the code. I don't have an "approach" yet
08:53 imirkin: although chances are you could develop something that worked on *just* your board much faster
08:53 tobijk: damn why did i remember that wrong, nvidia is really not allowing overlapping indexes for clip/cull
08:54 imirkin: tacchinotacchi: studying code is not the proper first step here. you need to study the hardware. stare at traces, try to make sense of them. then fiddle with the hw until it does the things you want.
08:55 imirkin: tacchinotacchi: take a look at nvkm/subdev/fb/ramnve0.c as a starting point
08:55 imirkin: er, ramgk100.c maybe?
08:55 tacchinotacchi: thanks
08:55 imirkin: tacchinotacchi: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/fb/ramgk104.c
08:56 tobijk: imirkin: i'd like to go the way you layed out in the email, think this is still the way to go? (we ust grant more freedom)
08:56 imirkin: this is the current logic for kepler
08:56 imirkin: tobijk: well, the nvidia impl may not be to spec
08:56 tacchinotacchi: imirkin: while you are absolutely right, you may not be considering that i don't know anything at all about dealing with nvidia hardware
08:56 imirkin: tobijk: so i wouldn't necessarily rely on it. check with Brian Paul, he was an extension author
08:57 tacchinotacchi: imirkin: for example i don't know the function to write to the gpu's memolry
08:57 imirkin: tacchinotacchi: no, i'm considering it. the 6 month estimate includes 1 month of intensive familiarization with the existing docs, etc
08:57 tobijk: imirkin: yeah it finally gets time :D
08:58 tacchinotacchi: imirkin: alright, i'll now try to make sense of ramnve0.c
08:58 tacchinotacchi: and ramgk100.c
08:58 imirkin: tobijk: either way, it's not something i can answer. if there's a non-conforming impl out there, i think the tendency is to get spec clarifications. however neither you nor i are in khronos, so we have to ask others to help
08:58 imirkin: tacchinotacchi: nve0 == gk100 btw. the files all got renamed. it's the chip id. gk = kepler. gf = fermi.
08:59 tacchinotacchi: imirkin: thank you
08:59 imirkin: tacchinotacchi: there's a totally half-baked and nonfunctional impl in ramgf100.c btw
08:59 tobijk: sure, but in my opinion we wont break something if we allow overlapping indexes, it will break on nvidia then ;-)
08:59 imirkin: tobijk: no, we will. the rules are different.
08:59 imirkin: tobijk: for example what if you do gl_ClipDistance[6] = 1; gl_CullDistance[7] = 1;
09:00 imirkin: tobijk: does that count as 15 used, or 8?
09:00 tacchinotacchi: imirkin: from my expierence, i can tell when i try to change my Fermi's clock via nouveau pstate socket it says "not implemented"
09:00 imirkin: tacchinotacchi: right. it's not enabled. coz it doesn't work :)
09:00 tacchinotacchi: imirkin: did you put some kind of lock there? it doesn't even trie
09:01 tacchinotacchi: imirkin: ok, could you do me one last favour
09:01 imirkin: it's not even supposed to work. it's just a basic script from someone's card that worked for their card only. and apparently doesn't anymore.
09:02 tacchinotacchi: imirkin: i don't know how to open unix sockets and deal with them from c code
09:02 imirkin: in case it's not clear, i'd suggest you pick a different first project
09:02 imirkin: not sure how that's relevant... but you open unix sockets like any other socket. just use AF_UNIX instead of AF_INET...
09:03 tacchinotacchi: imirkin: yea i got that, but some hour of studying code will not hurt me before i give up and try an easier project :)
09:03 tacchinotacchi: imirkin: thanks, i didn't remember INET where sockets just like UNIX
09:42 tobijk: imirkin: brianp is telling me clip[0] and cull[0] is allright and the driver should handle the combination of the TGSI_clip/culls into one array/register, i like it :D
09:42 imirkin: tobijk: that's roughly what i suggested, right?
09:43 tobijk: yep and the way i hoped it to work out :)
09:44 imirkin: do you have a piglit that demonstrates the fail on nvidia?
09:45 tobijk: yep, i'm about to answwer that same question for brian as well, will add you to cc there
09:59 imirkin: tobijk: actually he suggests having separate clip and cull distances
09:59 imirkin: and then letting the driver deal with it
10:03 tobijk: yeah that was what you proposed yesterday evening, no?
10:10 imirkin: tobijk: mmmmaybe
10:10 imirkin: i've proposed a lot of things
10:10 imirkin: ;)
10:50 tobijk: imirkin: hehe yeah, but thats my favorite way :)
11:13 imirkin: ok, nv30 swtnl is "fixed"
11:13 imirkin: or at least not quite as broken
11:13 imirkin: skeggsb: --^
11:45 l4mRh4X0r: imirkin: sorry, hadn't seen your message the other day. I would post the output, but I don't see nouveau in xrandr --listproviders anymore
11:45 l4mRh4X0r: The only change being (to my knowledge) an updated mesa
11:46 imirkin: l4mRh4X0r: sorry, i have no recollection of what your problem was...
11:47 l4mRh4X0r: My problem was that DRI_PRIME=1 glxinfo |fgrep "OpenGL vendor" still showed Intel after using xrandr --setprovideroffloadsink nouveau Intel
11:47 imirkin: ah right
11:47 imirkin: well, i need to see dmesg and xorg log
11:48 l4mRh4X0r: Still? I mean, xrandr --listproviders doesn't list nouveau anymore, so I can't use PRIME, right?
11:48 imirkin: offhand i'm guessing that you upgraded and are somehow using dri3, but aren't in the video group, and don't have permissions to write to /dev/dri/render* and mesa fails rather than falling back to dri2
11:49 l4mRh4X0r: Ah. You're right with me not being in the video group, let me fix that
12:01 glennk: think systemd likes to use ACL on the /dev/dri/render* rather than groups, can check using lsattr
12:03 l4mRh4X0r: glennk: you're right, getfacl shows I have write access
12:03 l4mRh4X0r: imirkin: Xorg.0.log: http://sprunge.us/egig, dmesg: http://sprunge.us/ZSYK
12:03 imirkin: l4mRh4X0r: nouveau E[ PGR][0000:01:00.0] grctx template channel unload timeout
12:04 imirkin: l4mRh4X0r: looks like your gpu isn't coming up properly
12:04 imirkin: l4mRh4X0r: did this work before?
12:05 l4mRh4X0r: Well, it did show up in xrandr --listproviders before, but I haven't had it working with PRIME yet
12:05 l4mRh4X0r: Although on an earlier install the nvidia driver and bumblebee worked fine
12:06 imirkin: nouveau has trouble coming up on a lot of laptop GK106's... although your failure looks different than "usual"
12:06 tobijk: it looks odd, lets blame gcc 5.1 ;-)
12:08 tobijk: oh intel puts out a nice trace as well later on
12:10 pmoreau: Meh... I'll have to do a lot of renaming in nouveau_acpi, it's too confusing!
12:11 pmoreau: Like dsm_detected = false if we detect an optimus_dsm_detected
12:12 tobijk: dsm_detected_not_optimus ;-)
12:12 pmoreau: :D
12:12 pmoreau: Except I will add an apple_gmux_dsm_deteced
12:12 pmoreau: So it will end up being dsm_detected_not_optimus_nor_apple_gmux
12:12 tobijk: yay
12:13 pmoreau: And I wonder if I will create an apple_gmux_v2_dsm_detected
12:13 pmoreau: s/will/should
12:14 tobijk: mh is the differenct that big between v1/v2?
12:14 pmoreau: Different function id, rev id and UUID
12:15 pmoreau: Or at least UUID and function id
12:15 l4mRh4X0r: Anything I can do to help diagnosing my issue by the way?
12:15 tobijk: mh but the out come is the bool apple_gmux_dsm_deteced? then i vote for just set that
12:16 pmoreau: And I'll try not to mispell detected :D
12:16 tobijk: :)
12:17 pmoreau: Yeah maybe; I was doing that when I wrote the patches localy.
12:17 pmoreau: But one thing I wonder is the difference between dsm_v1 and optimus_dsm as they are called in the code: how should I rename them?
12:18 pmoreau: In the end, they should all be optimus, including the Apple Gmux thing
12:18 tobijk: mh now i have to look ath the code to anywhere get you a sane answer :)
12:18 pmoreau: ;)
12:18 pmoreau: (Not sure the code will help)
12:20 pmoreau: Oh, an optimus laptop!
12:21 tobijk: where *duck and cover*
12:21 pmoreau: l4mRh4X0r's laptop
12:22 pmoreau: A few MMIO-write faults
12:23 pmoreau: And he doesn't want to suspend...
12:23 pmoreau: l4mRh4X0r: How does it go if you boot with runpm=0?
12:24 pmoreau: Probably not going to change much
12:27 tobijk: pmoreau: just distinguish between mux and muxless aka v1 and optimus?!
12:28 pmoreau: soft or hard mux?
12:28 pmoreau: cause the apple gmux is also a mux, but you're right, I forgot about that
12:29 tobijk: optimus is soft and v1 is hard
12:29 pmoreau: Ok
12:29 tobijk: or am i wrong here now :O
12:30 tobijk: at least that is my interpretation, but dont rely on me please :)
12:30 pmoreau: You seem right, nouveau_dsm is doing some mux stuff, which nouveau_optimus_dsm isn't doing
12:30 l4mRh4X0r: pmoreau: Well, I'll gladly try :P
12:31 l4mRh4X0r: Is that a kernel parameter?
12:31 imirkin: skeggsb: i'd really appreciate a review of "nv30/draw: rework some of the output vertex buffer logic" that i just sent out. i have no idea what that whole NV30_3D_VTXBUF_DMA1 deal is all about, but i saw it elsewhere, decided to copy :)
12:31 imirkin: i suspect it's more important for AGP than PCIe, but i only have PCIe
12:33 pmoreau: l4mRh4X0r: A parameter to nouveau, it should only help with not trying to power off the Nvidia card, and maybe with some freeze/slow down resulting from the power down failure
12:33 tobijk: imirkin: that description sounds like poking blind indeed
12:34 imirkin: tobijk: pre-nv50 don't have a gpu-side VM, so a lot more things have to be done "manually"
12:34 pmoreau: tobijk: I always thought Optimus was just being able to switch between IGD and DIS, be it using a hard mux or a soft one, but apparently it's only for soft mux.
12:34 imirkin: tobijk: that's what all that stupid "dma object" stuff is about... it stayed around on nv50, but it's completely pointless there. pre-nv50 it makes a lot more sense.
12:35 imirkin: pmoreau: optimus is when you can use both at once
12:35 tobijk: imirkin: ah ok
12:35 l4mRh4X0r: pmoreau: I can enable that for one boot by passing nouveau.runpm=0 as kernel parameter, right?
12:35 tobijk: pmoreau: with a hard mux you enable x and disable y at the same time
12:35 imirkin: l4mRh4X0r: that will force it to not suspend when not in use though.
12:35 pmoreau: l4mRh4X0r: Right
12:36 pmoreau: imirkin: But it's failing to suspend anyway :)
12:36 l4mRh4X0r: imirkin: yeah, that's what I understood from pmoreau already
12:36 l4mRh4X0r: But it should help diagnosing the issue, right?
12:36 l4mRh4X0r: As in, by confirming whether it's in the pm
12:37 imirkin: or disconfirming :)
12:37 l4mRh4X0r: Hence the whether :P
12:37 l4mRh4X0r: I'll give that a try then.
12:40 tobijk: pmoreau: just call it mux_dsm and optimus_dsm and set those in the apple ones as well
12:41 pmoreau: tobijk: Or just mux_dsm, optimus_dsm, apple_gmux_dsm
12:41 l4mRh4X0r: Well, at least it shows up again in xrandr --listproviders
12:42 pmoreau: It probably was removed as it tried to suspend, but wasn't put back as the suspend failed?
12:42 tobijk: is the apple one really a third one and if, whats the difference, not counting the dsm_methods
12:42 l4mRh4X0r: But still the problem with glxinfo outputting Intel as vendor
12:43 l4mRh4X0r: pmoreau: possibly.
12:43 pmoreau: tobijk: The handling of the mux is done by the apple_gmux driver inside the kernel (which also deals with the backlighting)
12:44 tobijk: ah! ok
12:44 pmoreau: l4mRh4X0r: It could be that the error imirkin pointed out is the one responsible for that
12:45 tobijk: l4mRh4X0r: your intel ddx is not capable of dri3
12:45 imirkin: l4mRh4X0r: until nouveau comes up properly in dmesg, no point in looking at xrandr or any other output
12:46 l4mRh4X0r: Right, just checked, still has the same error in dmesg
12:50 l4mRh4X0r: So, anything else I can do to help diagnose this?
12:51 tobijk: add a bugentry at f.do to not forget about the problem?
12:52 l4mRh4X0r: Fair enough. What should be in there, just the description of my problem and the xorg log and dmesg?
12:54 pmoreau: That would be the minimum
12:54 pmoreau: imirkin: Could a trace of the blob help in that case?
12:55 imirkin: couldn't hurt
12:55 l4mRh4X0r: How do I do that?
12:55 tobijk: optimus+nvidia = will hurt :D
12:56 pmoreau: l4mRh4X0r: https://wiki.ubuntu.com/X/MMIOTracing
12:57 l4mRh4X0r: Right. Time to get the proprietary driver then :P
12:57 tobijk: l4mRh4X0r: first get the nvidia driver to work, then care about tracing :)
12:57 pmoreau: True :D
12:58 l4mRh4X0r: Well, it has worked on this laptop before.
12:59 tobijk: l4mRh4X0r: ah well, trace a smaller app, not a full DE, wil ljust bloat things. you mainly want the gpu initialization
13:00 l4mRh4X0r: so, something like the glxgears one described on the ubuntu wiki?
13:00 pmoreau: You will need to run glxinfo or glxgears at least, just loading X isn't enough.
13:00 pmoreau: Yep
13:31 l4mRh4X0r: Managed to make an mmiotrace of glxinfo using bumblebee :)
13:32 l4mRh4X0r: What component do I file the bug against?
13:32 imirkin: xorg -> Driver/nouveau
13:32 l4mRh4X0r: okay
13:32 imirkin: the mmiotrace should be like 10-50MB right?
13:32 imirkin: if you xz -9 it, it becomes a lot smaller :)
13:32 tobijk: mh hope bumblebee wont change too much though
13:33 pmoreau: Yeah, I was going to ask about it
13:33 tobijk: l4mRh4X0r: preferably go the hard way without bumblebee (thats way harder to config though)
13:36 l4mRh4X0r: tobijk: Yeah, bumblebee was the fastest way to get this right now, as I have to leave soon
13:36 tobijk: we intend to stick around for a while, so take your time :)
13:37 tobijk: and with we i mean nouveau
13:38 l4mRh4X0r: I know, but at least you have something to work on this way. I'll try to work on a "proper" mmiotrace later on
13:45 l4mRh4X0r: imirkin: my mmiotrace was 103 MB, shrunk down to 5.9 MB. Still too large to attach on bugzilla
13:45 imirkin: l4mRh4X0r: email to mmio.dumps@gmail.com
13:45 l4mRh4X0r: Alright. Shall I mention in the bug report I sent it there?
13:46 imirkin: yes please
13:47 pmoreau: And if you could put the card chipset in brackets at the begin of the mail subject, that would be nice :)
13:51 l4mRh4X0r: Whoops, too late
13:51 pmoreau: No problem
13:51 pmoreau: I'll add a label in the mailbox
13:52 l4mRh4X0r: Alright. Well, good luck, I'm off now
13:52 pmoreau: See you!
15:07 imirkin: bleh, come to think of it, clipping is probably broken with nv30/draw
15:08 imirkin: unless... draw clips? that'd be neat.
15:10 imirkin: ooh, fancy. looks like it does.
15:10 imirkin: [probably a bad idea but... wtvr]
15:13 tobijk: its not like nv30 user will care for real speed
15:34 imirkin: pmoreau: fyi, "preciser" -> "specify". "precise" in english means "précis", and can't be a verb.
15:36 tobijk: pmoreau: i like that series, makes it
15:36 tobijk: a lot cleaner
15:41 imirkin: pmoreau: "Add support for Apple Gmux _DMS" -- _DSM i presume?
15:42 tobijk: imirkin: (not pmoreau) yes that is right :)
17:20 imirkin: ok... with my outstanding patches and the stuff i pushed, nv30 swtnl is in _much_ better shape
17:22 tobijk: well send the outstanding ones to the ml, or did i just happen to oversee them :/
17:23 imirkin: there are 2
17:36 imirkin: the gart one and the texcoord one
17:38 tobijk: yeah found them in my trash *urgh*
17:49 imirkin: tobijk: i'm not particularly happy about the gart thing either. however gart is the right place for this data.
17:49 imirkin: but why it didn't work in vram... dunno.
17:50 tobijk: mhm
17:51 skeggsb: imirkin: they look fine to me, but yes, i am a bit concerned about the vram thing too, i can't think of a good reason either
17:52 skeggsb: imirkin: and, the DMA0/1 stuff are to set bits that select one of two possible dma object slots that can be used as the "aperture" that the buffer offset belongs to
17:52 skeggsb: there's no unified address space before nv50
17:53 skeggsb: so we have a "gart" ctxdma and a vram one
17:57 tobijk: going to bed, see you guys :)
17:58 imirkin: skeggsb: ah ok. but if the object is in vram, we don't want to set that at all?
17:58 imirkin: skeggsb: or do we still want the dma object?
17:58 skeggsb: imirkin: iirc (which, to be fair, i might not be), for vtxbuf there's just one bit, when it's 0 it selects DMA0
17:59 skeggsb: (which we point at vram)
17:59 imirkin: ahhh ok. so DMA0 = vram, DMA1 = gart?
18:00 skeggsb: yep, that's how we should be configuring it anyway
18:00 imirkin: right, i realize that some other driver could do it differently
18:00 skeggsb: PUSH_DATA (push, fifo->vram); /* VTXBUF0 */
18:00 skeggsb: PUSH_DATA (push, fifo->gart); /* VTXBUF1 */
18:00 imirkin: ok, i'll play with it a bit more then... set DMA0 for when i stick it into VRAM
18:00 skeggsb: yep, we are
18:01 imirkin: and wtf is up with only nv40 being able to get indexbufs from vram?
18:01 imirkin: but not nv44?
18:01 skeggsb: nfi, you'd have to ask nvidia that one
18:01 imirkin: i tested it out, and that indeed appears to be the case
18:01 skeggsb: they removed the methods in 0x4497...
18:01 imirkin: very odd.
18:01 skeggsb: indeed
18:09 imirkin: gah. well. i can no longer repro the fail
18:10 imirkin: ah there ya go
18:10 imirkin: apparently PUSH_RESRC is smart enough not to append that DMA1 on there unless it's actually in vram
18:10 imirkin: er
18:10 imirkin: actually in GART
18:11 imirkin: yeah ok. so that was the defining change.
18:11 imirkin: let me split those apart into something a little more logical-seeming
18:22 imirkin: hm... supertuxkart still shows a tiny bit of fail with swtnl
18:22 imirkin: but... it's close
18:33 imirkin: skeggsb: i think the patches i just sent out make a lot more sense
18:35 skeggsb: imirkin: feel free to add my R-b
18:35 imirkin: to which? whole thing, or just 1+2?
18:36 skeggsb: 1+2 i guess, the others look fine, but i'm mostly trusting you know what you're doing there because i don't :P
18:36 imirkin: i've been pushing without r-b pretty freely, so don't feel pressured ;)
18:36 imirkin: i'll add your r-b to the 1+2 before i push though
18:36 imirkin: esp '1' is the type of thing i'm pretty iffy on
18:37 imirkin: still something wrong though... the floor texture in stk was coming out wrong
18:37 imirkin: which means that there's some sort of fail for the later texcoords... ugh
18:37 imirkin: and we don't have a disasm that i can stick the opcodes into
18:38 imirkin: i have a local one for nv40fp, but not vp
18:51 imirkin: skeggsb: any ideas on https://bugs.freedesktop.org/show_bug.cgi?id=90567 btw?