On Thu, Jun 16, 2016 at 2:20 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Thu, Jun 16, 2016 at 2:57 PM, Rob Herring <r...@kernel.org> wrote: >> On Thu, Jun 16, 2016 at 12:09 PM, Rob Clark <robdcl...@gmail.com> wrote: >>> On Thu, Jun 16, 2016 at 12:56 PM, Rob Herring <r...@kernel.org> wrote: >>>> On Thu, Jun 16, 2016 at 11:44 AM, Rob Clark <robdcl...@gmail.com> wrote: >>>>> On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring <r...@kernel.org> wrote: >>>>>> In the process of adding RGBX (XB24) format to mesa for Android, I >>>>>> started seeing a new problem that makes the UI stop updating. It >>>>>> happens about when the splash screen is stopped and the lock screen is >>>>>> displayed. The display flickers on mouse movement, and it looks like >>>>>> the screen is flipping to old buffers (like the splash screen after >>>>>> its process exited). It is working fine for freedreno AFAICT, but I am >>>>>> running into a problem with virgl. With virgl, I get the following >>>>>> error: >>>>>> >>>>>> vrend_create_surface: context error reported 1 "surfaceflinger" >>>>>> Illegal resource 1435 >>>>>> vrend_report_buffer_error: context error reported 1 "surfaceflinger" >>>>>> Illegal command buffer 329729 >>>>>> >>>>>> The addition of the pixel format changes the eglconfig used for the >>>>>> splash screen. If I force the splash screen eglconfig to have an alpha >>>>>> or draw one frame of the splash screen and exit early or disable the >>>>>> splash screen, everything seems fine though I have hit the problem >>>>>> rarely navigating around. I suspect this has nothing to do with the >>>>>> pixel format other than different buffer sizes cause buffers to get >>>>>> reused differently. >>>>>> >>>>>> Now I've started working on getting RPi3 and vc4 working, and it >>>>>> appears to have a similar problem. I'm getting these errors though >>>>>> things go haywire before getting any error message: >>>>>> >>>>>> [ 43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM >>>>>> BO 0: 4 >>>>> >>>>> at least in the vc4 case, I suspect you need a similar bit of winsys >>>>> magic to ensure the same pipe_screen is returned for any given drm >>>>> device fd. (Or did someone already add that?) >>>> >>>> That problem should be gone with GBM gralloc, right? >>> >>> *maaaybe*.. >>> >>> It, like the gralloc-drm-pipe approach, means we have a pipe_screen >>> (vs. the other drm-gralloc backends which were using libdrm_xyz >>> directly), so it was going through the logic to avoid duplicate >>> pipe_screen's (for the drivers which had that). >>> >>> Maybe w/ gbm, everything ends up sharing the same pipe_screen? I'm >>> not really sure, since I guess both GL and gralloc are creating a gbm >>> device? >>> >>> I guess easy enough to put some debug print in vc4_screen_create() to >>> confirm. But the sort of errors you are seeing make me suspicious. >> >> Uhh, well looks like that is a problem for vc4: >> >> 01-01 00:00:07.295 127 127 W VC4 : vc4_screen_create >> 01-01 00:00:07.334 127 127 W VC4 : vc4_screen_create >> 01-01 00:00:08.349 205 223 W VC4 : vc4_screen_create >> 01-01 00:00:08.352 205 223 W VC4 : vc4_screen_create >> 01-01 00:00:35.467 437 488 W VC4 : vc4_screen_create >> 01-01 00:00:35.477 437 488 W VC4 : vc4_screen_create >> 01-01 00:00:39.041 511 511 W VC4 : vc4_screen_create >> 01-01 00:00:43.385 511 798 W VC4 : vc4_screen_create >> 01-01 00:00:44.135 718 718 W VC4 : vc4_screen_create >> 01-01 00:00:44.202 718 923 W VC4 : vc4_screen_create >> >>> Possibly the "libdrm equivalent" part of vc4 needs to do more to avoid >>> re-importing the same handle multiple times? >> >> Maybe time for the common implementation. > > yeah, probably > >> This doesn't explain the virgl case though as I already fixed this >> problem. The log below is from virgl. > > I haven't looked closely at virgl yet, but if it has some sort of bo > cache, perhaps it is allowing shared buffers into the cache?? Not > sure, but I'd be on the lookout for things like that..
I had disabled the cache for virgl without any improvement. > Presumably it already has a hashtable to deal w/ multiple-imports of > the same flink name? virgl does, though I added the dmabuf support, so maybe it needs better review. :) It looks like this is the 2nd problem with vc4. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev