On 10/15/19 8:42 AM, Daniel Vetter wrote:
On Tue, Oct 15, 2019 at 5:14 PM James Jones wrote:
On 10/15/19 7:19 AM, Daniel Vetter wrote:
On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote:
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "fields" to t
On Tue, Oct 15, 2019 at 5:14 PM James Jones wrote:
>
> On 10/15/19 7:19 AM, Daniel Vetter wrote:
> > On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote:
> >> Builds upon the existing NVIDIA 16Bx2 block linear
> >> format modifiers by adding more "fields" to the
> >> existing parameterized
On 10/15/19 7:19 AM, Daniel Vetter wrote:
On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote:
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "fields" to the
existing parameterized
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier
macro that allow full
On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote:
> Builds upon the existing NVIDIA 16Bx2 block linear
> format modifiers by adding more "fields" to the
> existing parameterized
> DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier
> macro that allow fully defining a unique-across-
> all-N
Beyond general review, I'm looking for feedback on a few things
specifically here:
-Is the level of backwards compatibility described here sufficient?
Technically I can make the user space drivers support the old
modifiers too, but that would mean the layout they specify would
morph based on th
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "fields" to the
existing parameterized
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier
macro that allow fully defining a unique-across-
all-NVIDIA-hardware bit layout using a minimal
set of fields and values. The
