On Fri, 3 May 2019 07:29:22 -0700 Alyssa Rosenzweig <aly...@rosenzweig.io> wrote:
> > + else if (!(job->clear & PIPE_CLEAR_COLOR)) > > Make sure this is actually being called when you expect. I don't > remember if job->clear is being zeroed when we expect (hint: it might > not be due to a missing job_free routine somewhere, *blush*). > > > + .rt[0].rgb_func = PIPE_BLEND_ADD, > > + .rt[0].rgb_src_factor = PIPE_BLENDFACTOR_ONE, > > + .rt[0].rgb_dst_factor = PIPE_BLENDFACTOR_ZERO, > > + .rt[0].alpha_func = PIPE_BLEND_ADD, > > + .rt[0].alpha_src_factor = PIPE_BLENDFACTOR_ZERO, > > + .rt[0].alpha_dst_factor = PIPE_BLENDFACTOR_ONE, > > Why is alpha flipped? Actually, I tried several things, so I might have left it flipped at some point, but it doesn't work with with src_factor=one and dts_factor=zero. > Is the black you're seeing really (0, 0, 0, a) or > might it be (0, 0, 0, 0)? Good question. I haven't dumped the buffers yet. Another thing to note: the texture I'm reloading from is using PIPE_FORMAT_B8G8R8X8_UNORM as a format, so no alpha component in there. I don't know exactly what happens in this case (do we have garbage in the alpha component?) :-/. > > > /* Bind texture/sampler. TODO: push/pop */ > > (Was this TODO addressed? It might explain the missing panel) We definitely bind the new sampler/texture, but I'm not sure we restore the old one. This being said, the version I have made using util_blitter_blit() was taking care of saving/restoring those, and I still had the issue :-/. > > > + 0.0, ctx->pipe_framebuffer.height, 0.0, 1.0, > > + 0.0, 0.0, 0.0, 1.0, > > + ctx->pipe_framebuffer.width, ctx->pipe_framebuffer.height, > > 0.0, 1.0, > > + ctx->pipe_framebuffer.width, 0.0, 0.0, 1.0, > > Just FWIW, this routine is running a fragment shader _without a vertex > shader_. In effect, we're running the vertex shader in software and > writing varyings straight to memory, as if the VS ran. So these values > are essentially the transformed output of a vertex shader. You mean we should apply the viewport transform on top, right? But again, the blitter-based implementation had a full VS -> FS pipeline with viewport transform applied and it didn't work either. > > > + .format = MALI_RGBA32F, > > + .swizzle = panfrost_get_default_swizzle(4), > > + .unknown1 = 0x2, > > +1 > > > + /* Looks like setting first_tiler_job->dependency_index_2 to point > > to > > + * out 'reload fb content' job is not enough, the link order > > matters too. > > + * Let's insert our job in the first slot so that > > panfrost_link_jobs() > > + * place it before any other tiler jobs. > > Oh, that's very interesting, I never realized that was the issue (I had > draw order issues). It's worth more investigation in the future, but +1 > and here's a cookie :P Hehe, glad to hear that at least part of this investigation lead to something useful :-). > > -------------------------------------- > > Hoping one of these is related, but the diff looks fairly solid.... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
