On modern systems with 4GB apertures, the size in bytes is
4294967296,
or (1ull << 32). The kernel gives us the aperture size as a __u64,
which works out great.
Unfortunately, libdrm "helpfully" returns the data as a size_t, which
on 32-bit systems means it truncates the aperture size to 0 bytes.
We've happily reported this value as 0 MB of video memory via
GLX_MESA_query_renderer since it was originally exposed.
This patch bypasses libdrm and calls the ioctl ourselves so we can
use a proper uint64_t, avoiding the 32-bit integer overflow. We now
report a proper video memory size on 32-bit systems.
Chris points out that the aperture size (CPU mappable size limit)
isn't really the right thing to be checking. But libdrm_intel uses
it to fail execbuffer, so it is an actual limit for now. Once that's
fixed we can probably move to something else. In the meantime, fix
the obvious typecasting bug.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
.createImageWithModifiers = intel_create_image_with_modifiers,
};
+static uint64_t
+get_aperture_size(int fd)
+{
+ struct drm_i915_gem_get_aperture aperture;
+
+ if (drmIoctl(fd, DRM_IOCTL_I915_GEM_GET_APERTURE, &aperture) != 0)
+ return 0;
+
+ return aperture.aper_size;
+}
+
static int
brw_query_renderer_integer(__DRIscreen *dri_screen,
int param, unsigned int *value)
* assume that there's some fragmentation, and we start doing extra
* flushing, etc. That's the big cliff apps will care about.
*/
- size_t aper_size;
- size_t mappable_size;
-
- drm_intel_get_aperture_sizes(dri_screen->fd, &mappable_size, &aper_size);
+ uint64_t aper_size = get_aperture_size(dri_screen->fd);
const unsigned gpu_mappable_megabytes =
(aper_size / (1024 * 1024)) * 3 / 4;