Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Wednesday 21 February 2018 15:28:53 Ville Syrjälä wrote: > On Mon, Feb 19, 2018 at 10:36:50AM +0100, Pali Rohár wrote: > > On Tuesday 13 February 2018 19:45:56 Ville Syrjälä wrote: > > > On Tue, Feb 13, 2018 at 06:43:41PM +0100, Pali Rohár wrote: > > > > On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote: > > > > > On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote: > > > > > > So it can be done only once after reboot? Or only prior to booting > > > > > > kernel? > > > > > > > > > > Never. > > > > > > > > Never? Now I'm lost. Why then dmesg message instruct user to try set up > > > > it in BIOS if you say it is never possible? > > > > > > You can change it in the BIOS. No way to change it from the operating > > > system. > > > > Hi! Can you explain it a bit more? > > > > What does it mean "in BIOS"? Prior switching from 16bit real mode to > > protected or long? Or before exiting EFI boot services? Or before > > booting kernel (when initialize memory mapping)? > > The BIOS is a black box, no one really knows what it's doing. The stolen > memory is carved out pretty early I think (alongside other carved out > chunks for SMM and whatnot). And once that's done the BIOS usually locks > down stuff like this (the hw has magic write once lock bits for various > registers) so there's just no way to change things afterwards. Thank you for explanation. So real problem with changing size of stolen memory is that BIOS "may" lock future changes. Is there any documentation for this Intel GPU stolen memory? I hope that I should be able at least to read status of that lock registers -- to prove that size of stolen memory is locked and cannot be changed. > > > > I still do not see reason nor understand why this cannot be possible > > either in bootloader (e.g. grub2) or prior to loading bootloader which > > runs in protected or long mode. > > > > It is because BIOS uses some undocumented call/procedure which sets that > > amount of memory and it is unknown how to do it? > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > -- Pali Rohár pali.ro...@gmail.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Mon, Feb 19, 2018 at 10:36:50AM +0100, Pali Rohár wrote: > On Tuesday 13 February 2018 19:45:56 Ville Syrjälä wrote: > > On Tue, Feb 13, 2018 at 06:43:41PM +0100, Pali Rohár wrote: > > > On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote: > > > > On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote: > > > > > So it can be done only once after reboot? Or only prior to booting > > > > > kernel? > > > > > > > > Never. > > > > > > Never? Now I'm lost. Why then dmesg message instruct user to try set up > > > it in BIOS if you say it is never possible? > > > > You can change it in the BIOS. No way to change it from the operating > > system. > > Hi! Can you explain it a bit more? > > What does it mean "in BIOS"? Prior switching from 16bit real mode to > protected or long? Or before exiting EFI boot services? Or before > booting kernel (when initialize memory mapping)? The BIOS is a black box, no one really knows what it's doing. The stolen memory is carved out pretty early I think (alongside other carved out chunks for SMM and whatnot). And once that's done the BIOS usually locks down stuff like this (the hw has magic write once lock bits for various registers) so there's just no way to change things afterwards. > > I still do not see reason nor understand why this cannot be possible > either in bootloader (e.g. grub2) or prior to loading bootloader which > runs in protected or long mode. > > It is because BIOS uses some undocumented call/procedure which sets that > amount of memory and it is unknown how to do it? > > -- > Pali Rohár > pali.ro...@gmail.com -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tuesday 13 February 2018 19:45:56 Ville Syrjälä wrote: > On Tue, Feb 13, 2018 at 06:43:41PM +0100, Pali Rohár wrote: > > On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote: > > > On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote: > > > > So it can be done only once after reboot? Or only prior to booting > > > > kernel? > > > > > > Never. > > > > Never? Now I'm lost. Why then dmesg message instruct user to try set up > > it in BIOS if you say it is never possible? > > You can change it in the BIOS. No way to change it from the operating system. Hi! Can you explain it a bit more? What does it mean "in BIOS"? Prior switching from 16bit real mode to protected or long? Or before exiting EFI boot services? Or before booting kernel (when initialize memory mapping)? I still do not see reason nor understand why this cannot be possible either in bootloader (e.g. grub2) or prior to loading bootloader which runs in protected or long mode. It is because BIOS uses some undocumented call/procedure which sets that amount of memory and it is unknown how to do it? -- Pali Rohár pali.ro...@gmail.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tue, Feb 13, 2018 at 06:43:41PM +0100, Pali Rohár wrote: > On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote: > > On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote: > > > $ cat /sys/kernel/debug/dri/0/i915_gem_stolen > > > Stolen: > > >8b55bf17e080:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 1) (ggtt offset: 00083000, size: 4000, type: 0) (stolen: > > > 1000) > > >8b55c2693040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 1) (ggtt offset: 02b9f000, size: 4000, type: 0) (stolen: > > > 5000) > > >8b55bf9a7300:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 0) (ggtt offset: 0f6b4000, size: 4000, type: 0) (stolen: > > > 9000) > > >8b55a6161040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 0) (ggtt offset: 0937f000, size: 4000, type: 0) (stolen: > > > d000) > > >8b5563e0dac0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 0) (ggtt offset: 0f714000, size: 4000, type: 0) (stolen: > > > 00019000) > > >8b55bf17e800:g 4KiB 41 00 [ 0 0 0 0 ] 0 LLC (pinned x > > > 1) (ggtt offset: e000, size: 1000, type: 0) (stolen: 0012c000) > > >8b55bf02d540:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 1) (ggtt offset: 00141000, size: 4000, type: 0) (stolen: > > > 0012d000) > > >8b55c2989340:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 1) (ggtt offset: 00148000, size: 4000, type: 0) (stolen: > > > 00131000) > > >8b55c29890c0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 1) (ggtt offset: 0014f000, size: 4000, type: 0) (stolen: > > > 00135000) > > >8b55c2989840:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 1) (ggtt offset: 00156000, size: 4000, type: 0) (stolen: > > > 00139000) > > >8b55bf02da40: p g 14400KiB 77 00 [ 0 0 0 0 ] 0 uncached > > > dirty (name: 1) (pinned x 1) (display) (ggtt offset: 0015a000, size: > > > 00e1, type: 0) (stolen: 0013d000) (p mappable) > > >8b556dfba780:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > > (pinned x 0) (ggtt offset: 0ad2a000, size: 4000, type: 0) (stolen: > > > 01655000) > > > > > > > likely you'll have the fbdev framebuffer taking up a sizeable chunk. > > > > > > Seems 14MB. > > > > > > > You could get some back by reducing fbdev depth to 16bpp, or even 8bpp, > > > > but I'm not convinced the fbdev gamma LUT stuff really works currently > > > > so you might end up with bogus colors in your vts with that. > > > > > > Ok, I could try it. Via fbset tool? > > > > Kernel command line. We don't allow resizing the fbdev fb once it's > > created. > > Ok, will try. > > > > > > > > > > > > > > [0.00] Memory: 7972840K/8282704K available (6196K kernel > > > > > code, 1159K rwdata, 2848K rodata, 1408K init, 688K bss, 309864K > > > > > reserved, 0K cma-reserved) > > > > > > > > > > > The BIOS may or may not provide a knob to change the size > > > > > > of the stolen memory. > > > > > > > > > > In BIOS Setup screen I have option to choose GPU memory and I set it > > > > > to > > > > > max 512MB. So this is not the right option... > > > > > > > > > > And why cannot kernel use some continuous check of RAM itself? > > > > > > > > Because the hardware won't allow it. > > > > > > So it can be done only once after reboot? Or only prior to booting kernel? > > > > Never. > > Never? Now I'm lost. Why then dmesg message instruct user to try set up > it in BIOS if you say it is never possible? You can change it in the BIOS. No way to change it from the operating system. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote: > On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote: > > $ cat /sys/kernel/debug/dri/0/i915_gem_stolen > > Stolen: > >8b55bf17e080:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 1) (ggtt offset: 00083000, size: 4000, type: 0) (stolen: > > 1000) > >8b55c2693040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 1) (ggtt offset: 02b9f000, size: 4000, type: 0) (stolen: > > 5000) > >8b55bf9a7300:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 0) (ggtt offset: 0f6b4000, size: 4000, type: 0) (stolen: > > 9000) > >8b55a6161040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 0) (ggtt offset: 0937f000, size: 4000, type: 0) (stolen: > > d000) > >8b5563e0dac0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 0) (ggtt offset: 0f714000, size: 4000, type: 0) (stolen: > > 00019000) > >8b55bf17e800:g 4KiB 41 00 [ 0 0 0 0 ] 0 LLC (pinned x > > 1) (ggtt offset: e000, size: 1000, type: 0) (stolen: 0012c000) > >8b55bf02d540:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 1) (ggtt offset: 00141000, size: 4000, type: 0) (stolen: > > 0012d000) > >8b55c2989340:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 1) (ggtt offset: 00148000, size: 4000, type: 0) (stolen: > > 00131000) > >8b55c29890c0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 1) (ggtt offset: 0014f000, size: 4000, type: 0) (stolen: > > 00135000) > >8b55c2989840:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 1) (ggtt offset: 00156000, size: 4000, type: 0) (stolen: > > 00139000) > >8b55bf02da40: p g 14400KiB 77 00 [ 0 0 0 0 ] 0 uncached dirty > > (name: 1) (pinned x 1) (display) (ggtt offset: 0015a000, size: 00e1, > > type: 0) (stolen: 0013d000) (p mappable) > >8b556dfba780:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty > > (pinned x 0) (ggtt offset: 0ad2a000, size: 4000, type: 0) (stolen: > > 01655000) > > > > > likely you'll have the fbdev framebuffer taking up a sizeable chunk. > > > > Seems 14MB. > > > > > You could get some back by reducing fbdev depth to 16bpp, or even 8bpp, > > > but I'm not convinced the fbdev gamma LUT stuff really works currently > > > so you might end up with bogus colors in your vts with that. > > > > Ok, I could try it. Via fbset tool? > > Kernel command line. We don't allow resizing the fbdev fb once it's > created. Ok, will try. > > > > > > > > > > [0.00] Memory: 7972840K/8282704K available (6196K kernel code, > > > > 1159K rwdata, 2848K rodata, 1408K init, 688K bss, 309864K reserved, 0K > > > > cma-reserved) > > > > > > > > > The BIOS may or may not provide a knob to change the size > > > > > of the stolen memory. > > > > > > > > In BIOS Setup screen I have option to choose GPU memory and I set it to > > > > max 512MB. So this is not the right option... > > > > > > > > And why cannot kernel use some continuous check of RAM itself? > > > > > > Because the hardware won't allow it. > > > > So it can be done only once after reboot? Or only prior to booting kernel? > > Never. Never? Now I'm lost. Why then dmesg message instruct user to try set up it in BIOS if you say it is never possible? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote: > On Tuesday 13 February 2018 17:36:54 Ville Syrjälä wrote: > > On Tue, Feb 13, 2018 at 02:38:42PM +0100, Pali Rohár wrote: > > > On Tuesday 13 February 2018 15:27:26 Ville Syrjälä wrote: > > > > On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote: > > > > > On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote: > > > > > > Hi! I'm periodically getting following message in dmesg on Lenovo > > > > > > Thinkpad X1 Carbon 3rd generation: > > > > > > > > > > > > [drm] Reducing the compressed framebuffer size. This may lead to > > > > > > less power savings than a non-reduced-size. Try to increase stolen > > > > > > memory size if available in BIOS. > > > > > > > > > > > > In BIOS I already set GPU size to 512M, but this did not help. Also > > > > > > update to last BIOS version did not help. > > > > > > > > > > > > So why this message is periodically print in dmesg? And what can I > > > > > > do > > > > > > with this problem? > > > > > > > > > > > > And why cannot Linux kernel allocate itself more memory for GPU (if > > > > > > BIOS > > > > > > can/could do that)? Is not 512MB for GPU enough? > > > > > > > > > > And here is output from lspci, which clearly says that 512MB is > > > > > already > > > > > set for GPU: > > > > > > > > The PCI BAR size has nothing to do with the size of the stolen memory. > > > > The BAR just provides a window into the global GTT address space of the > > > > GPU. Stolen memory is a contiguous chunk of physical memory carved out > > > > by the BIOS. > > > > > > Ok, how could I detect how much memory was stolen? > > > > > > In dmesg I see following lines: > > > > > > [0.00] e820: BIOS-provided physical RAM map: > > > [0.00] BIOS-e820: [mem 0x-0x00057fff] > > > usable > > > [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] > > > reserved > > > [0.00] BIOS-e820: [mem 0x00059000-0x0008bfff] > > > usable > > > [0.00] BIOS-e820: [mem 0x0008c000-0x0009] > > > reserved > > > [0.00] BIOS-e820: [mem 0x000e-0x000f] > > > reserved > > > [0.00] BIOS-e820: [mem 0x0010-0xab908fff] > > > usable > > > [0.00] BIOS-e820: [mem 0xab909000-0xabb08fff] > > > type 20 > > > [0.00] BIOS-e820: [mem 0xabb09000-0xacbfefff] > > > reserved > > > [0.00] BIOS-e820: [mem 0xacbff000-0xacd7efff] > > > ACPI NVS > > > [0.00] BIOS-e820: [mem 0xacd7f000-0xacdfefff] > > > ACPI data > > > [0.00] BIOS-e820: [mem 0xacdff000-0xacdf] > > > usable > > > [0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] > > > reserved > > > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] > > > reserved > > > [0.00] BIOS-e820: [mem 0x0001-0x00024dff] > > > usable > > > > > > [0.00] Reserving Intel graphics memory at > > > 0xae00-0xafff > > > > That's the one. Since you have a BDW the amount FBC can actually use > > will be 8MiB less than what's reported here. So looks like you should > > have 24MiB total, minus whatever else we end up allocating from stolen. > > > > Check /sys/kernel/debug/dri/0/i915_gem_stolen to see what's there. Most > > $ cat /sys/kernel/debug/dri/0/i915_gem_stolen > Stolen: >8b55bf17e080:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 1) (ggtt offset: 00083000, size: 4000, type: 0) (stolen: 1000) >8b55c2693040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 1) (ggtt offset: 02b9f000, size: 4000, type: 0) (stolen: 5000) >8b55bf9a7300:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 0) (ggtt offset: 0f6b4000, size: 4000, type: 0) (stolen: 9000) >8b55a6161040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 0) (ggtt offset: 0937f000, size: 4000, type: 0) (stolen: d000) >8b5563e0dac0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 0) (ggtt offset: 0f714000, size: 4000, type: 0) (stolen: 00019000) >8b55bf17e800:g 4KiB 41 00 [ 0 0 0 0 ] 0 LLC (pinned x 1) > (ggtt offset: e000, size: 1000, type: 0) (stolen: 0012c000) >8b55bf02d540:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 1) (ggtt offset: 00141000, size: 4000, type: 0) (stolen: 0012d000) >8b55c2989340:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 1) (ggtt offset: 00148000, size: 4000, type: 0) (stolen: 00131000) >8b55c29890c0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 1) (ggtt offset: 0014f000, size: 4000, type: 0) (stolen: 00135000) >8b55c2989840:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned > x 1) (ggtt
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tuesday 13 February 2018 17:36:54 Ville Syrjälä wrote: > On Tue, Feb 13, 2018 at 02:38:42PM +0100, Pali Rohár wrote: > > On Tuesday 13 February 2018 15:27:26 Ville Syrjälä wrote: > > > On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote: > > > > On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote: > > > > > Hi! I'm periodically getting following message in dmesg on Lenovo > > > > > Thinkpad X1 Carbon 3rd generation: > > > > > > > > > > [drm] Reducing the compressed framebuffer size. This may lead to less > > > > > power savings than a non-reduced-size. Try to increase stolen memory > > > > > size if available in BIOS. > > > > > > > > > > In BIOS I already set GPU size to 512M, but this did not help. Also > > > > > update to last BIOS version did not help. > > > > > > > > > > So why this message is periodically print in dmesg? And what can I do > > > > > with this problem? > > > > > > > > > > And why cannot Linux kernel allocate itself more memory for GPU (if > > > > > BIOS > > > > > can/could do that)? Is not 512MB for GPU enough? > > > > > > > > And here is output from lspci, which clearly says that 512MB is already > > > > set for GPU: > > > > > > The PCI BAR size has nothing to do with the size of the stolen memory. > > > The BAR just provides a window into the global GTT address space of the > > > GPU. Stolen memory is a contiguous chunk of physical memory carved out > > > by the BIOS. > > > > Ok, how could I detect how much memory was stolen? > > > > In dmesg I see following lines: > > > > [0.00] e820: BIOS-provided physical RAM map: > > [0.00] BIOS-e820: [mem 0x-0x00057fff] usable > > [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] > > reserved > > [0.00] BIOS-e820: [mem 0x00059000-0x0008bfff] usable > > [0.00] BIOS-e820: [mem 0x0008c000-0x0009] > > reserved > > [0.00] BIOS-e820: [mem 0x000e-0x000f] > > reserved > > [0.00] BIOS-e820: [mem 0x0010-0xab908fff] usable > > [0.00] BIOS-e820: [mem 0xab909000-0xabb08fff] type > > 20 > > [0.00] BIOS-e820: [mem 0xabb09000-0xacbfefff] > > reserved > > [0.00] BIOS-e820: [mem 0xacbff000-0xacd7efff] ACPI > > NVS > > [0.00] BIOS-e820: [mem 0xacd7f000-0xacdfefff] ACPI > > data > > [0.00] BIOS-e820: [mem 0xacdff000-0xacdf] usable > > [0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] > > reserved > > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] > > reserved > > [0.00] BIOS-e820: [mem 0x0001-0x00024dff] usable > > > > [0.00] Reserving Intel graphics memory at > > 0xae00-0xafff > > That's the one. Since you have a BDW the amount FBC can actually use > will be 8MiB less than what's reported here. So looks like you should > have 24MiB total, minus whatever else we end up allocating from stolen. > > Check /sys/kernel/debug/dri/0/i915_gem_stolen to see what's there. Most $ cat /sys/kernel/debug/dri/0/i915_gem_stolen Stolen: 8b55bf17e080:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00083000, size: 4000, type: 0) (stolen: 1000) 8b55c2693040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 02b9f000, size: 4000, type: 0) (stolen: 5000) 8b55bf9a7300:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 0) (ggtt offset: 0f6b4000, size: 4000, type: 0) (stolen: 9000) 8b55a6161040:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 0) (ggtt offset: 0937f000, size: 4000, type: 0) (stolen: d000) 8b5563e0dac0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 0) (ggtt offset: 0f714000, size: 4000, type: 0) (stolen: 00019000) 8b55bf17e800:g 4KiB 41 00 [ 0 0 0 0 ] 0 LLC (pinned x 1) (ggtt offset: e000, size: 1000, type: 0) (stolen: 0012c000) 8b55bf02d540:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00141000, size: 4000, type: 0) (stolen: 0012d000) 8b55c2989340:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00148000, size: 4000, type: 0) (stolen: 00131000) 8b55c29890c0:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 0014f000, size: 4000, type: 0) (stolen: 00135000) 8b55c2989840:g16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00156000, size: 4000, type: 0) (stolen: 00139000) 8b55bf02da40: p g 14400KiB 77 00 [ 0 0 0 0 ] 0 uncached dirty (name: 1) (pinned x 1) (display) (ggtt offset: 0015a000, size: 00e1, type: 0) (stolen: 0013d000) (p mappable) 8b556dfba780:g16KiB 40 40
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tue, Feb 13, 2018 at 02:38:42PM +0100, Pali Rohár wrote: > On Tuesday 13 February 2018 15:27:26 Ville Syrjälä wrote: > > On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote: > > > On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote: > > > > Hi! I'm periodically getting following message in dmesg on Lenovo > > > > Thinkpad X1 Carbon 3rd generation: > > > > > > > > [drm] Reducing the compressed framebuffer size. This may lead to less > > > > power savings than a non-reduced-size. Try to increase stolen memory > > > > size if available in BIOS. > > > > > > > > In BIOS I already set GPU size to 512M, but this did not help. Also > > > > update to last BIOS version did not help. > > > > > > > > So why this message is periodically print in dmesg? And what can I do > > > > with this problem? > > > > > > > > And why cannot Linux kernel allocate itself more memory for GPU (if BIOS > > > > can/could do that)? Is not 512MB for GPU enough? > > > > > > And here is output from lspci, which clearly says that 512MB is already > > > set for GPU: > > > > The PCI BAR size has nothing to do with the size of the stolen memory. > > The BAR just provides a window into the global GTT address space of the > > GPU. Stolen memory is a contiguous chunk of physical memory carved out > > by the BIOS. > > Ok, how could I detect how much memory was stolen? > > In dmesg I see following lines: > > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x00057fff] usable > [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved > [0.00] BIOS-e820: [mem 0x00059000-0x0008bfff] usable > [0.00] BIOS-e820: [mem 0x0008c000-0x0009] reserved > [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved > [0.00] BIOS-e820: [mem 0x0010-0xab908fff] usable > [0.00] BIOS-e820: [mem 0xab909000-0xabb08fff] type 20 > [0.00] BIOS-e820: [mem 0xabb09000-0xacbfefff] reserved > [0.00] BIOS-e820: [mem 0xacbff000-0xacd7efff] ACPI NVS > [0.00] BIOS-e820: [mem 0xacd7f000-0xacdfefff] ACPI > data > [0.00] BIOS-e820: [mem 0xacdff000-0xacdf] usable > [0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved > [0.00] BIOS-e820: [mem 0x0001-0x00024dff] usable > > [0.00] Reserving Intel graphics memory at > 0xae00-0xafff That's the one. Since you have a BDW the amount FBC can actually use will be 8MiB less than what's reported here. So looks like you should have 24MiB total, minus whatever else we end up allocating from stolen. Check /sys/kernel/debug/dri/0/i915_gem_stolen to see what's there. Most likely you'll have the fbdev framebuffer taking up a sizeable chunk. You could get some back by reducing fbdev depth to 16bpp, or even 8bpp, but I'm not convinced the fbdev gamma LUT stuff really works currently so you might end up with bogus colors in your vts with that. > > [0.00] Memory: 7972840K/8282704K available (6196K kernel code, 1159K > rwdata, 2848K rodata, 1408K init, 688K bss, 309864K reserved, 0K cma-reserved) > > > The BIOS may or may not provide a knob to change the size > > of the stolen memory. > > In BIOS Setup screen I have option to choose GPU memory and I set it to > max 512MB. So this is not the right option... > > And why cannot kernel use some continuous check of RAM itself? Because the hardware won't allow it. > > > > > > > $ lspci -v -s 00:02.0 > > > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 > > > (rev 09) (prog-if 00 [VGA controller]) > > > Subsystem: Lenovo HD Graphics 5500 > > > Flags: bus master, fast devsel, latency 0, IRQ 46 > > > Memory at e000 (64-bit, non-prefetchable) [size=16M] > > > Memory at c000 (64-bit, prefetchable) [size=512M] > > > I/O ports at 3000 [size=64] > > > [virtual] Expansion ROM at 000c [disabled] [size=128K] > > > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > > > Capabilities: [d0] Power Management version 2 > > > Capabilities: [a4] PCI Advanced Features > > > Kernel driver in use: i915 > > > Kernel modules: i915 > > > > > > -- > > > Pali Rohár > > > pali.ro...@gmail.com > > > ___ > > > dri-devel mailing list > > > dri-de...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Pali Rohár > pali.ro...@gmail.com -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tuesday 13 February 2018 15:27:26 Ville Syrjälä wrote: > On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote: > > On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote: > > > Hi! I'm periodically getting following message in dmesg on Lenovo > > > Thinkpad X1 Carbon 3rd generation: > > > > > > [drm] Reducing the compressed framebuffer size. This may lead to less > > > power savings than a non-reduced-size. Try to increase stolen memory size > > > if available in BIOS. > > > > > > In BIOS I already set GPU size to 512M, but this did not help. Also > > > update to last BIOS version did not help. > > > > > > So why this message is periodically print in dmesg? And what can I do > > > with this problem? > > > > > > And why cannot Linux kernel allocate itself more memory for GPU (if BIOS > > > can/could do that)? Is not 512MB for GPU enough? > > > > And here is output from lspci, which clearly says that 512MB is already > > set for GPU: > > The PCI BAR size has nothing to do with the size of the stolen memory. > The BAR just provides a window into the global GTT address space of the > GPU. Stolen memory is a contiguous chunk of physical memory carved out > by the BIOS. Ok, how could I detect how much memory was stolen? In dmesg I see following lines: [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0008bfff] usable [0.00] BIOS-e820: [mem 0x0008c000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xab908fff] usable [0.00] BIOS-e820: [mem 0xab909000-0xabb08fff] type 20 [0.00] BIOS-e820: [mem 0xabb09000-0xacbfefff] reserved [0.00] BIOS-e820: [mem 0xacbff000-0xacd7efff] ACPI NVS [0.00] BIOS-e820: [mem 0xacd7f000-0xacdfefff] ACPI data [0.00] BIOS-e820: [mem 0xacdff000-0xacdf] usable [0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0x0001-0x00024dff] usable [0.00] Reserving Intel graphics memory at 0xae00-0xafff [0.00] Memory: 7972840K/8282704K available (6196K kernel code, 1159K rwdata, 2848K rodata, 1408K init, 688K bss, 309864K reserved, 0K cma-reserved) > The BIOS may or may not provide a knob to change the size > of the stolen memory. In BIOS Setup screen I have option to choose GPU memory and I set it to max 512MB. So this is not the right option... And why cannot kernel use some continuous check of RAM itself? > > > > $ lspci -v -s 00:02.0 > > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev > > 09) (prog-if 00 [VGA controller]) > > Subsystem: Lenovo HD Graphics 5500 > > Flags: bus master, fast devsel, latency 0, IRQ 46 > > Memory at e000 (64-bit, non-prefetchable) [size=16M] > > Memory at c000 (64-bit, prefetchable) [size=512M] > > I/O ports at 3000 [size=64] > > [virtual] Expansion ROM at 000c [disabled] [size=128K] > > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > > Capabilities: [d0] Power Management version 2 > > Capabilities: [a4] PCI Advanced Features > > Kernel driver in use: i915 > > Kernel modules: i915 > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Pali Rohár pali.ro...@gmail.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote: > On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote: > > Hi! I'm periodically getting following message in dmesg on Lenovo > > Thinkpad X1 Carbon 3rd generation: > > > > [drm] Reducing the compressed framebuffer size. This may lead to less power > > savings than a non-reduced-size. Try to increase stolen memory size if > > available in BIOS. > > > > In BIOS I already set GPU size to 512M, but this did not help. Also > > update to last BIOS version did not help. > > > > So why this message is periodically print in dmesg? And what can I do > > with this problem? > > > > And why cannot Linux kernel allocate itself more memory for GPU (if BIOS > > can/could do that)? Is not 512MB for GPU enough? > > And here is output from lspci, which clearly says that 512MB is already > set for GPU: The PCI BAR size has nothing to do with the size of the stolen memory. The BAR just provides a window into the global GTT address space of the GPU. Stolen memory is a contiguous chunk of physical memory carved out by the BIOS. The BIOS may or may not provide a knob to change the size of the stolen memory. > > $ lspci -v -s 00:02.0 > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev > 09) (prog-if 00 [VGA controller]) > Subsystem: Lenovo HD Graphics 5500 > Flags: bus master, fast devsel, latency 0, IRQ 46 > Memory at e000 (64-bit, non-prefetchable) [size=16M] > Memory at c000 (64-bit, prefetchable) [size=512M] > I/O ports at 3000 [size=64] > [virtual] Expansion ROM at 000c [disabled] [size=128K] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Capabilities: [d0] Power Management version 2 > Capabilities: [a4] PCI Advanced Features > Kernel driver in use: i915 > Kernel modules: i915 > > -- > Pali Rohár > pali.ro...@gmail.com > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote: > Hi! I'm periodically getting following message in dmesg on Lenovo > Thinkpad X1 Carbon 3rd generation: > > [drm] Reducing the compressed framebuffer size. This may lead to less power > savings than a non-reduced-size. Try to increase stolen memory size if > available in BIOS. > > In BIOS I already set GPU size to 512M, but this did not help. Also > update to last BIOS version did not help. > > So why this message is periodically print in dmesg? And what can I do > with this problem? > > And why cannot Linux kernel allocate itself more memory for GPU (if BIOS > can/could do that)? Is not 512MB for GPU enough? And here is output from lspci, which clearly says that 512MB is already set for GPU: $ lspci -v -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 5500 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at e000 (64-bit, non-prefetchable) [size=16M] Memory at c000 (64-bit, prefetchable) [size=512M] I/O ports at 3000 [size=64] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915 -- Pali Rohár pali.ro...@gmail.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
Hi! I'm periodically getting following message in dmesg on Lenovo Thinkpad X1 Carbon 3rd generation: [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. In BIOS I already set GPU size to 512M, but this did not help. Also update to last BIOS version did not help. So why this message is periodically print in dmesg? And what can I do with this problem? And why cannot Linux kernel allocate itself more memory for GPU (if BIOS can/could do that)? Is not 512MB for GPU enough? -- Pali Rohár pali.ro...@gmail.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
