Enabling GL 4.0 in gen7 requires a bit of work because some hardware and kernel combinations may not support all the features. Specifically, we need to know if the kernel can do pipelined register writes. Unfortunately, this requires that we emit batches at screen creation time when we don't have a brw_context available (all our current batch emission infrastructure relies on this). See [1] and [2] for more details.
This little series implements the minimum infrastructure necessary so we can emit a batch to check for register writes at screen creation time. The first 4 patches refactor some of the interl_batchbuffer code so they don't require a brw_context parameter. This way we can reuse the code directly at screen creation time. There are still a few functions that we need but rely quite heavily on the brw_context object, specifically, brw_emit_mi_flush() and intel_batchbuffer_flush(). These need to access the brw_context mostly to deal with things such as ring changes, flushing the batch when we exceed the allocated buffer size, throttling, etc which we don't need in our particular case, so we decided to have alternate implementation of these that are greatly simplified for the case of checking register writes. Overall, the implementation of these functions in brw_check_register_writes.c is ~50 SLOC, so it is really not a lot of code and it skips a lot of the complexity that the more generic batch buffer functions have to deal with all kinds of scenarios, so it seems like an acceptable trade-off. Patch 5 implements all this and also implements the check for the capacity to do pipelined register writes using this new infrastructure. Basically, we create our own batch buffer and the necessary objects to use it (buffer manager, hardware context, etc), we then emit the register writes, check the result and dispose of the all the objects after we're done. Patch 6 simply calls this functionality when needed to see if we can expose GL 4.0 on Haswell systems. There are a number of other intel_batchbuffer functions that we don't need for this particular case but that we could also modify to accept a batchbuffer object instead of a brw_context. I would be happy to write follow-up patches to do that if we are interested. [1] https://lists.freedesktop.org/archives/mesa-dev/2016-October/133439.html [2] https://lists.freedesktop.org/archives/mesa-dev/2016-October/133502.html Iago Toral Quiroga (6): i965: Make intel_bachbuffer_reloc() take a batchbuffer argument i965: make intel_batchbuffer_emit_dword() take a batchbuffer as argument i965: make intel_batchbuffer_free() take a batchbuffer as argument i965: remove brw_context dependency from intel_batchbuffer_init() i965: check if we support pipelined register writes at screen creation time i965/gen7: Enable OpenGL 4.0 in Haswell when supported src/mesa/drivers/dri/i965/Makefile.sources | 1 + .../drivers/dri/i965/brw_check_register_writes.c | 212 +++++++++++++++++++++ src/mesa/drivers/dri/i965/brw_context.c | 4 +- src/mesa/drivers/dri/i965/brw_context.h | 3 + src/mesa/drivers/dri/i965/genX_blorp_exec.c | 4 +- src/mesa/drivers/dri/i965/intel_batchbuffer.c | 81 ++++---- src/mesa/drivers/dri/i965/intel_batchbuffer.h | 41 ++-- src/mesa/drivers/dri/i965/intel_extensions.c | 78 +------- src/mesa/drivers/dri/i965/intel_screen.c | 11 +- 9 files changed, 298 insertions(+), 137 deletions(-) create mode 100644 src/mesa/drivers/dri/i965/brw_check_register_writes.c -- 2.7.4 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
