[Mesa-dev] Etnaviv on mesa master vs. Array._DrawVAO

[Guido Günther]

Hi,
On Sat, Sep 01, 2018 at 09:07:46AM +0200, Mathias Fröhlich wrote:
> Hi,
> 
> On Friday, 31 August 2018 12:40:01 CEST Guido Günther wrote:
> > Hi,
> > I'm looking into forward porting laanwj's patches for GC7000 support to
> > current mesa master. Luckily most of it already got merged last November
> > with mostly only the texture descriptor support missing(
> > https://github.com/laanwj/mesa/commit/b71802207432543745dff471c68fbc40495b48
> > 58)
> > 
> > Putting this on current master leads to this assertion in mesa when running
> > kmscube like:
> > 
> >     kmscube: ../src/gallium/drivers/etnaviv/etnaviv_state.c:536:
> > etna_vertex_elements_state_create: Assertion `element_size != 0 &&
> > end_offset <= 256' failed.
> > 
> > Printing the value there gives:
> > 
> >     etna_vertex_elements_state_create:535: size: 12, offset: 0, end_offset:
> > 12 etna_vertex_elements_state_create:535: size: 12, offset: 576,
> > end_offset: 588
> > 
> > And the bt is:
> > 
> >        Stack trace of thread 2158:
> >        #0  0x0000ffffa93427c0 raise (libc.so.6)
> >        #1  0x0000ffffa934274c raise (libc.so.6)
> >        #2  0x0000ffffa9343bac abort (libc.so.6)
> >        #3  0x0000ffffa933bd2c n/a (libc.so.6)
> >        #4  0x0000ffffa933bdac __assert_fail (libc.so.6)
> >        #5  0x0000ffffa8de468c etna_vertex_elements_state_create
> > (imx-drm_dri.so) #6  0x0000ffffa8757178 u_vbuf_set_vertex_elements_internal
> > (imx-drm_dri.so) #7  0x0000ffffa875726c u_vbuf_set_vertex_elements
> > (imx-drm_dri.so) #8  0x0000ffffa8711bcc cso_set_vertex_elements
> > (imx-drm_dri.so) #9  0x0000ffffa8b28760 set_vertex_attribs (imx-drm_dri.so)
> >        #10 0x0000ffffa8b28c9c st_update_array (imx-drm_dri.so)
> >        #11 0x0000ffffa8ad4e44 st_validate_state (imx-drm_dri.so)
> >        #12 0x0000ffffa8a1e410 prepare_draw (imx-drm_dri.so)
> >        #13 0x0000ffffa8a1e488 st_draw_vbo (imx-drm_dri.so)
> >        #14 0x0000ffffa8a0ea9c vbo_draw_arrays (imx-drm_dri.so)
> >        #15 0x0000ffffa8a0f408 vbo_exec_DrawArrays (imx-drm_dri.so)
> >        #16 0x0000ffffa953f7e0 glDrawArrays (libGLESv2.so.2)
> >        #17 0x0000aaaad7e62ea0 draw_cube_smooth (kmscube)
> >        #18 0x0000aaaad7e64160 atomic_run (kmscube)
> >        #19 0x0000ffffa93306e0 __libc_start_main (libc.so.6)
> >        #20 0x0000aaaad7e621fc $x (kmscube)
> >        #21 0x0000aaaad7e621fc $x (kmscube)
> > 
> > I've traced this back to this commit:
> > 
> >     19a91841c347107d877bc750371c5fa4e9b4de19 is the first bad commit
> >     commit 19a91841c347107d877bc750371c5fa4e9b4de19
> >     Author: Mathias Fröhlich <mathias.froehlich at web.de>
> >     Date:   Sun Apr 1 20:18:36 2018 +0200
> > 
> >         st/mesa: Use Array._DrawVAO in st_atom_array.c.
> > 
> >         Finally make use of the binding information in the VAO when
> >         setting up arrays for draw.
> > 
> >         v2: Emit less relocations also for interleaved userspace arrays.
> > 
> >         Reviewed-by: Brian Paul <brianp at vmware.com>
> >         Signed-off-by: Mathias Fröhlich <Mathias.Froehlich at web.de>
> > 
> > And indeed commits prior to that one work as expected. Any hints what
> > would be the right fix to not trigger the assert?
> 
> 
> Introduce a gallium cap and feed ctx->Const.MaxVertexAttribRelativeOffset with 
> the value that limits the actual hardware.
> 
> I have something prepared for that but did not get any response for a some 
> preparation patch so put that issue somehow down on my list.
> The point for today is, is that my development system is down, means I can 
> prepare this once this machine is back up hopefully by the beginning of this 
> week.
> Else feel free to just introduce that cap.

I will be away from the hw for the next week but I'm happy to cook up a
patch and test it afterwards.
Cheers,
 -- Guido