On 1/27/21 11:20 PM, Dmitry Osipenko wrote:
26.01.2021 05:45, Mikko Perttunen пишет:
2. We will probably need a dedicated drm_tegra_submit_cmd for sync point
increments. The job's sync point will be allocated dynamically when job
is submitted. We will need a fag for the sync_incr and wait_syncpt
commands, saying "it's a job's sync point increment/wait"
Negative. Like I have explained in previous discussions, with the
current way the usage of hardware resources is much more deterministic
and obvious. I disagree on the point that this is much more complicated
for the userspace. Separating syncpoint and channel allocation is one of
the primary motivations of this series for me.
Sync points are a limited resource. The most sensible way to work around
it is to keep sync points within kernel as much as possible. This is not
only much simpler for user space, but also allows to utilize DRM API
properly without re-inventing what already exists and it's easier to
maintain hardware in a good state.
I've spent the last few years designing for automotive and industrial
products, where we don't want to at runtime notice that the system is
out of free syncpoints and because of that we can only process the next
camera frame in a second or two instead of 16 milliseconds. We need to
know that once we have allocated the resource, it is there. The newer
chips are also designed to support this.
Considering Linux is increasingly being used for such applications, and
they are important target markets for NVIDIA, these need to be supported.
Because of the above design constraint the userspace software that runs
in these environments also expects resources to be allocated up front.
This isn't a matter of having to design that software according to what
kind of allocation API we decide do at Linux level -- it's no use
designing for dynamic allocation if it leads to you not meeting the
safety requirement of needing to ensure you have all resources allocated
up front.
This isn't a good design feature just in a car, but in anything that
needs to be reliable. However, it does pose some tradeoffs, and if you
think that running out of syncpoints on T20-T114 because of upfront
allocation is an actual problem, I'm not opposed to having both options
available.
If you need to use a dedicated sync point for VMs, then just allocate
that special sync point and use it. But this sync point won't be used
for jobs tracking by kernel driver. Is there any problem with this?
In addition to above, it would increase the number of syncpoints
required. The number of syncpoints supported by hardware has been
calculated for specific use cases, and increasing the number of required
syncpoints risks not being able to support those use cases.
The primary motivation for me is to get a practically usable kernel
driver for userspace.
Me too. For the traditional "tablet chips" the task is quite well
defined and supported. But my goal is to also get rid of the jank in
downstream and allow fully-featured use of Tegra devices on upstream
kernels and for that, the driver needs to be usable for the whole range
of use cases.
Mikko
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
