12:52 karolherbst: uff. arm
12:52 karolherbst: envyas just segfaults
12:56 karolherbst: ohh wait
13:02 karolherbst: we had this segfault..
13:02 karolherbst: why didn't we fix it :D
13:51 karolherbst: this makes no sense
15:24 karolherbst: imirkin:
15:24 karolherbst: i...
15:24 karolherbst: sry
15:24 karolherbst: I looked into the issue from yesterday though
15:24 karolherbst: but yeah.. looks like some corruption
15:25 karolherbst: disabled all uses of those methods
16:27 karolherbst: uff.. the tegra driver on older mesas OOM kill the machine
17:46 karolherbst: imirkin: does this ring any bells? "glxgears: ../src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c:258: nvc0_validate_fb: Assertion `!fb->zsbuf' failed."
17:47 imirkin: which one's that? that if you have a linear RT, you don't have a tiled depth buffer?
17:47 imirkin: (don't have the code in front of me)
17:47 karolherbst: trying to figure out where this invalid method comes from.. but apparently it seemed to have worked with an older mesa
17:47 karolherbst: that's what I got with 18.2
17:48 karolherbst: mhh
17:48 karolherbst: that's when !nouveau_bo_memtype(bo)
17:48 karolherbst: at least on master
17:49 imirkin: yeah, memtype == 0 is "linear"
17:49 imirkin: so ... the hardware just can't do this
17:49 imirkin: it will throw an error when you try to draw in such a configuration
17:49 imirkin: the assert is there to warn us of this earlier
17:50 imirkin: that said ... there shouldn't be a way for this to happen ... when you're rendering to scanout, you shouldn't have depth bound
17:50 karolherbst: yeah.. I think I will have to bisect from master again anyway
17:50 imirkin: perhaps with gbm or something it's possible
17:50 karolherbst: for whatever reaon... mesa thought that loading my system tegra gallium driver is a smart idea
17:50 imirkin: this error isn't due to a change in nouveau, but rather in the winsys logic, i would think
17:51 karolherbst: yeah.. probably
17:51 karolherbst: I guess some tegra fixes later on
17:52 imirkin: now ... it may be worth checking ... perhaps on tegra, the hw DOES allow this
17:52 imirkin: since it's all in sysmem anyways
17:52 karolherbst: yeah, maybe
18:19 karolherbst: imirkin: okay.. cool. I get that assert on master as well
18:20 karolherbst: and kmscube doesn't trigger that one
18:23 karolherbst: now the big question: is that related to the mthd errors or not :/
18:24 imirkin: yeah, could very well be
18:24 imirkin: if the first error is like RT_SOMETHING
18:24 imirkin: it rejects your starting of the draw
18:24 imirkin: and subsequent commands fail because you're not inside of a draw
18:24 karolherbst: mhh
18:25 karolherbst: doesn't seem like it though
18:25 karolherbst: the first is always "[INVALID_OPERATION] ch 4 [04001bf000 glxgears[13535]] subc 0 class b197 mthd 19d0 data 0000003d"
18:25 karolherbst: but
18:25 imirkin: that's the vertex count
18:25 imirkin: er no
18:25 karolherbst: yeah.. but I have no idea where that is coming from.. ohh wait..
18:25 imirkin: that's CLEAR_BUFFERS
18:25 karolherbst: yeah
18:26 karolherbst: but when I was disabling submiting those.. it was still using the system driver...
18:26 imirkin: dunno how you can have an invalid CLEAR_BUFFERS tbh
18:26 karolherbst: let me check
18:26 karolherbst: maybe the data?
18:26 imirkin: that's a mask
18:26 imirkin: of what to clear
18:26 karolherbst: yeah
18:26 karolherbst: maybe it doesn't like some bit
18:29 karolherbst: any idea why vertex buffer count might upset the gpu as well?
18:29 imirkin: it's only valid inside a BEGIN/END thing
18:30 karolherbst: huh.. we only use it inside the mme code, right?
18:30 imirkin: sure
18:30 karolherbst: mhhh
18:30 imirkin: for implementing indirect draws and a few other things
18:30 karolherbst: now I just disabled that and it still complains
18:31 karolherbst: ohh...
18:31 karolherbst: ehh
18:31 karolherbst: I am stupid
18:32 karolherbst: we push it alongside VERTEX_BUFFER_FIRST
18:34 karolherbst: but we have no idea what it complains about here,r ight? " gr: DATA_ERROR 0000009c [] ch 4 [04001bf000 glxgears[13672]] subc 0 class b197 mthd 0d78 data 00000052" :/
18:36 karolherbst: oh well.. looking into the clear_buffers fail should be easier
18:42 karolherbst: imirkin: it's one of the bits..
18:45 karolherbst: ufff
18:45 karolherbst: I have an idea
18:48 imirkin: the depth bit?
18:48 karolherbst: currently figuring out which one exactly
18:57 karolherbst: mhh
18:57 karolherbst: it's not just one bit
18:59 karolherbst: ehh.. seems like only bit 0x1 doesn't make the hardware unhappy
18:59 karolherbst: jep
19:00 karolherbst: so bits 0x3c are bad
19:01 karolherbst: something is weird
19:19 karolherbst: imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/tegra/tegra_context.c#n497
19:19 karolherbst: replaced that with a state.zsbuf = NULL
19:19 karolherbst: and now glxgears renders
19:19 karolherbst: and the errors are gone :(
19:21 imirkin: right
19:21 imirkin: let's see how the tegra surface wrap/unwrap works
19:21 imirkin: i suspect it's buggy
19:22 imirkin: hm, no
19:22 imirkin: fb->zsbuf is really getting set
19:22 imirkin: i think it's all this importing business
19:22 imirkin: to properly support it, we'd have to create shadow copies or something
19:24 imirkin: winsys stuff isn't my forte... i bet the egl thing picks a config with a depth buffer
19:24 imirkin: and then imports a linear texture
19:24 karolherbst: mhh
19:24 karolherbst: but it's GLX
19:24 imirkin: wtvr, same diff
19:24 karolherbst: ohh, okay
19:24 karolherbst: makes sense though
19:25 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/tegra/tegra_screen.c#n203
19:25 imirkin: and also the ->resource_create_front thing
19:31 karolherbst: mhh, yeah, no idea what to do here actually :/ well, that shadow copy stuff sounds like messy business actually
19:31 imirkin: very!
19:31 karolherbst: but I think we need this for some annoying piglit fails as well, no?
19:31 karolherbst: I kind of remember that we talked about shadow copies in the past
19:31 karolherbst: no idea why though
19:31 imirkin: for nv30
19:31 karolherbst: ohh, something blitter related?
19:32 imirkin: no, nv30 is just very picky
19:32 karolherbst: ahh, okay
19:32 imirkin: about formats of different color buffers
19:32 imirkin: or the format between color and depth
19:39 karolherbst: how messy is it to disable certain visuals? maybe as a workaround we could disable all with a depth buffer for now and mvoe on?
19:40 karolherbst: huh...
19:40 imirkin: not sure that's legal
19:40 karolherbst: the rendering is wrong
19:40 karolherbst: I just noticed it now
19:40 imirkin: turns out it wants the depth buffer - who knew :p
19:40 karolherbst: yeah...
19:40 karolherbst: looks like something depth related
19:41 karolherbst: the inner of the gears is on top of the rest of the gears
19:42 karolherbst: on top in a depth kind of sense
19:42 karolherbst: _but_ I guess thats because I just disable the zsbuf thingy
19:43 karolherbst: how do we handle that with noueau then?
19:43 imirkin: this doesn't come up
19:43 imirkin: everything's tiled
19:43 imirkin: and all is well
19:45 karolherbst: ups.. I crashed the GPU :D
19:45 karolherbst: played to much with the pstate file
19:46 karolherbst: I think the voltage control is broken anyway
19:46 karolherbst: as my SKU isn't supported by upstream tegra