[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

[Egbert Eich]

The Radeon driver reduces the framebuffer resolution to 8bpp if
a device with less than 32 Mb VRAM is found. This causes the
framebuffer to run in 8 bit paletted mode. For a text console this
is not an issue as 256 different colors is more than one gets
on a VGA text console.
It is done to give X more memory to work with since the console memory
is not freed but remains allocated while X is active.
Still, running the fbdev Xserver driver - which we do during installation
- will give applications an 8bit pseudo-color visual which doesn't look
too pretty.
We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower
and to 8 only if 8MB or less VRAM is found.
This should be a reasonable compromise for us.
This patch will most likely not ever make it upstream.

This works around ugly modes on crappy IPMI cards using ES1000.

Signed-off-by: Egbert Eich <eich@suse.de>
---
 drivers/gpu/drm/radeon/radeon_fb.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c
index cc8489d..9e8e221 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev)
 	int bpp_sel = 32;
 	int ret;
 
-	/* select 8 bpp console on RN50 or 16MB cards */
-	if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
+	/* select 16 bpp console on RN50 or 32MB cards */
+	if (rdev->mc.real_vram_size <= (8*1024*1024))
 		bpp_sel = 8;
+	else if (ASIC_IS_RN50(rdev)
+		  || rdev->mc.real_vram_size <= (32*1024*1024))
+		bpp_sel = 16;
 
 	rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL);
 	if (!rfbdev)
-- 
1.7.6.3

Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

[Alex Deucher]

On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich <eich@suse.de> wrote:
> The Radeon driver reduces the framebuffer resolution to 8bpp if
> a device with less than 32 Mb VRAM is found. This causes the
> framebuffer to run in 8 bit paletted mode. For a text console this
> is not an issue as 256 different colors is more than one gets
> on a VGA text console.
> It is done to give X more memory to work with since the console memory
> is not freed but remains allocated while X is active.
> Still, running the fbdev Xserver driver - which we do during installation
> - will give applications an 8bit pseudo-color visual which doesn't look
> too pretty.
> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower
> and to 8 only if 8MB or less VRAM is found.
> This should be a reasonable compromise for us.
> This patch will most likely not ever make it upstream.
>
> This works around ugly modes on crappy IPMI cards using ES1000.

I don't have a strong opinion either way on this one.

Alex

>
> Signed-off-by: Egbert Eich <eich@suse.de>
> ---
>  drivers/gpu/drm/radeon/radeon_fb.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c
> index cc8489d..9e8e221 100644
> --- a/drivers/gpu/drm/radeon/radeon_fb.c
> +++ b/drivers/gpu/drm/radeon/radeon_fb.c
> @@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev)
>         int bpp_sel = 32;
>         int ret;
>
> -       /* select 8 bpp console on RN50 or 16MB cards */
> -       if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
> +       /* select 16 bpp console on RN50 or 32MB cards */
> +       if (rdev->mc.real_vram_size <= (8*1024*1024))
>                 bpp_sel = 8;
> +       else if (ASIC_IS_RN50(rdev)
> +                 || rdev->mc.real_vram_size <= (32*1024*1024))
> +               bpp_sel = 16;
>
>         rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL);
>         if (!rfbdev)
> --
> 1.7.6.3
>

Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

[Dave Airlie]

On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich <eich@suse.de> wrote:
>> The Radeon driver reduces the framebuffer resolution to 8bpp if
>> a device with less than 32 Mb VRAM is found. This causes the
>> framebuffer to run in 8 bit paletted mode. For a text console this
>> is not an issue as 256 different colors is more than one gets
>> on a VGA text console.
>> It is done to give X more memory to work with since the console memory
>> is not freed but remains allocated while X is active.
>> Still, running the fbdev Xserver driver - which we do during installation
>> - will give applications an 8bit pseudo-color visual which doesn't look
>> too pretty.
>> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower
>> and to 8 only if 8MB or less VRAM is found.
>> This should be a reasonable compromise for us.
>> This patch will most likely not ever make it upstream.
>>
>> This works around ugly modes on crappy IPMI cards using ES1000.
>
> I don't have a strong opinion either way on this one.

Why would you use fbdev? package -modesetting at least if not the real ATI DDX.

Dave.

Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

[Egbert Eich]

Dave Airlie writes:
 > On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
 > > On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich <eich@suse.de> wrote:
 > >> The Radeon driver reduces the framebuffer resolution to 8bpp if
 > >> a device with less than 32 Mb VRAM is found. This causes the
 > >> framebuffer to run in 8 bit paletted mode. For a text console this
 > >> is not an issue as 256 different colors is more than one gets
 > >> on a VGA text console.
 > >> It is done to give X more memory to work with since the console memory
 > >> is not freed but remains allocated while X is active.
 > >> Still, running the fbdev Xserver driver - which we do during installation
 > >> - will give applications an 8bit pseudo-color visual which doesn't look
 > >> too pretty.
 > >> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower
 > >> and to 8 only if 8MB or less VRAM is found.
 > >> This should be a reasonable compromise for us.
 > >> This patch will most likely not ever make it upstream.
 > >>
 > >> This works around ugly modes on crappy IPMI cards using ES1000.
 > >
 > > I don't have a strong opinion either way on this one.
 > 
 > Why would you use fbdev? package -modesetting at least if not the real ATI DDX.
 > 

fbdev is good as a general fallback which works pretty much everywhere - even
if there's no KMS driver available in the kernel (in this case with vesa
fbdev).
I'm not pushing strongly for this patch making it into the mainline kernel,
I need to carry it around for our enterprise product for the time being.
It could well be that it can be tossed once we redesign things for SLE13.

But maybe you may want to repace the '<=' with a '<' so that the code 
matches the comment above ie. that one gets 8bpp only for 16MB and less
which would already help.

Cheers,
	Egbert.

Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

[Michel Dänzer]

On Mit, 2012-10-24 at 18:33 +0200, Egbert Eich wrote: 
> The Radeon driver reduces the framebuffer resolution to 8bpp if
> a device with less than 32 Mb VRAM is found. This causes the
> framebuffer to run in 8 bit paletted mode. For a text console this
> is not an issue as 256 different colors is more than one gets
> on a VGA text console.
> It is done to give X more memory to work with since the console memory
> is not freed but remains allocated while X is active.
> Still, running the fbdev Xserver driver - which we do during installation
> - will give applications an 8bit pseudo-color visual which doesn't look
> too pretty.

Is it not possible for xf86-video-fbdev to choose a higher depth anyway,
even if specified explicitly in xorg.conf or on the Xorg command line?


> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower
> and to 8 only if 8MB or less VRAM is found.
> This should be a reasonable compromise for us.
> This patch will most likely not ever make it upstream.

This last sentence seems stale here. :)


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer