freedreno and vc4 have support to re-order draw calls to reduce tile passes and improve memory efficiency[1][2]. We should probably have a piglit test(s) for this. Probably for simple case of rendering to FBO and then sampling from, we can do something that iterates between rendering to FBO and then sampling from, so that each step overwrites one component (ie. x, y, z, or w) and taking the rest of the components from the previous FBO sampled as a texture? For gl(es)3+ type features, we probably need to add things like using a prior TF output bo as a UBO, and other things I'm not thinking of right now. [1] http://bloggingthemonkey.blogspot.com/2016/07/dirty-tricks-for-moar-fps.html [2] http://anholt.livejournal.com/47610.html
Created attachment 136463 [details] [review] new gles3 Test transform-feedback to uniform-buffer-object Would this test work for the tf-ubo-tiling-interaction? Additionally, I have a question wrt the FBO test: Would this work: loop over i: »···loop over tiles: »···»···draw solid color[i] to fbo »···draw to piglit_winsys_fbo sampling from fbo »···check result I do not understand the necessity of your scheme writing single components. Do you intend to just check the result once at the end of the test? Or are you intending to render to and sample from the same texture in one pass (using GL_ARB_texture_barrier)?
hmm, I meant to write some test but never got around to it. I was in particular thinking of something really simple that toggled between two fbo's rendering to current fbo and sampling from previous fbo. The driver should detect the read after write dependency and split up the batches so that order is preserved (vs reordering things so draw #1, #3, #5 that write the FBO all happen before #2, #4, #6 that read the FBO). That said, I guess there are plenty of other ways that issues could crop up (TF/ssbo/images are probably good candidates).. TF is possibly an interesting case, since if binning pass is enabled (which is default), then for each tile the driver renders, it will only run the VS for the subset of vertices which touch the current tile. I'm a bit curious what will happen in this sort of case. I guess it could be a similar issue for ssbo/image written by VS (although for other reasons I have only exposed ssbo/image in FS and CS). In freedreno, I just track which resources are read and/or written by a given draw (without really caring that it is VBO/TFBO/SSBO/texture/etc), which has worked pretty well. The occasional small bug that I introduced, for example when adding ssbo/image support, simply amounting to forgeting to add appropriate resource_read()/resource_written() call. (That said, because of binning pass, I probably need to revisit TF case.. things written by draw #1 in VS and read in draw #2, probably shouldn't cause the batch to be split, but might need special handling to disable using visibility stream from binning pass to skip VS invocations)
Created attachment 136668 [details] [review] gles2: Add fbo ping-pong test. There are fbo-flushing and fbo-flushing2 in Piglit which draw to an FBO and then sample from the fbo to piglit_winsys_fbo. But they only use a single draw call for the entire FBO and don't do back and forth rendering between two FBOs. Based on your description I came up with the attached test. Maybe I'll write an ssbo and an image store test, too. No promises, though.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/piglit/issues/5.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.