IRC Logs of #nouveau on irc.freenode.net for 2011-02-28

00:04 #nouveau: < mupuf> pq: fixed
00:18 #nouveau: < pq> mupuf, thanks. Btw if you want to use the wiki's heading numbering, you can look InstallDRM sources for an example.
00:19 #nouveau: < pq> right now you have two 2's
00:23 #nouveau: < mupuf> pq: oh, cool! thanks
00:27 #nouveau: < mupuf> have to go now, have a good day
03:10 #nouveau: < calim> darktama: the mipmap thing wasn't a new bug, it was just "we're fast now so we need to sync render to texture properly"; so I guess I can push it now
03:23 #nouveau: < darktama> calim: ah cool
03:23 #nouveau: < darktama> calim: btw, give nouveau git a shot, curious as to whether "page jumping" is gone now..
03:24 #nouveau: < calim> yes, I already recompiled
03:26 #nouveau: < darktama> anything exciting to report?
03:30 #nouveau: < darktama> calim: assuming nothing else pressing comes up, i'll probably start attempting to merge bits together tomorrow
03:32 #nouveau: < calim> hm ... it seems unstableish now
03:32 #nouveau: < darktama> oh? mine seemed fine
03:33 #nouveau: < calim> let's try again, I just had an input lockup, the graphics kept running
03:33 #nouveau: < darktama> i briefly thought the large/small page hack removal busted 3d, but, i was running a dodgy 3d driver (oops!)
03:34 #nouveau: < calim> more vm flush times it seems
03:34 #nouveau: < calim> *timeouts
03:34 #nouveau: < darktama> yeah, there'll be more flushes now.. we probably should figure out a better flush wait
03:35 #nouveau: < darktama> i don't see the timeout very often though
03:36 #nouveau: < calim> it happens when I resize my gnome-terminal (or is it xfce Terminal, I they're so similar), but not when loading textures in games ... page jumping seems gone
03:37 #nouveau: * darktama is wondering if his nva8 will lockup at all now
03:37 #nouveau: < darktama> it hasn't all day since that commit
03:45 #nouveau: < calim> http://cgit.freedesktop.org/mesa/mesa/log/?h=nvc0&showmsg=1
03:45 #nouveau: < darktama> nice :)
03:45 #nouveau: < darktama> does that include the recent nvc0 commits?
03:46 #nouveau: < calim> some, not the shader backend fixes though
03:47 #nouveau: < calim> well, I tried to get in all of the others where possible
03:48 #nouveau: < calim> I didn't replace clip-with-SCISSOR with clip-with-VIEWPORT because I can't turn off the viewport rect's effect on clears
03:48 #nouveau: < calim> well, I could, but then the scissor's rect would, like OpenGL specifies, but gallium ...
03:49 #nouveau: < darktama> yeah
03:49 #nouveau: < darktama> ucp stuff seems missing too?
03:49 #nouveau: < calim> so, some control-flow piglit tests might still cause endless loops now
03:49 #nouveau: * darktama just trying to get an idea of what there is to do
03:50 #nouveau: < darktama> trying to resist going back to zcull before doing the boring mergy stuff :)
03:50 #nouveau: < calim> yes, I just started editing the tarball yesterday night, thought about adding the UCPs now too, but then I decided I'd better push right now
03:50 #nouveau: < calim> *tarball's version
03:51 #nouveau: < calim> but I fixed the AUX constbuf mapping (I hope)
03:51 #nouveau: < pq> calim, that commit, sconscript has nv50_push2.c but Makefile does not. Is that a mistake?
03:51 #nouveau: < calim> so uploads of UCPs shouldn't trigger faults now
03:51 #nouveau: < calim> pq: yes
04:09 #nouveau: * calim had to reboot to activate ZCOMP - OA: old: 90 fps, new: 140 fps, +zcomp: 170 fps, +pageflip: 190 fps
04:09 #nouveau: < darktama> calim: ah, you've implemented for nvc0?
04:10 #nouveau: < darktama> zcomp, that is
04:13 #nouveau: < darktama> hm, "old" would imply nv50 actually i guess :)
04:42 #nouveau: < calim> darktama: yep, 9600M GT, low memory bandwidth -> noticeable effect from both zcomp and pageflip
04:49 #nouveau: < calim> now I want HiZ too ...
04:49 #nouveau: < calim> maybe we could use software methods instead of an ioctl for window allocation
04:51 #nouveau: < darktama> yeah i hadn't quite figured out the best way to do that yet
04:51 #nouveau: < darktama> i started looking at it last week
04:54 #nouveau: < calim> hm, but swmthds can't return the window id, we could inject it (into dispatch ?), but not sure if that's nice
04:54 #nouveau: < darktama> i'd like a new bo ioctl anyway, to remove the nastyness from the current one.. probably with a chipset-specific data field, sort-of like pscnv's "user" field
04:55 #nouveau: < darktama> i coded up the libdrm changes last week for it, removing bo_new_tile, and adding a "user" pointer to bo_new carrying tile_mode/tile_flags/window_size for nv50.. and for <nv50 the 16/32/zeta flags the drm uses there
04:58 #nouveau: < calim> nice, do we get addresses too then already ?
04:58 #nouveau: < darktama> yes, that was part of it too
04:58 #nouveau: < calim> ah, then I can do the negative offset trick for temporary vertex storage
05:00 #nouveau: < darktama> i didn't come up yet with a good way to do buffer validation without relocs.. something like classic dri / nvc0's way looks nice i guess
05:00 #nouveau: < darktama> of course, relocs are still there for <nv50..
05:01 #nouveau: < calim> sure, they need them; but they also need less
05:01 #nouveau: < darktama> yes, far far less
05:01 #nouveau: < calim> well, 1/2 at least :-)
05:02 #nouveau: < calim> well just have to be careful that wherever the was a reloc there's a validation call now
05:02 #nouveau: < darktama> yeah, and that's relatively easy really
05:02 #nouveau: < darktama> just a PITA to change it all :)
05:03 #nouveau: < darktama> and.. there's also the fact that doing once making libdrm reloc-less for >=nv50.. it introduces a dependency on 2.6.39 if you don't wan't it to crash randomly..
05:03 #nouveau: < calim> so, the nv50_resource.offset can be replaced by address again
05:04 #nouveau: < calim> true, that'll be fun for the users; I guess we could wait a while with removing the relocs so to not make it all that painful
05:04 #nouveau: < darktama> yeah, well libdrm will still have them, the fun won't begin until we stop using them in the ddx/mesa
05:06 #nouveau: < calim> the fun already begins when mesa/nvc0 is merged to master again
05:06 #nouveau: < calim> for pre-2.6.38 users
05:06 #nouveau: < darktama> that's true
05:06 #nouveau: < darktama> :)
05:14 #nouveau: < darktama> we could make it fail horridly at init for said users i guess
05:15 #nouveau: < darktama> better than a ton of "omg random crap got rendered and then it locked up" reports
05:16 #nouveau: < calim> yes, sounds good
05:25 #nouveau: < pq> since I haven't seen this being asked in a long while because it's a "banned" topic; is there a roadmap for out of staging in kernel yet?
05:36 #nouveau: < calim> step 1: convince ourselves that nouveau is stable enough - I'm having a really hard time with step 1
05:38 #nouveau: < pq> hardware-wise? API-wise you seem to be a lot wiser now than, say, a year ago.
05:39 #nouveau: < calim> yes, hardware wise; people always come with mysterious crashes
05:39 #nouveau: < calim> at least on a certain class of chipsets ...
05:40 #nouveau: < pq> IMO hardware stability issues do not affect much on getting out of staging, the driver can still be experimental. It's the API issues that are more important in that sense. Unless there are hardware issues that force an API change.
05:44 #nouveau: < pq> should probably also ask, what does getting out of staging benefit anyone...
06:07 #nouveau: < calim> pq: it gets us not-kicked out of mainline, at some point people will probably start complaining
06:26 #nouveau: < pq> calim, at some point, maybe, but Nouveau is too important to be kicked out. More likely someone force-unstages Nouveau, a bit like what happened when it went into staging from out-of-tree.
10:54 #nouveau: < mupuf> calim: when do you plan to merge the nvc0 branch on mesa master?
10:56 #nouveau: < calim> when regressions are eliminated and code is being shared
10:59 #nouveau: < mupuf> seems pretty reasonable. I'll hold the new TiDNC a bit for it. Releasing it the same day as the previous one seems a good idea to me :)
10:59 #nouveau: < mupuf> it's in a bit more than two weeks
11:00 #nouveau: < calim> that won't be enough for the merge
11:01 #nouveau: < mupuf> ok, then, I can release it soon and make another one in a month like it used to be
11:02 #nouveau: < mupuf> OA: old: 90 fps, new: 140 fps, +zcomp: 170 fps, +pageflip: 190 fps. Old=mesa master's nv50, new=nvc0's branch, zcomp=not commited yet
11:03 #nouveau: < mupuf> right?
11:03 #nouveau: < calim> no, the compressed z buffer is created by the DDX
11:13 #nouveau: < Alexie> would any of the code get shared with other nv chipsets?
11:14 #nouveau: < Alexie> apart from nv50s?
11:14 #nouveau: < calim> no
11:14 #nouveau: < calim> well, actually yes, some buffer code might be shared with nvfx
11:15 #nouveau: < Alexie> nice:)
11:16 #nouveau: < calim> lynxeye1: you asked some time ago about moving the buffer suballocation to libdrm - I won't do that because the stuff libdrm does should actually be moved to a gallium winsys and the dependency on libdrm removed
11:20 #nouveau: < ymanton> and what do you do for the ddx? xorg st?
11:22 #nouveau: < calim> the DDX keeps using libdrm
11:24 #nouveau: < ymanton> ok, so by moved to gallium you mean copied
11:25 #nouveau: < calim> more or less; but no plans to actually do that in the near future (radeon have done it recently)
11:43 #nouveau: < Alexie> what's "winsys"?
11:43 #nouveau: < Alexie> where does that fits in on the opengl stack
11:43 #nouveau: < Alexie> isit just a library that links in with the drivers and other stuff?
11:43 #nouveau: < mupuf> calim: has z-comp landed in the ddx? I saw some commits but I'm not sure the support is complete
11:44 #nouveau: < calim> Alexie: it's the OS specific part and has nothing to do with windows
11:44 #nouveau: < calim> (but with command submission and memory management)
11:44 #nouveau: < calim> mupuf: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=42c16ff33dcca6cd9bae62fe0d71a40452e03581
11:45 #nouveau: < calim> yes, in userspace it's as simple as saying "this is compressed now"
11:45 #nouveau: < mupuf> calim: what about the kernel side? Is it to land on the 2.6.38 ou .39?
11:46 #nouveau: < Alexie> I see texcompress.* has made it into the tree, is this the non patented texture compression stuff?
11:46 #nouveau: < calim> mainline 2.6.38 doesn't have it I think
11:46 #nouveau: < calim> Alexie: yes, RGTC in this case
11:48 #nouveau: < Alexie> I just did a diff on GL3.txt and yeah its done, good work
11:49 #nouveau: < calim> it says r600, but nv50 has been ready for RGTC as well for a long time
11:55 #nouveau: < RSpliet> latest GIT fixes visual corruption on NVA8
11:55 #nouveau: < RSpliet> she's smooth as a baby's bottom again, good work!
11:59 #nouveau: < Alexie> llvmpipe doesn't support rgtc yet, i see
12:01 #nouveau: < mupuf> RSpliet: when was this issue introduced?
12:01 #nouveau: < RSpliet> mupuf: new memory manager
12:01 #nouveau: < mupuf> please keep us informed whether it also solved the instability or not
12:02 #nouveau: < RSpliet> mupuf: will do, although that bug is way way older
12:02 #nouveau: < RSpliet> set her to be my default kernel now, so I'll soon find out how frequent lockups become
12:03 #nouveau: < mupuf> RSpliet: I know, but darktama said it may have fixed it too (If I read what he said correctly)
12:03 #nouveau: < mupuf> why "her"? :)
12:04 #nouveau: < RSpliet> things I love must be female
12:04 #nouveau: < mupuf> :p
12:05 #nouveau: < RSpliet> I'm actually more curious if this fixes corruptions on NVAC as well, but I'm not doing a development kernel on that machine :$
12:06 #nouveau: < RSpliet> I'd consider if it were in koji, but all those kernels are GCC4.6
12:49 #nouveau: < calim> darktama: page jumping is back
13:28 #nouveau: < mupuf> calim: How would you define z-compression?
13:28 #nouveau: < mupuf> if you have some pointers to some doc, it would be appreciated
13:45 #nouveau: < mwk> mupuf: Z compression is when you attempt to store tiles made of simple gradients of Z in a compressed form
13:46 #nouveau: < mwk> the compressed form is "pixel (x,y) in this nx4 tile is A + x * B + y * C"
13:47 #nouveau: < mwk> when ROP, on writing a Z tile, realises that the tile is of that simple form, it just writes these 3 parameters - A, B, C instead of all pixels in tile
13:47 #nouveau: < mwk> and tags a tile as compressed
13:47 #nouveau: < mwk> the "tile" is 0x80 bytes, 0x20 bytes per line * 4 lines, how many pixels that is depends on the zeta format in use
13:48 #nouveau: < mupuf> what do you mean by simple grandients of Z?
13:48 #nouveau: < mwk> and A, B, C are stored in a funny floating point sorta-shared-exponent format... I nailed down most of its inner format, but not all. could push the known details if anyone cares.
13:49 #nouveau: < mupuf> mwk: I think I'll just quote you, no way I can explain that :D
13:49 #nouveau: < mwk> simple gradient is... well, it's when Z is a R^2 -> R linear function
13:49 #nouveau: < mwk> sigh, ok.
13:49 #nouveau: < mwk> I'll explain again...
13:50 #nouveau: < mwk> say, you render a single primitive... triangle or whatever
13:50 #nouveau: < mwk> one of the per-pixel values you compute & write is the Z value, of course
13:50 #nouveau: < mupuf> indeed, of course ;)
13:51 #nouveau: < mwk> its format is variable, the two interesting ones are 24-bit unsigned integer, and 32-bit float
13:51 #nouveau: < mwk> given a single primitive, and without depth-modifying shader, the resulting Z values will be linear over the polygon
13:52 #nouveau: < mwk> ie, there are such A, B, C coefficients that, for any x,y inside the primitive, Z[x][y] == A + B * x + C * y
13:53 #nouveau: < mupuf> ok, that makes sence
13:53 #nouveau: < mwk> good
13:53 #nouveau: < mwk> so, the zeta buffer is split into 0x100-byte roptiles, like all tiled surfaces
13:54 #nouveau: < mwk> the roptiles are 4 lines, 0x40 bytes each.
13:54 #nouveau: < mwk> for compression purposes, they're further split into 2 "compression tiles", 4 lines of 0x20 bytes
13:54 #nouveau: < mwk> this works out to 8x4 pixels if using 32 bpp zeta format, 4x4 if 64 bpp
13:55 #nouveau: < mwk> if the surface is compressed, it has a piece of hidden "tag memory" associated with it - 1 bit for every compression tile
13:56 #nouveau: < mwk> now, if such a tile lies wholly inside a single polygon, then all pixels in it have their Z value equal to the A + B * x + C * y
13:56 #nouveau: < mwk> ROP can detect it when writing Z values, since it writes out a tile at once [I think]
13:56 #nouveau: < ymanton> what if 2 tris intersect a tile bit they're still coplanar?
13:56 #nouveau: < ymanton> but*
13:57 #nouveau: < mwk> when it detects that, the tag bit for the tile is set to 1, and only the A, B, C values are written to the VRAM underlying zeta
13:57 #nouveau: < mwk> if it cannot guarantee that for a given tile [or compression is disabled], it'll write 0 to the tag bit, and write all individual pixels instead
13:58 #nouveau: < mwk> ymanton: ROP cannot see that, it'll just write uncompressed
13:58 #nouveau: < mwk> mupuf: further, that's all transparent to the user
13:58 #nouveau: < mupuf> thanks for the explanation, it makes perfect sense
13:58 #nouveau: < mwk> the memory controller frontent knows about the compression, and also has access to the tag memory
13:59 #nouveau: < mwk> if you attempt to read out a compressed tile in any way [BAR, texture, blit source, ...], it'll read the A, B, C values and compute the value of all pixels in tile from that
14:00 #nouveau: < mupuf> ok, so it really is transparent
14:00 #nouveau: < mwk> yep
14:00 #nouveau: < mupuf> nice piece of harware
14:00 #nouveau: < mwk> except for the part where you have to allocate the tag memory.
14:01 #nouveau: < mwk> that's scary.
14:01 #nouveau: < mupuf> :) it is yes
14:01 #nouveau: < mwk> on nv50 and nvc0, you write all relevant information to the page tables
14:02 #nouveau: < mwk> the format [aka storage type], compression mode, tag address
14:02 #nouveau: < mwk> [or, if on nv50 and not using paging, into the DMA object.]
14:03 #nouveau: < mwk> pre-nv50 cards instead had 15 or 16 "special regions" you could set up in VRAM for compressed surfaces
14:03 #nouveau: < mwk> or for tiling, for that matter
14:04 #nouveau: < mwk> there's also color compression, which is much less interesting
14:04 #nouveau: < mupuf> mwk: has the support for nv50- landed yet?
14:04 #nouveau: < mwk> no idea
14:05 #nouveau: < mupuf> I remember color compression gave some perf boost on r300
14:05 #nouveau: < mwk> I'm just REing that, implementation is not my thing
14:05 #nouveau: < mwk> color compression is only useful when using 4x or 8x multisampling
14:06 #nouveau: < mwk> most of the time, multisampling results in pixels having identical color values for all 4 samples
14:06 #nouveau: < mwk> or 8 samples
14:07 #nouveau: < mwk> color compression trivially exploits it... tag == 0 is uncompressed and all individual samples are written, tag == 1 is compressed, and only one sample per pixel is written, others are assumed to be identical
14:08 #nouveau: < mwk> like zeta compression, it's handled transparently by hardware
14:08 #nouveau: < mupuf> do we have multisampling support in gallium?
14:08 #nouveau: < calim> no
14:08 #nouveau: < mwk> bwahahahaaahahah
14:08 #nouveau: < mwk> hahahahahahha
14:08 #nouveau: < mwk> hahhaha.
14:08 #nouveau: < mwk> no.
14:09 #nouveau: < mupuf> :D So, does it simply ignore the parameter when the application requests for it?
14:09 #nouveau: < calim> nvc0 has non-multisample color compression though ...
14:09 #nouveau: < mwk> no, you simply cannot select it
14:09 #nouveau: < mupuf> I can in openarena, I guess it is ignored then
14:09 #nouveau: < mwk> well, it does support multisampling. specifically, the 1x multisampling mode.
14:10 #nouveau: < mwk> with GLX, you select multisampling [for the main framebuffer, anyway] by requesting a GLX visual or fbconfig with appropriate multisample_samples attribute
14:10 #nouveau: < mupuf> mwk: I still remember what you said to me in June, "watch out or you'll become highly ironical (it was another adjective) like the rest of us"
14:11 #nouveau: < mwk> GLX doesn't export any visuals with >1x multisample, so there's no way you can request it
14:11 #nouveau: < ymanton> non-multisampled color compression... for all of those flatshaded bandwidth hogs
14:12 #nouveau: < mwk> hm does it...
14:12 #nouveau: < mwk> oh yeah, it has non-multisampled compression. I wonder htf it works.
14:12 #nouveau: < calim> and best part, it's so useful that blob always uses it
14:13 #nouveau: < mwk> *shrug*
14:13 #nouveau: < mwk> maybe it doesn't have anything better to do with all this tag memory
14:14 #nouveau: < mwk> hm, actually maybe it's not THAT useless
14:14 #nouveau: < mwk> a remarkably common uniform-color primitive is... glClear()
14:15 #nouveau: < ymanton> and for 2d maybe
14:16 #nouveau: < ymanton> but even then its not that much overdraw
14:18 #nouveau: < mupuf> mwk: is color tiling an always-faster solution or is it an heuristic? I guess you would need some benchmarks to know that
14:18 #nouveau: < mwk> tiled surfaces are almost always superior to linear surfaces
14:19 #nouveau: < mwk> if that's what you mean
14:20 #nouveau: < mwk> they get you much more cache locality... also some parts of GPU will just refuse to work with linear surfaces since they're designed with low-level knowledge of the tiling
14:25 #nouveau: < mupuf> mwk: ok, I was thinking about the performance loss when using color tiling on ..... white noise
14:27 #nouveau: < mwk> you mean compression, not tiling, right?
14:27 #nouveau: < mwk> well the tag memory costs... memory, of course
14:27 #nouveau: < mupuf> yes, sorry, compression
14:28 #nouveau: < mwk> on nv50 it's dedicated, so it'd be wasted if you didn't use it. on nvc0, it's small dedicated cache backed by arbitrary-length area of VRAM
14:28 #nouveau: < mwk> ie. on nvc0 it costs you a bit of VRAM to compress memory
14:29 #nouveau: < mwk> but it's quite tiny
14:31 #nouveau: < mwk> on the order of 1/400 of the buffer's size, and the memory access bandwidth cost is similar
14:34 #nouveau: < mupuf> ok, so, color compression is very cheap and can boost performance a lot on cards with slow memory
14:34 #nouveau: < mupuf> or on cards that have been downclocked
14:35 #nouveau: < calim> certainly not "a lot"
14:36 #nouveau: < mupuf> calim: even if the memory is clocked at a tenth of its original speed?
14:37 #nouveau: < mupuf> on games like tron where colors are the same everywhere, it should have an impact
14:38 #nouveau: < Alexie> just a query; is there a reason why there are nouveau_dri.so and nouveau_vieux_dri.so libraries?
14:40 #nouveau: < RSpliet> Alexie: vieux = old, NV4x and below iirc
14:41 #nouveau: < ymanton> <=nv20
14:41 #nouveau: < chithead> nv30/nv40 are nvfx. below are nouveau_vieux
14:41 #nouveau: < Alexie> I'm currently tracking down a bug that crashes X in nouveau_vieux.
14:42 #nouveau: < Alexie> the problem is that somehow a buffer object is null before being used hence the crash
14:42 #nouveau: < Alexie> I've updated my mesa git tree and rebuilding before testing again.
14:42 #nouveau: < Alexie> I have got this far:
14:43 #nouveau: < Alexie> [ 24395.696] (WW) NOUVEAU(0): OK2
14:43 #nouveau: < Alexie> [ 24395.696] (WW) NOUVEAU(0): [ppix] devPrivates = 0x846a800, refcnt = 1, devKind = 1200, screen_x = 0, screen_y = 0
14:43 #nouveau: < Alexie> [ 24395.696] (WW) NOUVEAU(0): [nvbuf->base] attachment = 1, name = 0, pitch = 1200, cpp = 4, flags = 00000000, format = 00000000, dr
14:43 #nouveau: < Alexie> iver = 0x858fce0
14:43 #nouveau: < Alexie> [ 24395.696] (WW) NOUVEAU(0): [nouveau_pixmap(ppix)->bo] (nil)
14:43 #nouveau: < Alexie> (at this point X dies a horrible death)
14:43 #nouveau: < mwk> mupuf: we're very unclear on how non-ms color compression works, since it's nvc0+ only and noone had a look so far
14:43 #nouveau: < mupuf> mwk: ok, it doesn't really matter anyway. Thanks for answering
14:43 #nouveau: < mwk> but compressing colors is *hard*
14:44 #nouveau: < mwk> you barely ever get exactly identical colors written
14:44 #nouveau: < mwk> and ROP would have to detect it somehow, too
14:44 #nouveau: < darktama> Alexie: nouveau_pixmap(ppix), is that NULL, or just ->bo ?
14:44 #nouveau: < Alexie> ->bo
14:46 #nouveau: < darktama> we probably should check that i guess, and return failure from get_buffers.. in nv_accel_common.c, can you add debugging showing what "ret" is if nouveau_bo_new_tile() fails?
14:46 #nouveau: < darktama> and print the arguments it was passedthat caused it to fail
14:47 #nouveau: < Didier_Spaier> mupuf, joi, xexaxo_: I'm back with good news: running the last mesa 7.10 from git with nouveau I get twice more FPS than with 7.9 ;-)
14:48 #nouveau: < mupuf> Didier_Spaier: good news :)
14:48 #nouveau: < Didier_Spaier> To compile it I did "make realclean && make linux-x86-32", IOW without dri.
14:49 #nouveau: < xexaxo_> Didier_Spaier: sweet, is that (2x) on a particular test only ?
14:50 #nouveau: < Didier_Spaier> xexaxo_: Under fluxbox, start an xterm and run glxgears for one minute.
14:52 #nouveau: < Didier_Spaier> xexaxo_: if you know of some more serious test, I'd be happy to try.
14:52 #nouveau: < Alexie> this line nouveau_bo_handle_get(nouveau_pixmap(ppix)->bo, &nvbuf->base.name); seems to crash the X server
14:52 #nouveau: < darktama> Alexie: see above
14:52 #nouveau: < Alexie> yeah, I'll do that just as soon as my mesa gets done
14:54 #nouveau: < xexaxo_> Didier_Spaier: I was asking in general, but you can still give it a try with nexuiz or oa (if you are into that sort of things)
14:57 #nouveau: < Didier_Spaier> xexaxo_: well, though I be not really a gamer (sorry but I'm 62 already, lol), I'll give a nexuiz a try ;-)
14:58 #nouveau: < mupuf> darktama: hi, will the z-compression land in the 2.6.39 or in the .40?
14:58 #nouveau: < darktama> .39
14:58 #nouveau: < mupuf> ok, thanks
14:59 #nouveau: < Alexie> on startup, it says [ 26612.693] (WW) NOUVEAU(0): nouveau_bo_new_tile() returned FALSE
14:59 #nouveau: < Alexie> And when I run glxinfo, i get this
14:59 #nouveau: < mupuf> darktama: Will you have time to talk about my pause/unpause patch in a few minutes? I now have time to work on it again
15:00 #nouveau: < Alexie> http://ompldr.org/vN2x0OQ
15:00 #nouveau: < Alexie> at the bottom
15:03 #nouveau: < Alexie> the crash isn't happening in that function, I'm looking at nouveau_dri2_init now
15:05 #nouveau: < mupuf> http://nouveau.freedesktop.org/wiki/Nouveau%20Companion%2044 Final review for those interested in re-reading it
15:11 #nouveau: < Alexie> xf86DrvMsg(scrn->scrnIndex, X_WARNING, /* AIB */ "[nouveau_pixmap(ppix)->bo] %p\n", nouveau_pixmap(ppix)->bo);
15:11 #nouveau: < Alexie> OK it definitely crashed trying to access nouveau_pixmap(ppx)->bo
15:15 #nouveau: < chithead> mupuf: xf86-video-intel is also kms-only since 2.10
15:18 #nouveau: < Alexie> ok this gets trickyt
15:19 #nouveau: < Alexie> right, the first time it calls the function it's OK
15:19 #nouveau: < Alexie> but the second time it calls the function, it crashes
15:20 #nouveau: < Alexie> the bug mght be in lines 56-60
15:21 #nouveau: < mupuf> chithead: thanks
15:21 #nouveau: < Alexie> http://ompldr.org/vN2x0aQ <-- latest with new debug
15:24 #nouveau: < mupuf> fuck, I was about to say the phoronix guy not to talk about the new TiNDC and he jus has
15:24 #nouveau: < Alexie> mupuf: teehee. Next time just wait until it's ready
15:25 #nouveau: < Alexie> that's why I don't like journalists, they've got big mouths
15:25 #nouveau: < mupuf> Alexie: well, the content of the article would have changed anyway
15:25 #nouveau: < chithead> hehe, he tells users to keep on reading phoronix instead
15:25 #nouveau: < mupuf> and editing on a wiki is way simpler
15:33 #nouveau: < Alexie> yeah, mupuf, tindc 44 is looking good!:)
15:33 #nouveau: < mupuf> glad you liked it
15:34 #nouveau: < mupuf> I'll try to make a sequel later on
15:34 #nouveau: < mupuf> this is a good exercise to check you understand at least a little what is going on
15:35 #nouveau: < Alexie> ok i'm just gonna debug nouveau_bo_handle_get, it seems to be exploding
15:37 #nouveau: < Alexie> yeah, mupuf, it's good to know what's everyone is up to
15:37 #nouveau: < Alexie> i'm trying to trace a bad X crash with the _vieux driver at the moment
15:51 #nouveau: < MaximLevitsky> Hi folks
15:51 #nouveau: < MaximLevitsky> Just read the Nouveau Companion 44
15:52 #nouveau: < MaximLevitsky> So, the FuC processor is really named like that bt nvidia :-8 ? I was sure it is a slightly misspelled swear word :-)
15:53 #nouveau: < MaximLevitsky> *it was*
15:54 #nouveau: < calim> it says "that we named FuC", and we != nvidia
15:55 #nouveau: < MaximLevitsky> Yea, but it names it, function micro controller, thus somewhat gives an impression that it is a official name
15:56 #nouveau: < mupuf> MaximLevitsky: can you suggest another way to formulate the sentence?
15:56 #nouveau: < MaximLevitsky> mupuf: why bother, I don't see anything wrong with it
15:56 #nouveau: < mupuf> it mislead you ;)
15:57 #nouveau: < MaximLevitsky> Ah, just wanted to say something here
15:57 #nouveau: < Alexie> mupuf: just say FuC out very loudly, and you'll see lol
15:58 #nouveau: < MaximLevitsky> I am very happy with the progress of the nouveau
15:59 #nouveau: < mupuf> MaximLevitsky: glad to hear. This was just communication, the work was being done even though it wasn't really visible
16:05 #nouveau: < mupuf> Alexie: I can curse in English, German or French, I'm from southern France and people curse all the bloody time there.
16:06 #nouveau: < mupuf> there is a famous joke that we say "fuck" as a punction mark (what would be written as a coma)
16:06 #nouveau: < mupuf> punctuation*
16:07 #nouveau: < Alexie> ah ;)
16:07 #nouveau: < Alexie> ou est la poupet?
16:07 #nouveau: < mupuf> la poupée? No idea where the doll is :D
16:08 #nouveau: < Alexie> oh, it's a joke
16:08 #nouveau: < Alexie> thought it meant the rubbish bin
16:08 #nouveau: < mupuf> poubelle then ;)
16:09 #nouveau: < Alexie> that's it!
16:09 #nouveau: < Alexie> yeah, I needed to find somewhere to put my rubbish and couldn't find it!
16:09 #nouveau: < mupuf> :D Sounds like me when I was in England
16:10 #nouveau: < Alexie> c
16:10 #nouveau: < Alexie> darktama: OK I got the bligher
16:10 #nouveau: < Alexie> *blighter
16:11 #nouveau: < Alexie> seems on call to nouveau_bo_handle_get, a NULL is passed in via nouveau_pixmap(ppx)->bo
16:11 #nouveau: < Alexie> hence a nasty crash
16:11 #nouveau: < Alexie> I think it needs to be initialised to zero or something
16:12 #nouveau: < Alexie> nouveau_pixmap(ppix)->po = NuLL will not work as it is an inlined function which calls exGetPixmapPrivate(ppx)
16:12 #nouveau: < Alexie> *exaGetPixmapDriverPrivate(ppx)
16:13 #nouveau: < Alexie> if it's null... then it dies
16:18 #nouveau: < mupuf> Alexie: I guess the real question is why nouveau_pixmap(ppix)->po
16:18 #nouveau: < mupuf> why nouveau_pixmap(ppix)->po == NULL
16:19 #nouveau: < Alexie> I think CreatePixmap() in the vieux drivcer isn't settibng it up correctly
16:29 #nouveau: < Alexie> I may be looking in the wrong place
16:32 #nouveau: < Alexie> brb
16:32 #nouveau: < Alexie> seeing as nouveau_drv.so is the same and works just fine on my NV34 the problem has to b e elsewhere
16:32 #nouveau: < Alexie> I suspect it might be in the _vieux driver
16:35 #nouveau: < Alexie> baqck
16:40 #nouveau: < Alexie> What's the difference between gallium/nouveau_dri.so and nouveau_dri_vieux.so?
16:52 #nouveau: < Alexie> Now i'm sure it's not setting up a bo whenever it has to create a new pixmap in nouveau_dri2:nouveau_dri2_create_buffer()
16:52 #nouveau: < RAOF> Alexie: The set of hardware they drive. nouveau_vieux supports nvSOMETHING - nv2x, nouveau supports nv3x-current.
16:53 #nouveau: < Alexie> anyone else have problems with vieux?
16:53 #nouveau: < Alexie> mine crashes whenever I run opengl apps
17:04 #nouveau: < Alexie> when the xf86-video-nouveau calls pScreen->CreatePixmap() does this goes to the vieux driver?
17:06 #nouveau: < Alexie> or does it gets handled in nouveau_exa_create_pixmap?
17:08 #nouveau: < RAOF> pScreen->CreatePixmap doesn't interact directly with the GL driver, as I understand it. It'll go through exa_create_pixmap, and then (possibly) a reference to that buffer will be sent out as a response to a DRI2 request by the GL driver.
17:09 #nouveau: < Alexie> yeah that's what I think
17:09 #nouveau: < Alexie> it might not be returning a ->bo
17:11 #nouveau: < Alexie> yep it's not handing back a bo
17:11 #nouveau: < Alexie> ret = nouveau_allocate_surface(scrn, width, height, bitsPerPixel,
17:11 #nouveau: < Alexie> usage_hint, new_pitch, &nvpix->bo);
17:11 #nouveau: < Alexie> in src/nouveau_exa.c
17:12 #nouveau: < Alexie> guess I gotta dig into nouveau_allocate_surface
17:18 #nouveau: < Alexie> there's no error checking in nouvea_exa_create_pixmap
17:18 #nouveau: < Alexie> nouveau_allocate_surface returns FALSe but the code still uses it anyway
17:19 #nouveau: < Alexie> there's no error handling in nouveau_dr2_create_buffer()
17:19 #nouveau: < Alexie> so when it returns NULL, it just tries to use it.. *BOOM*
17:20 #nouveau: < darktama> Alexie: i pretty much said all of that above..
17:20 #nouveau: < darktama> and asked you to dig as to *why* bo_new_tile() was failing
17:21 #nouveau: < Alexie> it's failing with FASe
17:21 #nouveau: < Alexie> *FALSE
17:21 #nouveau: < Alexie> but we knew that
17:21 #nouveau: < darktama> no, nouveau_bo_new_tile() returns an int.. in "ret"
17:21 #nouveau: < Alexie> I will print out the parameters passed to it
17:21 #nouveau: < Alexie> if (ret)
17:21 #nouveau: < Alexie> {
17:21 #nouveau: < Alexie> xf86DrvMsg(scrn->scrnIndex, X_WARNING, /* AIB */
17:21 #nouveau: < Alexie> "nouveau_bo_new_tile() returned FALSE\n");
17:21 #nouveau: < Alexie> return FALSE;
17:21 #nouveau: < Alexie> }
17:21 #nouveau: < Alexie> return TRUE;
17:21 #nouveau: < Alexie> that's boolean
17:22 #nouveau: < darktama> yes, and that's also nouveau_allocate_surface(), *not* what nouveau_bo_new_tile() returns
17:22 #nouveau: < Alexie> I was tracing the values passed down through these functions from dri2_create_buffer
17:22 #nouveau: < Alexie> nouveau_bo_new_tile() appears ot be part of the drm stuff
17:23 #nouveau: < darktama> yes, it's what's responsible for allocating the memory for your pixmap
17:23 #nouveau: < darktama> and it's failing for some reason
17:23 #nouveau: < Alexie> I'll go dig into my drm stuff
17:32 #nouveau: < Alexie> ooh it makes a series of calls to _bo_new_tile()
17:32 #nouveau: < Alexie> the last call fails with a ret value of -12 but X11 is up and running
17:32 #nouveau: < Alexie> now to run glxinfo
17:32 #nouveau: < darktama> -12 is -ENOMEM
17:33 #nouveau: < Alexie> after that, all subsequent calls are -21
17:33 #nouveau: < Alexie> *-12
17:33 #nouveau: < Alexie> I think I know why
17:33 #nouveau: < Alexie> [ 35838.515] (WW) NOUVEAU(0): [nouveau_pixmap(ppix)->bo] addr = 0x8262ed8, handle = 7, size = 17203200, map = (nil), tile_mode = 000
17:33 #nouveau: < Alexie> 03800, tile_flags = 0000000A
17:33 #nouveau: < Alexie> it allocates 17MB of ram
17:33 #nouveau: < Alexie> this card has 32MB onboard
17:34 #nouveau: < Alexie> [ 35779.404] (II) NOUVEAU(0): GART: 64MiB available
17:34 #nouveau: < Alexie> [ 35779.408] (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer
17:35 #nouveau: < Alexie> http://ompldr.org/vN2x1dg
17:36 #nouveau: < Alexie> that's the calls that are made in there
17:36 #nouveau: < Alexie> any ideas?
17:40 #nouveau: < Alexie> i'll print out the memory sizes
17:41 #nouveau: < Alexie> ok i got the memory
17:42 #nouveau: < Alexie> it allocates 16384, 16384, 0, 24576, 24576, 24576, 17203200, 16777216 then 8601600 , this is where it fails. it;s run out of memory
17:42 #nouveau: < Alexie> this can't be right
17:43 #nouveau: < robink> Woah, nv50 is going to be replaced by ported nvc0 code?
17:44 #nouveau: < Alexie> http://ompldr.org/vN2x1eQ (with memory allocations)
17:44 #nouveau: < robink> (commit f80c03e1875fe96ff2f4c022e3cb76357828140d)
17:47 #nouveau: < Alexie> brb
18:04 #nouveau: < Alexie> okay
18:04 #nouveau: < Alexie> is there anything I can do to tell the driver not to allocate so much for the scratch buffer?
18:14 #nouveau: < Alexie> yeah, I can change it in the ddx
18:26 #nouveau: < Alexie> there's definitely a problem with memory allocation with my 32mb card. I';m not sure why it's run out of memory. it might be 32m butit's got a 64mb gart. what 's a gart anyway?
18:28 #nouveau: < Alexie> oh well, time for bed. I'll dig a bit more in the morning.
22:23 #nouveau: < lynxeye1> Alexie: what kernel are you using? This should be fixed with some 2.6.38-rc. See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=812f219a0f8a74a558c35be7942a07232ba348a5