That's a reasonable plan for now. For LINEAR, X, and Y, the
drmFormatModifierCount is the obvious value for the format. That's enough to
satisfy all the needs of Chrome OS and its zoo of virtual machines. For
simplicity, we can keep VK_FORMAT_FEATURE_DISJOINT_BIT disabled in
I should have said that the minimal support can be for LINEAR, X-tiled
and Y-tiled. CCS can and probably should come later.
On Wed, Jun 9, 2021 at 6:14 PM Yiwei Zhang wrote:
>
> On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand wrote:
> >
> > +Nanley
> >
> > We've not defined those yet. We had
+Nanley
We've not defined those yet. We had some internal talks a couple
years ago. The rough idea we had at the time was to define a modifier
for those cases which put the CCS after each main surface at some
fixed calculation offset based on width, height, and stride. Then the
one modifier
The Problem: For a given 3-tuple (multi-planar format, DRM format modifier,
chipset), we need Intel ABI that decides (a) the value of
VkDrmFormatModifierPropertiesEXT::drmFormatModifierPlaneCount and (b) the
content of each "modifier" plane.
For example, suppose drmFormatModifierPlaneCount is
On Wed, Jun 09, 2021 at 03:58:26PM +0200, Christian König wrote:
> Am 09.06.21 um 15:19 schrieb Daniel Vetter:
> > [SNIP]
> > > Yeah, we call this the lightweight and the heavyweight tlb flush.
> > >
> > > The lighweight can be used when you are sure that you don't have any of
> > > the
> > >
Am 09.06.21 um 15:19 schrieb Daniel Vetter:
[SNIP]
Yeah, we call this the lightweight and the heavyweight tlb flush.
The lighweight can be used when you are sure that you don't have any of the
PTEs currently in flight in the 3D/DMA engine and you just need to
invalidate the TLB.
The
On Fri, Jun 04, 2021 at 01:27:15PM +0200, Christian König wrote:
> Am 04.06.21 um 10:57 schrieb Daniel Vetter:
> > On Fri, Jun 04, 2021 at 09:00:31AM +0200, Christian König wrote:
> > > Am 02.06.21 um 21:19 schrieb Daniel Vetter:
> > > > On Wed, Jun 02, 2021 at 08:52:38PM +0200, Christian König
