+ if (INTEL_DEBUG & DEBUG_BUFMGR)
+ dri_bufmgr_set_debug(screen->bufmgr, true);
+
+ if ((INTEL_DEBUG & DEBUG_SHADER_TIME) && devinfo->gen < 7) {
+ fprintf(stderr,
+ "shader_time debugging requires gen7 (Ivybridge) or better.\n");
+ INTEL_DEBUG &= ~DEBUG_SHADER_TIME;
+ }
+
+ if (intel_get_integer(screen, I915_PARAM_MMAP_GTT_VERSION) >= 1) {
+ /* Theorectically unlimited! At least for individual objects...
+ *
+ * Currently the entire (global) address space for all GTT maps is
+ * limited to 64bits. That is all objects on the system that are
+ * setup for GTT mmapping must fit within 64bits. An attempt to use
+ * one that exceeds the limit with fail in drm_intel_bo_map_gtt().
+ *
+ * Long before we hit that limit, we will be practically limited by
+ * that any single object must fit in physical memory (RAM). The upper
+ * limit on the CPU's address space is currently 48bits (Skylake), of
+ * which only 39bits can be physical memory. (The GPU itself also has
+ * a 48bit addressable virtual space.) We can fit over 32 million
+ * objects of the current maximum allocable size before running out
+ * of mmap space.
+ */
+ screen->max_gtt_map_object_size = UINT64_MAX;
+ } else {
+ /* Estimate the size of the mappable aperture into the GTT. There's an
+ * ioctl to get the whole GTT size, but not one to get the mappable subset.
+ * It turns out it's basically always 256MB, though some ancient hardware
+ * was smaller.
+ */
+ uint32_t gtt_size = 256 * 1024 * 1024;
+
+ /* We don't want to map two objects such that a memcpy between them would
+ * just fault one mapping in and then the other over and over forever. So
+ * we would need to divide the GTT size by 2. Additionally, some GTT is
+ * taken up by things like the framebuffer and the ringbuffer and such, so
+ * be more conservative.
+ */
+ screen->max_gtt_map_object_size = gtt_size / 4;
+ }
+
+ screen->hw_has_swizzling = intel_detect_swizzling(screen);
+ screen->hw_has_timestamp = intel_detect_timestamp(screen);
+
+ /* GENs prior to 8 do not support EU/Subslice info */
+ if (devinfo->gen >= 8) {
+ intel_detect_sseu(screen);
+ } else if (devinfo->gen == 7) {
+ screen->subslice_total = 1 << (devinfo->gt - 1);
+ }
+
+ /* Gen7-7.5 kernel requirements / command parser saga:
+ *
+ * - pre-v3.16:
+ * Haswell and Baytrail cannot use any privileged batchbuffer features.
+ *
+ * Ivybridge has aliasing PPGTT on by default, which accidentally marks
+ * all batches secure, allowing them to use any feature with no checking.
+ * This is effectively equivalent to a command parser version of
+ * \infinity - everything is possible.
+ *
+ * The command parser does not exist, and querying the version will
+ * return -EINVAL.
+ *
+ * - v3.16:
+ * The kernel enables the command parser by default, for systems with
+ * aliasing PPGTT enabled (Ivybridge and Haswell). However, the
+ * hardware checker is still enabled, so Haswell and Baytrail cannot
+ * do anything.
+ *
+ * Ivybridge goes from "everything is possible" to "only what the
+ * command parser allows" (if the user boots with i915.cmd_parser=0,
+ * then everything is possible again). We can only safely use features
+ * allowed by the supported command parser version.
+ *
+ * Annoyingly, I915_PARAM_CMD_PARSER_VERSION reports the static version
+ * implemented by the kernel, even if it's turned off. So, checking
+ * for version > 0 does not mean that you can write registers. We have
+ * to try it and see. The version does, however, indicate the age of
+ * the kernel.
+ *
+ * Instead of matching the hardware checker's behavior of converting
+ * privileged commands to MI_NOOP, it makes execbuf2 start returning
+ * -EINVAL, making it dangerous to try and use privileged features.
+ *
+ * Effective command parser versions:
+ * - Haswell: 0 (reporting 1, writes don't work)
+ * - Baytrail: 0 (reporting 1, writes don't work)
+ * - Ivybridge: 1 (enabled) or infinite (disabled)
+ *
+ * - v3.17:
+ * Baytrail aliasing PPGTT is enabled, making it like Ivybridge:
+ * effectively version 1 (enabled) or infinite (disabled).
+ *
+ * - v3.19: f1f55cc0556031c8ee3fe99dae7251e78b9b653b
+ * Command parser v2 supports predicate writes.
+ *
+ * - Haswell: 0 (reporting 1, writes don't work)
+ * - Baytrail: 2 (enabled) or infinite (disabled)
+ * - Ivybridge: 2 (enabled) or infinite (disabled)
+ *
+ * So version >= 2 is enough to know that Ivybridge and Baytrail
+ * will work. Haswell still can't do anything.
+ *
+ * - v4.0: Version 3 happened. Largely not relevant.
+ *
+ * - v4.1: 6702cf16e0ba8b0129f5aa1b6609d4e9c70bc13b
+ * L3 config registers are properly saved and restored as part
+ * of the hardware context. We can approximately detect this point
+ * in time by checking if I915_PARAM_REVISION is recognized - it
+ * landed in a later commit, but in the same release cycle.
+ *
+ * - v4.2: 245054a1fe33c06ad233e0d58a27ec7b64db9284
+ * Command parser finally gains secure batch promotion. On Haswell,
+ * the hardware checker gets disabled, which finally allows it to do
+ * privileged commands.
+ *
+ * I915_PARAM_CMD_PARSER_VERSION reports 3. Effective versions:
+ * - Haswell: 3 (enabled) or 0 (disabled)
+ * - Baytrail: 3 (enabled) or infinite (disabled)
+ * - Ivybridge: 3 (enabled) or infinite (disabled)
+ *
+ * Unfortunately, detecting this point in time is tricky, because
+ * no version bump happened when this important change occurred.
+ * On Haswell, if we can write any register, then the kernel is at
+ * least this new, and we can start trusting the version number.
+ *
+ * - v4.4: 2bbe6bbb0dc94fd4ce287bdac9e1bd184e23057b and
+ * Command parser reaches version 4, allowing access to Haswell
+ * atomic scratch and chicken3 registers. If version >= 4, we know
+ * the kernel is new enough to support privileged features on all
+ * hardware. However, the user might have disabled it...and the
+ * kernel will still report version 4. So we still have to guess
+ * and check.
+ *
+ * - v4.4: 7b9748cb513a6bef4af87b79f0da3ff7e8b56cd8
+ * Command parser v5 whitelists indirect compute shader dispatch
+ * registers, needed for OpenGL 4.3 and later.
+ *
+ * - v4.8:
+ * Command parser v7 lets us use MI_MATH on Haswell.
+ *
+ * Additionally, the kernel begins reporting version 0 when
+ * the command parser is disabled, allowing us to skip the
+ * guess-and-check step on Haswell. Unfortunately, this also
+ * means that we can no longer use it as an indicator of the
+ * age of the kernel.
+ */
+ if (intel_get_param(screen, I915_PARAM_CMD_PARSER_VERSION,
+ &screen->cmd_parser_version) < 0) {
+ /* Command parser does not exist - getparam is unrecognized */
+ screen->cmd_parser_version = 0;
+ }
+
+ if (!intel_detect_pipelined_so(screen)) {
+ /* We can't do anything, so the effective version is 0. */
+ screen->cmd_parser_version = 0;
+ } else {
+ screen->kernel_features |= KERNEL_ALLOWS_SOL_OFFSET_WRITES;
+ }