26.10.2020 12:11, Mikko Perttunen пишет: >> >> The first patches should be the ones that are relevant to the existing >> userspace code, like support for the waits. > > Can you elaborate what you mean by this? All features that don't have an immediate real use-case should be placed later in the series because we may defer merging of those patches until we will see userspace that uses those features since we can't really decide whether these are decisions that we won't regret later on, only practical application can confirm the correctness. >> Partial mappings should be a separate feature because it's a >> questionable feature that needs to be proved by a real userspace first. >> Maybe it would be even better to drop it for the starter, to ease >> reviewing. > > Considering that the "no-op" support for it (map the whole buffer but > just keep track of the starting offset) is only a couple of lines, I'd > like to keep it in. There is no tracking in the current code which prevents the duplicated mappings, will we need to care about it? This a bit too questionable feature for now, IMO. I'd like to see it as a separate patch. ... >> I'd like to see the DRM_SCHED and syncobj support. I can help you with >> it if it's out of yours scope for now. >> > > I already wrote some code for syncobj I can probably pull in. Regarding > DRM_SCHED, help is accepted. However, we should keep using the hardware > scheduler, and considering it's a bigger piece of work, let's not block > this series on it. I'd like to see all the custom IOCTLs to be deprecated and replaced with the generic DRM API wherever possible. Hence, I think it should be a mandatory features that we need to focus on. The current WIP userspace already uses and relies on DRM_SCHED. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
