thr3ads.net - Nouveau - [Nouveau] Blank console but X11 works on MCP79

If this information is useful, please help other people find it:
Share via:

Ondrej Zary

2017-Nov-17 19:25 UTC

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>
> <linux at rainbow-software.org> wrote:
> > @@ -483,8 +483,8 @@
> >  nouveau 0000:02:00.0: disp:    0860: 00000000 -> 00000500
> >  nouveau 0000:02:00.0: disp:    0864: 00000000
> >  nouveau 0000:02:00.0: disp:    0868: 00000000 -> 04000500
> > -nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100500
> > -nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 00001e00
> > +nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100a00
> > +nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 0000e800
> >  nouveau 0000:02:00.0: disp:    0874: 00000000 -> ffff0000
> >  nouveau 0000:02:00.0: disp:    0878: 00000000
> >  nouveau 0000:02:00.0: disp:    0880: 05000000
> >
> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp
(0xe800) in
> > 64MB case. Why?
> >
> > I get blank screen even with 64MB with video=1280x1024-8 kernel
> > parameter. Console works with video=1280x1024-16 even with 32MB stolen
> > memory.
> >
> > Conclusions: 8-bit support is broken and bpp reduction is weird.
>
> OK, well that makes a *ton* of sense (8bpp being broken).
>
> I think the idea of bpp reduction is that when you're on your shiny
> new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating
> all that to a pinned fbcon - almost half of that would go to a single
> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
> have at least a few fb-sized buffers for backbuffer rendering, etc.
>
> The specific limits could probably use tweaking - I think they only
> consider VRAM size, not the fb size.
>
> I guess 8bpp worked prior to the change you bisected though, so we
> should figure out what we did wrong in the new code.
Yes, booted 3.7 (last working kernel) and it's running in 8bpp.

I guess that nv50_head_gamma_set() is missing something like this (from 
nv_crtc_gamma_set()):
        /* We need to know the depth before we upload, but it's possible to
         * get called before a framebuffer is bound.  If this is the case,
         * mark the lut values as dirty by setting depth==0, and it'll be
         * uploaded on the first mode_set_base()
         */
        if (!nv_crtc->base.primary->fb) {
                nv_crtc->lut.depth = 0;
                return 0;
        }

That's easy to add but there's no mode_set_base() for nv50 so
there's no place
to add code like this:
        if (nv_crtc->lut.depth != drm_fb->format->depth) {
                nv_crtc->lut.depth = drm_fb->format->depth;
                nv_crtc_gamma_load(crtc);
        }

-- 
Ondrej Zary

Ilia Mirkin

2017-Nov-17 19:37 UTC

head link

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux at
rainbow-software.org> wrote:> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>
>> <linux at rainbow-software.org> wrote:
>> > @@ -483,8 +483,8 @@
>> >  nouveau 0000:02:00.0: disp:    0860: 00000000 -> 00000500
>> >  nouveau 0000:02:00.0: disp:    0864: 00000000
>> >  nouveau 0000:02:00.0: disp:    0868: 00000000 -> 04000500
>> > -nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100500
>> > -nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 00001e00
>> > +nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100a00
>> > +nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 0000e800
>> >  nouveau 0000:02:00.0: disp:    0874: 00000000 -> ffff0000
>> >  nouveau 0000:02:00.0: disp:    0878: 00000000
>> >  nouveau 0000:02:00.0: disp:    0880: 05000000
>> >
>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp
(0xe800) in
>> > 64MB case. Why?
>> >
>> > I get blank screen even with 64MB with video=1280x1024-8 kernel
>> > parameter. Console works with video=1280x1024-16 even with 32MB
stolen
>> > memory.
>> >
>> > Conclusions: 8-bit support is broken and bpp reduction is weird.
>>
>> OK, well that makes a *ton* of sense (8bpp being broken).
>>
>> I think the idea of bpp reduction is that when you're on your shiny
>> new Riva TNT with 16MB of VRAM, you don't want to go crazy
allocating
>> all that to a pinned fbcon - almost half of that would go to a single
>> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
>> have at least a few fb-sized buffers for backbuffer rendering, etc.
>>
>> The specific limits could probably use tweaking - I think they only
>> consider VRAM size, not the fb size.
>>
>> I guess 8bpp worked prior to the change you bisected though, so we
>> should figure out what we did wrong in the new code.
>
> Yes, booted 3.7 (last working kernel) and it's running in 8bpp.
By the way, instead of booting $kernel, you can use modetest from
libdrm/tests. Not sure if it supports C8 though =/

I think the issue is this:

-               OUT_RING(evo, nv_crtc->lut.depth == 8 ?
-                               NV50_EVO_CRTC_CLUT_MODE_OFF :
-                               NV50_EVO_CRTC_CLUT_MODE_ON);

Whereas now we always set 0xC0000000 (aka "ON").

  -ilia

Ilia Mirkin

2017-Nov-17 19:52 UTC

head link

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin at alum.mit.edu>
wrote:> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux at
rainbow-software.org> wrote:
>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>>
>>> <linux at rainbow-software.org> wrote:
>>> > @@ -483,8 +483,8 @@
>>> >  nouveau 0000:02:00.0: disp:    0860: 00000000 -> 00000500
>>> >  nouveau 0000:02:00.0: disp:    0864: 00000000
>>> >  nouveau 0000:02:00.0: disp:    0868: 00000000 -> 04000500
>>> > -nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100500
>>> > -nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 00001e00
>>> > +nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100a00
>>> > +nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 0000e800
>>> >  nouveau 0000:02:00.0: disp:    0874: 00000000 -> ffff0000
>>> >  nouveau 0000:02:00.0: disp:    0878: 00000000
>>> >  nouveau 0000:02:00.0: disp:    0880: 05000000
>>> >
>>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp
(0xe800) in
>>> > 64MB case. Why?
>>> >
>>> > I get blank screen even with 64MB with video=1280x1024-8
kernel
>>> > parameter. Console works with video=1280x1024-16 even with
32MB stolen
>>> > memory.
>>> >
>>> > Conclusions: 8-bit support is broken and bpp reduction is
weird.
>>>
>>> OK, well that makes a *ton* of sense (8bpp being broken).
>>>
>>> I think the idea of bpp reduction is that when you're on your
shiny
>>> new Riva TNT with 16MB of VRAM, you don't want to go crazy
allocating
>>> all that to a pinned fbcon - almost half of that would go to a
single
>>> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
>>> have at least a few fb-sized buffers for backbuffer rendering, etc.
>>>
>>> The specific limits could probably use tweaking - I think they only
>>> consider VRAM size, not the fb size.
>>>
>>> I guess 8bpp worked prior to the change you bisected though, so we
>>> should figure out what we did wrong in the new code.
>>
>> Yes, booted 3.7 (last working kernel) and it's running in 8bpp.
>
> By the way, instead of booting $kernel, you can use modetest from
> libdrm/tests. Not sure if it supports C8 though =/
>
> I think the issue is this:
>
> -               OUT_RING(evo, nv_crtc->lut.depth == 8 ?
> -                               NV50_EVO_CRTC_CLUT_MODE_OFF :
> -                               NV50_EVO_CRTC_CLUT_MODE_ON);
>
> Whereas now we always set 0xC0000000 (aka "ON").
In case I was being unclear, I'm talking about

https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L1808

and surrounding items. Looks like lut_clr sets 0x40000000 which was
previously not used. Not sure what the difference between that and
0x00000000 is. This is what we have in rnndb for it:

https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L408

So bit 30 is mode, set is "high res", unset is "low res". So
really
what we want is 0x80000000 which leaves the LUT enabled but uses the
low-res mode?

All this could use some playing-around with.

  -ilia

Ilia Mirkin

2017-Nov-18 05:23 UTC

head link

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin at alum.mit.edu>
wrote:> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux at
rainbow-software.org> wrote:
>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>>
>>> <linux at rainbow-software.org> wrote:
>>> > @@ -483,8 +483,8 @@
>>> >  nouveau 0000:02:00.0: disp:    0860: 00000000 -> 00000500
>>> >  nouveau 0000:02:00.0: disp:    0864: 00000000
>>> >  nouveau 0000:02:00.0: disp:    0868: 00000000 -> 04000500
>>> > -nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100500
>>> > -nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 00001e00
>>> > +nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100a00
>>> > +nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 0000e800
>>> >  nouveau 0000:02:00.0: disp:    0874: 00000000 -> ffff0000
>>> >  nouveau 0000:02:00.0: disp:    0878: 00000000
>>> >  nouveau 0000:02:00.0: disp:    0880: 05000000
>>> >
>>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp
(0xe800) in
>>> > 64MB case. Why?
>>> >
>>> > I get blank screen even with 64MB with video=1280x1024-8
kernel
>>> > parameter. Console works with video=1280x1024-16 even with
32MB stolen
>>> > memory.
>>> >
>>> > Conclusions: 8-bit support is broken and bpp reduction is
weird.
>>>
>>> OK, well that makes a *ton* of sense (8bpp being broken).
>>>
>>> I think the idea of bpp reduction is that when you're on your
shiny
>>> new Riva TNT with 16MB of VRAM, you don't want to go crazy
allocating
>>> all that to a pinned fbcon - almost half of that would go to a
single
>>> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
>>> have at least a few fb-sized buffers for backbuffer rendering, etc.
>>>
>>> The specific limits could probably use tweaking - I think they only
>>> consider VRAM size, not the fb size.
>>>
>>> I guess 8bpp worked prior to the change you bisected though, so we
>>> should figure out what we did wrong in the new code.
>>
>> Yes, booted 3.7 (last working kernel) and it's running in 8bpp.
>
> By the way, instead of booting $kernel, you can use modetest from
> libdrm/tests. Not sure if it supports C8 though =/
It didn't. But it does now - I mailed a patch to dri-devel, also (with
slight fix) available at

https://people.freedesktop.org/~imirkin/patches/0001-modetest-add-C8-support-to-generate-SMPTE-pattern.patch

This works on GK208 but not on G92 (whose display unit is much closer
to your MCP79's). You can run as

./modetest -s DVI-I-1:1920x1200 at C8

This should display a SMPTE pattern, and exit when you hit enter. When
it does so, it doesn't restore fbcon, but you can swtich to another
vty to get console back.

I get a white picture on G92. Now just have to figure out how to fix
it. Someone should also test on a G80 if possible, since that takes a
different path as well.

  -ilia

Apparently Analagous Threads

Search for more seemingly similar threads

Nouveau - Nov 2017 - Blank console but X11 works on MCP79 - old regression since 3.8

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

[Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

Apparently Analagous Threads