Hi Ken,
On 31 March 2017 at 00:28, Kenneth Graunke wrote:
> 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
On Thu, Mar 30, 2017 at 06:48:38PM -0700, Kenneth Graunke wrote:
> Looking again...libdrm_intel sets bufmgr_gem->gtt_size to
> drm_i915_gem_get_aperture::aper_available_size - and uses that field
> to -ENOSPC your execbuffers. drm_intel_get_aperture_sizes, and this
> query, use
On Thursday, March 30, 2017 6:48:38 PM PDT Kenneth Graunke wrote:
> On Thursday, March 30, 2017 4:38:14 PM PDT Chris Wilson wrote:
> > On Thu, Mar 30, 2017 at 04:28:19PM -0700, Kenneth Graunke wrote:
> > > On modern systems with 4GB apertures, the size in bytes is 4294967296,
> > > or (1ull <<
On Thursday, March 30, 2017 4:38:14 PM PDT Chris Wilson wrote:
> On Thu, Mar 30, 2017 at 04:28:19PM -0700, Kenneth Graunke wrote:
> > 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
On Thu, Mar 30, 2017 at 04:28:19PM -0700, Kenneth Graunke wrote:
> 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
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