Re: [PATCH v5 00/21] sync_file API is not very suitable for DRM
28.01.2021 00:53, Mikko Perttunen пишет: > On 1/27/21 11:35 PM, Dmitry Osipenko wrote: >> 26.01.2021 05:45, Mikko Perttunen пишет: 4. Sync file shouldn't be needed for the part of DRM API which doesn't interact with external non-DRM devices. We should use DRM syncobj for everything related to DRM, it's a superior API over sync file, it's suitable for DRM scheduler. >>> >>> Considering the issues with fileno limits, I suppose there is no other >>> choice. Considering the recent NTSYNC proposal by Wine developers, maybe >>> we should also have NTHANDLEs to get rid of restrictions of file >>> descriptors. >> >> It's odd to me that you trying to avoid the existing DRM API. This all >> was solved in DRM long time ago and grate drivers have no problems with >> using the DRM APIs. Even if something is really missing, then you should >> add the missing features instead of re-inventing everything from scratch. >> > > DRM is only one of many subsystems that will have to deal with > syncpoints, so I have wanted to have a central solution instead of > reimplementing the same stuff everywhere. sync_files seem like the > "missing feature", but they are difficult to use it with the fileno > limits. But as has been said many times, they are intended only to > transfer fences between the implementations in individual drivers, so I > guess I will have to abandon this dream. Let's focus on finishing the basics first, using what we already have. Sync file + syncobj should be good enough for what we need right now. >>> DRM syncobjs may have some advantages over sync files, but >>> also disadvantages. They cannot be poll()ed, so they cannot be combined >>> with waits for other resources. >> >> I'm not sure do you mean by "poll". Sync object supports polling very >> well. >> > > I mean the poll/select etc. series of functions, which wait for file > descriptors to become ready. If there's some trick that allows syncobjs > to be used for that, then please tell. Please explain in details what problem you need to solve, give an example. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/21] sync_file API is not very suitable for DRM
26.01.2021 05:45, Mikko Perttunen пишет: >> 4. Sync file shouldn't be needed for the part of DRM API which doesn't >> interact with external non-DRM devices. We should use DRM syncobj for >> everything related to DRM, it's a superior API over sync file, it's >> suitable for DRM scheduler. > > Considering the issues with fileno limits, I suppose there is no other > choice. Considering the recent NTSYNC proposal by Wine developers, maybe > we should also have NTHANDLEs to get rid of restrictions of file > descriptors. It's odd to me that you trying to avoid the existing DRM API. This all was solved in DRM long time ago and grate drivers have no problems with using the DRM APIs. Even if something is really missing, then you should add the missing features instead of re-inventing everything from scratch. > DRM syncobjs may have some advantages over sync files, but > also disadvantages. They cannot be poll()ed, so they cannot be combined > with waits for other resources. I'm not sure do you mean by "poll". Sync object supports polling very well. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/21] sync_file API is not very suitable for DRM
On 1/27/21 11:35 PM, Dmitry Osipenko wrote: 26.01.2021 05:45, Mikko Perttunen пишет: 4. Sync file shouldn't be needed for the part of DRM API which doesn't interact with external non-DRM devices. We should use DRM syncobj for everything related to DRM, it's a superior API over sync file, it's suitable for DRM scheduler. Considering the issues with fileno limits, I suppose there is no other choice. Considering the recent NTSYNC proposal by Wine developers, maybe we should also have NTHANDLEs to get rid of restrictions of file descriptors. It's odd to me that you trying to avoid the existing DRM API. This all was solved in DRM long time ago and grate drivers have no problems with using the DRM APIs. Even if something is really missing, then you should add the missing features instead of re-inventing everything from scratch. DRM is only one of many subsystems that will have to deal with syncpoints, so I have wanted to have a central solution instead of reimplementing the same stuff everywhere. sync_files seem like the "missing feature", but they are difficult to use it with the fileno limits. But as has been said many times, they are intended only to transfer fences between the implementations in individual drivers, so I guess I will have to abandon this dream. DRM syncobjs may have some advantages over sync files, but also disadvantages. They cannot be poll()ed, so they cannot be combined with waits for other resources. I'm not sure do you mean by "poll". Sync object supports polling very well. I mean the poll/select etc. series of functions, which wait for file descriptors to become ready. If there's some trick that allows syncobjs to be used for that, then please tell. Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
