On 2019-12-05 at 13:11:29 +0000, Chris Wilson wrote: > Quoting Ramalingam C (2019-12-05 13:02:40) > > On 2019-12-05 at 12:20:12 +0000, Chris Wilson wrote: > > > Quoting Matthew Auld (2019-12-05 12:12:19) > > > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > > > > in order to pass the IGTs. We also need to adjust dumb_buffer.c, since > > > > that uses get_avail_ram_mb() for always_clear, but maybe we need the > > > > query region uapi for that? > > > > > > Hmm. Questions over the maximum size for dumb buffer, maximum number of > > > dumb buffers, etc, should be addressed to the dumb API. So some form of > > > drmGetCap() ? > > Chris, Is this suggestion to add this capability probing through a new > > IOCTL for > > dumb APIs? Please clarify. > > I don't think we need a new ioctl, as drm_getcap already covers the dumb > buffer API. We just need to expose the limits of the dumb buffer API > through it. > > The 2 that spring to mind are maximum size of individual buffer and > maximum size of total dumb buffers.
Will there be question for userspace for this extension or no? AFAIK There is no consumer except IGT. -Ram > (The latter may be infinite for > drivers that allow swapping of inactive buffers.) There was a request on > irc for something like this as well, but I'm not aware of the context. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
