dri-devel

kms and memory bandwidth limitations

[Dave A. <ai...@gm...>]

So I was looking at the memory bandwidth limitations that ajax added
to the X server,
and how we could add the concept to KMS.

Now the X server is in a lucky position as when it gets the modes it also knows
what bit depth its going to run in, and it can use that at the mode
validation time
to remove modes for bandwidth reasons.

Now KMS doesn't know what bitdepth its users is going to use until
they associate
a modeset is done and the framebuffer is assigned to the crtc, however
failing to
set the mode at this stage would be rude as we never removed the mode
from the list.

I can see a few  solutions to this (some hacky some not):

1) add a new field to the mode getting ioctl, specifying what bit depth the user
would like to have the mode list validated against before returning,
this probably
means speccing a new ioctl since I think this one is full.

2) add a new ioctl to be set by the kms user app, which pretty much says
I'm interested in modes that can work at this bpp, with a default to
32-bit depth.

3) add some new flags to the modes, stating what bit sized depths they are
supported at (i.e. DRM_MODE_FLAG_8BIT, 16BIT, 32BIT, 64BIT etc)

4) pass the info about memory bw to the caller (i.e. X) - uggh no.

I'm sort of leaning towards 2 at the moment as its probably the simpler, just
wondering if anyone has any other ideas or preferences?

Dave.

Re: kms and memory bandwidth limitations

[Alex D. <ale...@gm...>]

On Fri, Oct 2, 2009 at 12:20 AM, Dave Airlie <ai...@gm...> wrote:
> So I was looking at the memory bandwidth limitations that ajax added
> to the X server,
> and how we could add the concept to KMS.
>
> Now the X server is in a lucky position as when it gets the modes it also knows
> what bit depth its going to run in, and it can use that at the mode
> validation time
> to remove modes for bandwidth reasons.
>

As discussed at XDC, it would also be nice to have a randr call to set
up the entire display system in one shot rather than per-crtc since
some combinations of modes and depths may not work in multi-head
configurations, but may be just fine in single head configurations.

Alex

> Now KMS doesn't know what bitdepth its users is going to use until
> they associate
> a modeset is done and the framebuffer is assigned to the crtc, however
> failing to
> set the mode at this stage would be rude as we never removed the mode
> from the list.
>
> I can see a few  solutions to this (some hacky some not):
>
> 1) add a new field to the mode getting ioctl, specifying what bit depth the user
> would like to have the mode list validated against before returning,
> this probably
> means speccing a new ioctl since I think this one is full.
>
> 2) add a new ioctl to be set by the kms user app, which pretty much says
> I'm interested in modes that can work at this bpp, with a default to
> 32-bit depth.
>
> 3) add some new flags to the modes, stating what bit sized depths they are
> supported at (i.e. DRM_MODE_FLAG_8BIT, 16BIT, 32BIT, 64BIT etc)
>
> 4) pass the info about memory bw to the caller (i.e. X) - uggh no.
>
> I'm sort of leaning towards 2 at the moment as its probably the simpler, just
> wondering if anyone has any other ideas or preferences?
>
> Dave.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> --
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>