On Friday, April 6, 2018 7:31:41 AM PDT Lionel Landwerlin wrote: > v2: condition the extension on context isolation support from the > kernel (Chris) > > v3: (Lionel) > > The initial version of this change used a feature of the Gen7+ > command parser to turn the primitive instructions into no-ops. > Unfortunately this doesn't play well with how we're using the > hardware outside of the user submitted commands. For example > resolves are implicit operations which should not be turned into > no-ops as part of the previously submitted commands (before > blackhole_render is enabled) might not be disabled. For example > this sequence : > > glClear(); > glEnable(GL_BLACKHOLE_RENDER_INTEL); > glDrawArrays(...); > glReadPixels(...); > glDisable(GL_BLACKHOLE_RENDER_INTEL); > > While clear has been emitted outside the blackhole render, it > should still be resolved properly in the read pixels. Hence we > need to be more selective and only disable user submitted > commands. > > This v3 manually turns primitives into MI_NOOP if blackhole render > is enabled. This lets us enable this feature on any platform. > > Signed-off-by: Lionel Landwerlin <lionel.g.landwer...@intel.com> > --- > src/mesa/drivers/dri/i965/brw_compute.c | 46 +++++++++++--------- > src/mesa/drivers/dri/i965/brw_defines.h | 8 +++- > src/mesa/drivers/dri/i965/brw_draw.c | 20 ++++++--- > src/mesa/drivers/dri/i965/intel_extensions.c | 1 + > 4 files changed, 49 insertions(+), 26 deletions(-)
Another potential issue with this patch...it doesn't stub out BLORP operations. Maybe that's intentional? Should BlitFramebuffer, CopyTexSubImage, CopyImageSubData, and so on do anything? I had originally thought you might need handling for Clear here, but you do that explicitly in patch 2. Wasn't sure about the others...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
