On Friday 17 November 2017 20:52:45 Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@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 > >>> > >>> <li...@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"). >
Changing that to 0x80000000 does not help :( > In case I was being unclear, I'm talking about > > https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L >1808 > > 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: lut_clr is not called during boot so we can ignore it for now. > 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 -- Ondrej Zary _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau