Re: [PATCH v2] modetest: initialize handles/pitches in set_plane()

[Tobias Jakobi <tjakobi@math.uni-bielefeld.de>]

Hello Ilia!


On 2015-04-23 16:32, Ilia Mirkin wrote:
> On Thu, Apr 23, 2015 at 9:39 AM, Tobias Jakobi
> <tjakobi@math.uni-bielefeld.de> wrote:
>> Hello Ilia,
>> 
>> On 2015-04-21 21:15, Ilia Mirkin wrote:
>>> 
>>> I know it was immensely useful to me when I was adding YUV plane
>>> support to nouveau. Seemed to work as advertised at the time (1.5y
>>> ago) for YUYV, UYVY, and NV12.
>>> 
>>>   -ilia
>> 
>> maybe you can help me with that question.
>> 
>> Let's consider a user of the DRM interface that wants to feed NV12 
>> data to
>> it. NV12 is bi-planar, so the user should provide two
>> handles/pitches/offsets describing chroma and luma plane respectively. 
>> But
>> most of the time chroma and luma is contiguous in memory, with nothing 
>> in
>> between.
>> 
>> I was wondering if it is an allowed setup to request NV12 as 
>> pixelformat,
>> but only to provide _one_ handle/pitch/offset? (implying that we are 
>> in the
>> contiguous setting)
> 
> Uhm... I'm no authority on the matter, merely vouching for the
> usefulness of the modetest tool :) However I was never aware of any
> contiguousness assumptions in NV12, afaik the two different planes are
> different :) It could also cause issues if you had, a, say, 32x30
> image but whatever hw produced it wanted to make it 32x32. You'd end
> up with an offset between the two planes which wouldn't be specified.
> FWIW on the (much older) NVIDIA gpu's that I added support for, it
> assumes a separate offset:
> 
>                 nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
>                         nv_fb->nvbo->bo.offset + fb->offsets[1]);
> 
> Note that as far as the HW is concerned, it's an entirely separate
> memory location, not even an offset from the Y plane -- it could be 2
> totally separate bo's for all it cares.
Thanks for the insight! That's kind of what I expected.

What confused me though is that the v4l2 API has this:
http://www.hep.by/gnu/kernel/media/V4L2-PIX-FMT-NV12M.html

Maybe pixelformats are passed around differently in v4l2, but as far as 
I can see, the difference between v4l2-NV12 and v4l2-NV12M doesn't exist 
in DRM land. As soon as NV12 is used, we always have two planes given 
explicitly.



> Also, as another datapoint, the VP3 and newer video decoding units on
> NVIDIA cards (generally speaking GeForce 200+) have firmware that
> produces the Y and UV data as completely separate pieces of data as
> well. On VP2 they had to be in the same buffer, but you could provide
> an explicit offset to the UV bit.
OK, so the Exynos video processor kinda does the same here. It needs 
separate pointers to chroma and luma.


> 
>   -ilia


With best wishes,
Tobias


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel