Re: [Freedreno] [RFC PULL] Add Display Support for Qualcomm SDM845

[Daniel Stone]

Hi,

On 14 February 2018 at 13:50, Sean Paul <seanp...@chromium.org> wrote:
> On Wed, Feb 14, 2018 at 07:22:53AM -0500, Rob Clark wrote:
>> On Wed, Feb 14, 2018 at 3:30 AM, Daniel Stone <dan...@fooishbar.org> wrote:
>> > This one I guess you can't get around though. Can they still run from
>> > the one plane, or do you secretly consume two planes?
>>
>> I think it is still the case, like mdp5, that you need two hw pipes..
>> but actually it gets more crazy, since there are some cases where two
>> planes could share a hw pipe.
>
> Right. Large fbs might require 2 pipes, and multiple overlapping or adjacent 
> small fbs
> can be serviced with 1 pipe.

I didn't know about using a single pipe for multiple framebuffers.
That's quite special indeed.

I think virtualising probably makes sense in that case: rather than
just getting around limitations, it's seeming like more of a VC4
situation where they just really aren't actually planes in the first
place.

Cheers,
Daniel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [RFC PULL] Add Display Support for Qualcomm SDM845

[Daniel Stone]

Hi Rob,

On 13 February 2018 at 20:00, Rob Clark  wrote:
> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul  wrote:
>> Qualcomm has been working for the past few weeks on forward porting their
>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>> request for review, rather than an attempt at mainlining the code as it
>> currently stands. The goal is get this driver in shape over the next coming
>> months.
>
> just so others aren't confused, s/sde/dpu/g in the list below (we did
> our DAL->DC rename before sending first RFC :-P)

Heh, and it is quite a bit of code to dig through. I haven't yet got a
chance to fully check it out.

>> - include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)

We don't really have a good story for pixel-processing API anywhere tbh.

> To add to that, a few things I've noticed (but I've mostly only gotten
> as far as the front-end of the pipeline, ie. dpu_plane):
>
>  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
>there are still unequal capabilities for planes (ie. some can do YUV,
>scaling, etc).
>
>But drm-hwc (or weston) isn't going to know about that, so I think we'll
>need to add support for dynamically assigning dpu_plane::pipe, similar
>to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
>for drm-hwc ;-))

Formats/modifiers we do at least get per-plane. We won't know about
scaling, but at least Weston will go through trying each plane in
sequence until it finds one which accepts the configuration. Could HWC
do something like that with atomic, or does it rely on coming up with
a plan first rather than the brute-force testing approach? I haven't
seen its planner at all recently I'm afraid.

>  - I *think* we also need the same trick for combining mixers under one CRTC
>for 4k modes too?

This one I guess you can't get around though. Can they still run from
the one plane, or do you secretly consume two planes?

>  - in dpu_plane, and perhaps elsewhere, userspace pointers for things like CSC
>and scaling coefficients need to be annotated w/ __user.  (Except the 
> should
>probably be blob properties instead.. and we probably need to strip out the
>custom properties and re-introduce them separately with some userspace +
>review.)

It'd be good to know if the CSC could use the CRTC GAMMA_LUT -> CTM ->
DEGAMMA_LUT properties, if they were moved over to planes. (And if
not, why not; if there's any functionality missing from those, what it
is, etc.)

Cheers,
Daniel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [PATCH 00/11] drm/msm: A5XX preemption

[Daniel Stone]

Hi,

On 6 February 2017 at 17:59, Daniel Vetter  wrote:
> On Mon, Feb 06, 2017 at 10:39:28AM -0700, Jordan Crouse wrote:
>> This initial series implements 4 ringbuffers to give sufficient coverage for 
>> the
>> range of priority levels requested by the GLES and compute extensions. The
>> targeted ringbuffer is specified in the command submission flags. The default
>> ring is 0 (lowest priority).
>
> Link to userspace part that implements these extensions? Also which
> gles/compute extensions are you talking about? Asking not just because of
> the open source userspace requirement, but also because we want to
> upstream a scheduler on the i915 side. Getting alignment on that across
> drm drivers would be sweet.

Assuming he meant EGL rather than GLES, this is the usual one:
https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt

Cheers,
Daniel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno