02:50 vedranm: pmoreau: blogging with Phabricator is a nice idea
03:42 pmoreau: vedranm: Thanks! I'm pretty new to blogging, but I'll try to have a post every now and then (maybe each month?).
03:42 pmoreau: I'll maybe write one this weekend/next week to do a small recap of what I said at FOSDEM.
04:24 Jayhost: Anyone watching Julien?
05:20 vedranm: pmoreau: that would be interesting, hope you write it
06:11 karolherbst: current zcull status: I got antichamber running without trapping all the time, only disabling vsync makes the gpu trap a lot :/
06:12 karolherbst: ohh wait, it is back agin :/
06:15 karolherbst: mhhh
06:15 karolherbst: "GK104_3D.SCREEN_Y_CONTROL = { TRIANGLE_RAST_FLIP }" this looks important
06:18 karolherbst: yeah
06:18 karolherbst: :D
06:18 karolherbst: finally!
06:18 karolherbst: a visual difference
06:18 karolherbst: and yes, SCREEN_Y_CONTROL is important
06:19 karolherbst: imirkin: do you know how I get the information for this?
06:20 karolherbst: there is also Y_NEGATE
06:47 karolherbst: imirkin: okay, when the ZETA stuff changes (for example 1920x1080 => 960x540, zcull also needs to fit those bounds)
07:03 karolherbst: mhh odd
07:03 karolherbst: that's what you did, but I think the zcull thing is destroyed to often
07:09 imirkin: yeah you're probably right
07:09 imirkin: it was just a theory
07:11 karolherbst: well at least the mmt tells me that there is always a zcull operations before the zeta thing
07:11 karolherbst: and after the zeta bounds change, there is a full zcull rebind (new adress and everything)
07:12 karolherbst: mhh, still get the traps
07:12 karolherbst: something bothers the gpu
07:14 karolherbst: but it is related to changing something, I guess
07:15 karolherbst: like I don't get any traps when I start glxgears
07:15 karolherbst: and there zcull is only set once
07:15 karolherbst: but when I resize the window, there is new stuff and I get the traps
07:18 karolherbst: yay
07:18 karolherbst: imirkin: the changed address bothers it
07:19 karolherbst: mhhh and there seems some kind of overflow
07:19 karolherbst: if I leave the same address
07:20 karolherbst: after seom frames (around 1000) I get a read fault
07:21 karolherbst: ohh right
07:32 karolherbst: okay
07:33 karolherbst: the buffers are just replaced
07:33 karolherbst: 960x540 has it's buffer at 0x101ee0000 and 1920x1080 at 0x101ea0000
07:33 karolherbst: and the driver just reuses the addresses
07:34 karolherbst: will check if the driver frees those buffers at any time
07:34 karolherbst: nope
07:34 karolherbst: the buffer isn't freed
07:35 karolherbst: any idea what "GK104_3D.RT" is?
07:36 karolherbst: it is kind of in between ZCULL and ZETA
07:42 karolherbst: imirkin: so, question to understand that stuff: there are multiple framebuffers in an OpenGL Context and it might happen that one is 1920x1080 and one is 960x540 big and sometimes nvc0->framebuffer.zsbuf points to zsbuf of one framebuffer and sometimes to the other one?
07:44 karolherbst: and my idea would be to create a new zcull buffer for each framebuffer and just do the same thing like with the zsbuf basically
08:11 imirkin: karolherbst: a framebuffer is a set of attachments. there might be up to 8 color attachments, there might be a depth/stencil attachment.
08:11 imirkin: karolherbst: each attachment has a size, but the size of the framebuffer is the min of all the attachments in each dimension
08:22 karolherbst: imirkin: mhh okay, and the depth/stencil attachment size will be put into the ZETA thing then or is there something more to it?
08:23 imirkin: nope, that's it
08:23 imirkin: zeta = depth + stencil
08:23 imirkin: in a hypothetical GL implementation you could have separate depth and stencil buffers
08:23 karolherbst: I think that the addresses of the zcull buffers have to be managed on a per framebuffer basis
08:23 imirkin: but in practice that's not supported, at least not with st/mesa.
08:23 imirkin: yeah, that's why i clear out zcull surface when a new framebuffer is set :)
08:24 karolherbst: because it seems like that zcull has always the same width/height set as ZETA + nvidia uses the same address for each dimension (I think the game has only two in total, but I might be wrong)
08:24 karolherbst: imirkin: thing is, the changed address somehow annoyed ZCULL
08:24 karolherbst: when I always use the same buffer, I don't get any traps
08:25 imirkin: sounds like you have some figuring out to do ahead of you
08:25 imirkin: don't take the code i supplied as the "truth" :) use it if it makes sense, throw it away if not
08:25 karolherbst: ahhh
08:25 imirkin: i won't be offended :)
08:25 karolherbst: ZCULL_INVALIDATE is set when the address isn't used later anymore
08:26 karolherbst: makes somehow sense
08:26 imirkin: i don't know of course
08:26 imirkin: but i *assume*
08:26 karolherbst: yeah I know
08:26 imirkin: that invalidate resets the zcull surface
08:26 imirkin: to a state where it says "i have no information"
08:26 karolherbst: I think before unmap a zcull buffer, it has to be invalidated before
08:26 karolherbst: then it can be unmapped
08:27 imirkin: well, you def have to invalidate when you set a fresh zcull buffer
08:27 imirkin: you could also be hitting some sort of flush-related issue
08:27 karolherbst: yeah, but I have to call that invalidate on the old address
08:27 imirkin: where you delete the zcull buffer before the renderer is done using it
08:27 imirkin: in that case create a fence work thingie
08:27 imirkin: instead of unreffing the bo
08:27 karolherbst: could be yes
08:28 imirkin: the whole asynchronicity of the CPU <-> GPU interactions is a bit of a mindfuck unfortunately
08:28 karolherbst: yeah, I noticed
08:28 imirkin: i think i have a handle on it now, but ... every so often even i get tripped up
08:33 karolherbst: what bothers me a bit still is, that the blob usually uploads all the ZCULL data, but then it simply does ZCULL_REGION + that align((width * height * 0x10) / (0x50 * 0x20), 0x100) thingy, except for the 0x3f region
08:34 karolherbst: I don't know if that means, no data, or use the old data or something else
08:36 mwk: karolherbst: 0x3f region is "invalid" AFAIR
08:36 mwk: as in, zcull doesn't happen
08:36 karolherbst: yeah makes sense
08:37 karolherbst: but I also don't see nvidia pushing the same data twice in a row
08:37 karolherbst: so maybe region=0 + that other thing just means to reuse the old stuff
08:40 karolherbst: and yeah, there is definatly a ZETA address to ZCULL address mapping somewhere, same buffers are always used together
08:41 karolherbst: imirkin: is there a place where I could add a ZCULL buffer to the ZETA stuff?
08:41 imirkin: ?
08:42 karolherbst: I mean there has to be some sort of struct holding the zeta state in mesa-nvc0?
08:42 karolherbst: or not?
08:42 imirkin: pipe_framebuffer_state unfortuantely
08:42 imirkin: you could create a nvc0_framebuffer_stateobj
08:42 karolherbst: okay and base of that would be pipe_framebuffer_state
08:42 imirkin: that's why i stuck it into the context directly ;)
08:42 karolherbst: :D
08:42 karolherbst: k
08:43 imirkin: my way's a bit less efficient, but should work
08:43 karolherbst: yeah I think this way we can track that framebuffer and when it gets destroyed I can simply invalidate that zcull buffer
08:44 imirkin: i do it in ->set_framebuffer_state
08:44 imirkin: whenever a new one gets assigned, i kill the old one
08:44 karolherbst: yeah I saw it. but sadly there is more to it than this
08:46 imirkin: i'm sure.
08:48 karolherbst: thing is, when I always invalidate the buffer ZCULL is also unhappy after getting new data :/
08:54 karolherbst: where should I put this nvc0_framebuffer_stateobj thing then?
09:53 karolherbst: mhh got a new error: "gr: DATA_ERROR 00000004 [INVALID_VALUE] ch 2 [00bf890000 glxgears[7668]] subc 0 class a097 mthd 07c0 data 0000012c"
09:53 imirkin_: ZCULL_WIDTH
09:54 imirkin_: don't you align it?
09:54 karolherbst: and 07c4 is ZCULL_HEIGHT?
09:54 imirkin_: how did you end up with 0x12c
09:54 imirkin_: yep
09:54 karolherbst: ohh I am just playing around
09:54 imirkin_: src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h:#define NVC0_3D_ZCULL_HEIGHT 0x000007c4
09:54 karolherbst: ohhh
09:54 karolherbst: k
09:54 imirkin_: :)
09:55 imirkin_: all slowly coming together?
09:55 karolherbst: at least it means that 0x50/0x20 isn't that wrong because that worked before without that error
09:55 imirkin_: sure, but... confirmation bias :)
09:55 imirkin_: maybe 0x10 would have worked too
09:56 imirkin_: or 0x8
09:56 karolherbst: maybe
09:56 imirkin_: gnurou: what would you say the chances are that nvidia would be willing to release the docs for how to make zcull go?
09:57 imirkin_: ... on a scale of 0 to 0 :)
09:57 karolherbst: :D
09:57 karolherbst: k,
09:57 karolherbst: how can I increase the ZETA buffer?
09:57 imirkin_: increase?
09:57 karolherbst: yeah in size
09:58 imirkin_: nvc0_miptree_create is the function called to make it
09:58 karolherbst: like I want the normal amount + a little bit more data
09:58 imirkin_: if util_format_is_depth_or_stencil(): allocate_some_more :)
09:58 karolherbst: mhh weird, something else is odd
10:00 karolherbst: my current stuff by the way: https://github.com/karolherbst/mesa/commit/3dfeb7ae1654062b06f2523875a6d9c780c14c90
10:02 karolherbst: imirkin_: maybe there is somehting important going on with that macro?
10:02 karolherbst: because there isn't always that invalidate thing
10:02 karolherbst: also I don't understand what the value here means: PB: 0x80000656 GK104_3D.ZCULL_INVALIDATE = 0
10:03 karolherbst: is this somekind of reference from the macro?
10:03 imirkin_: no
10:03 imirkin_: it's just a pushbuf entry
10:03 imirkin_: of the IMMED_NVC0() style
10:03 karolherbst: yeah but I thought the number left means it is the data which is pushed
10:03 imirkin_: which can encode an immediate up to 0x1fff iirc
10:03 karolherbst: ohh
10:03 imirkin_: no. it's just what's in the pushbuf.
10:04 karolherbst: soo PB: 0x8000 means it is a IMMED_NVC0 with a value up to 0x1fff?
10:04 imirkin_: not enough data.
10:05 imirkin_: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_winsys.h#n73
10:05 imirkin_: enjoy.
10:05 imirkin_: also: http://envytools.readthedocs.org/en/latest/hw/fifo/dma-pusher.html#gf100-commands
10:06 karolherbst: it is just like this: https://gist.github.com/karolherbst/3ae1096b1fafd151b7af
10:07 imirkin_: BEGIN_NVC0(macro 0x3c);
10:07 imirkin_: PUSH_DATA(0)
10:07 imirkin_: IMMED_NVC0(ZCULL_INVALIDATE, 0)
10:07 imirkin_: er, that first oen should have been BEGIN_NVC0(macro 0x3c, 1)
10:10 karolherbst: okay
10:10 karolherbst: now I will write garbage to each field and see what errors I get :)
10:12 karolherbst: nice, so I will get all the right alignments :)
10:17 karolherbst: imirkin_: we could ask what that trap means though, but I somehow get the feeling it means "something is wrong, fix it"
11:10 karolherbst: imirkin_: could something on the kernel be missing? Or something else the driver has to push somewhere nobody figured out is zcull related?
11:13 imirkin_: karolherbst: i think you're looking at this like you need to write some fixed set of commands and then all will be well
11:13 imirkin_: that's not how these things work :)
11:15 karolherbst: right
11:49 imirkin_: skeggsb: any change you could teach demmt about nvif?
11:49 imirkin_: chance*
18:34 gnurou: imirkin_: let me check this, are you talking about kernel or user-space support? or probably both I guess?
23:24 ashmew2: Hello. I'm trying to software mux my intel and nvidia card with PRIME. but DRI_PRIME=1 , glxinfo reports openGL version 2.0 with Gallium 0.4 but glxinfo says openGL is 3.0 with DRI_PRIME=0. I need to use the nvidia card with opengl version > 3.0, is it possible?