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: > > ffff8b55bf17e080: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00083000, size: 00004000, type: 0) (stolen: 00001000) > > ffff8b55c2693040: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 02b9f000, size: 00004000, type: 0) (stolen: 00005000) > > ffff8b55bf9a7300: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 0) (ggtt offset: 0f6b4000, size: 00004000, type: 0) (stolen: 00009000) > > ffff8b55a6161040: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 0) (ggtt offset: 0937f000, size: 00004000, type: 0) (stolen: 0000d000) > > ffff8b5563e0dac0: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 0) (ggtt offset: 0f714000, size: 00004000, type: 0) (stolen: 00019000) > > ffff8b55bf17e800: g 4KiB 41 00 [ 0 0 0 0 ] 0 LLC (pinned x 1) (ggtt offset: ffffe000, size: 00001000, type: 0) (stolen: 0012c000) > > ffff8b55bf02d540: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00141000, size: 00004000, type: 0) (stolen: 0012d000) > > ffff8b55c2989340: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00148000, size: 00004000, type: 0) (stolen: 00131000) > > ffff8b55c29890c0: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 0014f000, size: 00004000, type: 0) (stolen: 00135000) > > ffff8b55c2989840: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 1) (ggtt offset: 00156000, size: 00004000, type: 0) (stolen: 00139000) > > ffff8b55bf02da40: p g 14400KiB 77 00 [ 0 0 0 0 ] 0 uncached dirty (name: 1) (pinned x 1) (display) (ggtt offset: 0015a000, size: 00e10000, type: 0) (stolen: 0013d000) (p mappable) > > ffff8b556dfba780: g 16KiB 40 40 [ 0 0 0 0 ] 0 LLC dirty (pinned x 0) (ggtt offset: 0ad2a000, size: 00004000, 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.000000] 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.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
