Who wants 252MB more RAM for PS3 homebrew.

[mbf]

Where did you get that information from? All we know is that the kernel makes an hypervisor call to transfer its FB (in XDR) to GPU VRAM.
I bet it's done using the MFC DMA from the Cell.

Now that you mention it, I'm not sure where I've seen this. Well, it should be fairly easy to test by disabling the kernel blit on vsync and run manual blits as fast as possible (no need to draw anything). If the speed is over 4GB/s, then it's definitely the GPU doing the blitting.

[ldesnogu]

Well, it should be fairly easy to test by disabling the kernel blit on vsync and run manual blits as fast as possible (no need to draw anything). If the speed is over 4GB/s, then it's definitely the GPU doing the blitting.

Though that'd be interesting to measure, I fail to see that it would prove who initiates the blit: you will be measuring XDR->VRAM copy, and this is probably symmetrical :)

However if the speed is very different from what StrontiumDog wants to measure (with the added need to stop kernel FB blitting to prevent bus contention), then that would be a hint.

[ps2devman]

Yes, "local memory"="VRAM".
It has been confirmed by a professional developer (he works for EA and has Sony SDK). He sometimes gives his opinion but he nevers breaks the NDA...

About bitblt, it's so easy to ask GPU to do the bitblt that it's a good assumption. However maybe it doesn't matter who does it. It's really just a dma access that copies pixel lines (pitch -i.e, gap between a line and following one- is correctly handled though when GPU does it).

When you have access to GPU registers (best way is to access it through FIFO mechanism, which is a kind of DMA access controlled by GPU too where you just 'push' commands in a queue in ram and GPU dequeues them automatically thru DMA)

For nv2A, it's done this way (extract from pbKit demo04 graphics.c):

Code: Select all

void image_bitblt(void)
{
	int	BytesPerPixel=4;
	DWORD	EncodedBpp=0xa;
	DWORD	SrcPitch,DstPitch;
	DWORD	SrcAddr,DstAddr;
	DWORD	sx,sy,dx,dy,h,w;
	DWORD	*p;
	
	SrcPitch=DstPitch=pb_back_buffer_pitch();
	SrcAddr=(DWORD)pb_extra_buffer(0);
	DstAddr=0; //dest_addr-base_dma_addr (base_dma_addr=last targetted buffer addr)
	
	sx=sy=dx=dy=0;
	w=pb_back_buffer_width();
	h=pb_back_buffer_height();
	
	switch(BytesPerPixel)
	{
		case 1:
			EncodedBpp=1;
			break;
		case 2:
			EncodedBpp=4;
			break;
		case 4:
			EncodedBpp=0xa;
			break;
	}

	p=pb_begin();
	pb_push4to(	SUBCH_4,
			p,			
			NV_IMAGE_BLIT_POINT_IN,
			EncodedBpp,
			&#40;DstPitch<<16&#41;|&#40;SrcPitch&0xffff&#41;,
			SrcAddr,
			DstAddr	&#41;;
	p+=5;
	pb_end&#40;p&#41;;

	p=pb_begin&#40;&#41;;
	pb_push3to&#40;	SUBCH_3,
			p,			
			NV_IMAGE_BLIT_POINT_IN,
			&#40;sx&0xffff&#41;|&#40;sy<<16&#41;,
			&#40;dx&0xffff&#41;|&#40;dy<<16&#41;,
			&#40;w&0xffff&#41;|&#40;h<<16&#41;	&#41;;
	p+=4;
	pb_end&#40;p&#41;;
&#125;

So, it's so simple to code that I would bet hypervisor takes advantages of all 'easy to use' RSX services.

Most constants come from "Nouveau" project nv_objects.h (see wiki)
(good thing is many nv40 constants are in there too)

[ralferoo]

For nv2A, it's done this way (extract from pbKit demo04 graphics.c):
...
(sx&0xffff)|(sy<<16),

That to me is sufficient to make me thing that the GPU is doing the work. I've been wondering why in http://wiki.ps2dev.org/ps3:hypervisor:l ... te:fb_blit we have "(xres << 16) | yres", when for both PPU and SPU it'd be easier just to use two variables. If it's passed directly to the GPU, that'd make a lot of sense.

[rapso]

It has been confirmed by a professional developer (he works for EA and has Sony SDK). He sometimes gives his opinion but he nevers breaks the NDA...

confirming confidential naming conventions is already breaking the NDA ;)

About bitblt, it's so easy to ask GPU to do the bitblt that it's a good assumption. However maybe it doesn't matter who does it. It's really just a dma access that copies pixel lines (pitch -i.e, gap between a line and following one- is correctly handled though when GPU does it).

maybe the rsx can do some swizzling or color conersions during blitting for free. it's just a guess.

[ralferoo]

It's really just a dma access that copies pixel lines (pitch -i.e, gap between a line and following one- is correctly handled though when GPU does it).

Hmmm. IMHO it doesn't handle non-full screen modes very well at all. It starts the blit at the top-left of the drawable range but still blits a full screen worth of data.

In effect, if you write to the FB as if it was full screen (i.e. ignoring xoff_res and yoff_res), so you also get a chunk from the RHS of the left and the bottom of frame 0 is at the top of the screen on frame 1. So, basically if you use the normal modes the app has to honour the reserver space limits and you're stuck with stupidly over-cautious overscan compensation or you use the full screen modes and possibly loose some text due to overscan.

I'm also a bit concerned that if the blit extends past the end of frame 0 onto the top of frame 1, then the bottom of frame 1 also is blitted past the end of the memory allocated to it. Perhaps this is why 18Mb is reserved rather than the needed amount! (even triple buffered, it should only need 15Mb)

[mbf]

Perhaps this is why 18Mb is reserved rather than the needed amount! (even triple buffered, it should only need 15Mb)

Correct me if I'm wrong but the memory required for one frame is: width*height*bytes_per_pixel. So in 1080p, that's 1920*1080*4 = 8294400 (7.9MB). If I remember correctly, the memory allocated by the kernel is 9000000 bytes (8.6MB) times two. So yes, the kernel is allocating a wee bit too much memory, but still far from enough to do triple buffering.

And yes, the overscan compensation is overly conservative and plain sucks on an LCD display :( I can't check right now, but I believe there's some constants in the ps3fb sources for that.... it shouldn't be that hard to be able to make it fully tunable with ps3videomode.

[urchin]

Browsing the code, it appears to be (9 x 2 + 1) * 1024 * 1024. The extra meg is used for 1MB alignment required by the GPU.

[ralferoo]

in 1080p, that's 1920*1080*4 = 8294400 (7.9MB).

I think I need to start engaging brain before posting. For some reason, I'd calculated 1280x1024*4, thought "Exactly 5Mb, strange I didn't think it was such a round number. Oh well, I'll post it anyway..."

[thalamus]

Hi Guys,

I've got the ps3vram.c driver integrated with the normal kernel build process, so you can use it even without loadable module support.
Here's how :-

cp ps3vram.c to /usr/src/ps3-linux/drivers/mtd
vi /usr/src/ps3-linux/drivers/mtd/Kconfig
add the following, after "CONFIG FTL" section

config PS3VRAM
tristate "PS3 VRAM Block Device"
depends on BLOCK
help
uses PS3 VRAM as a block device - ideal for swap

save Kconfig

vi /usr/src/ps3-linux/drivers/mtd/Makefile
add this line
obj-$(CONFIG_PS3VRAM) += ps3vram.o
after the CONFIG_FTL line
save Makefile

cd ../..
make menuconfig
select device drivers
enable MTD and select to open MTD options
enable "caching block access"
enable "ps3 vram block device"
exit menuconfig

make
install kernel to /boot

if after reboot, /dev/mtdblock0 does not exist, then do
mknod /dev/mtdblock/0 b 31 0

now edit /etc/fstab, comment out the current swap partition and add the line :-
/dev/mtdblock0 none swap sw 0 0

On reboot you'll have 241840k of swap in the PS3's Vram.

Meanwhile - has anyone got any further with making a DMA version of the PS3VRAM driver? The extra speed would be really handy.

[jimparis]

now edit /etc/fstab, comment out the current swap partition and add the line :-
/dev/mtdblock0 none swap sw 0 0

On reboot you'll have 241840k of swap in the PS3's Vram.

Don't forget that you'll need to run mkswap on the device every time you reboot. (Maybe some distros do that automatically, but mine don't).

[thalamus]

Good point.

To get around this, add a startup script to /etc/init.d named "swapon", like the one below.

#!/bin/sh
/sbin/mkswap /dev/mtdblock0
/sbin/swapon -p 10 /dev/mtdblock0

then link that script into the end of runlevel2

ln -s /etc/init.d/swapon /etc/rc2.d/S99swapon

[ps2devman]

nice!

[StrontiumDog]

config PS3VRAM
tristate "PS3 VRAM Block Device"
depends on BLOCK
help
uses PS3 VRAM as a block device - ideal for swap

Shouldn't that be:
config PS3VRAM
tristate "PS3 VRAM Block Device"
depends on MTD
help
uses PS3 VRAM as a block device - ideal for swap

???

It depends on MTD, not BLOCK, no?

Meanwhile - has anyone got any further with making a DMA version of the PS3VRAM driver? The extra speed would be really handy.

A person going by the name parabelboi has put a change to the wiki, suggesting that changing:

ddr_address = ioremap(ddr_lpar, ddr_size);
to
ddr_address = ioremap_flags(ddr_lpar, ddr_size, _PAGE_NO_CACHE);

results in a performance improvement. I don't know by how much, or how he came to this, because that function exists in the kernel, but nothing uses it that I could find.

Its worth a try. I would be interested to know if it does speed up access and if so, by what sort of margin.

Otherwise, write could be sped up by using:

status = lv1_gpu_context_attribute(ps3fb.context_handle,
L1GPU_CONTEXT_ATTRIBUTE_FB_BLIT,
offset, fb_ioif,
(xres << 16) | yres,
xres * BPP);

Except the exact values needed for offset and fb_ioif for an arbitrary block copy from kernel memory to video memory are yet to be deciphered. The values used in the ps3fb driver are far from obvious. For example neither offset nor fb_ioif seem to point to the virtual frame buffer.

There is no DMA facility to speed up reading that I am aware of. (Unless SPU DMA to/from video memory is significantly faster than PPU direct access which currently is unknown.)

StrontiumDog

[ldesnogu]

A person going by the name parabelboi has put a change to the wiki, suggesting that changing:

ddr_address = ioremap(ddr_lpar, ddr_size);
to
ddr_address = ioremap_flags(ddr_lpar, ddr_size, _PAGE_NO_CACHE);

results in a performance improvement. I don't know by how much, or how he came to this, because that function exists in the kernel, but nothing uses it that I could find.

Its worth a try. I would be interested to know if it does speed up access and if so, by what sort of margin.

If you look at arch/powerpc/mm/pgtable_32.c you will find this:

Code: Select all

144 void __iomem *
145 ioremap(phys_addr_t addr, unsigned long size)
146 {
147         return __ioremap(addr, size, _PAGE_NO_CACHE);
148 }
149 EXPORT_SYMBOL(ioremap);
150
151 void __iomem *
152 ioremap_flags(phys_addr_t addr, unsigned long size, unsigned long flags)
153 {
154         return __ioremap(addr, size, flags);
155 }
156 EXPORT_SYMBOL(ioremap_flags);

So no change here ;)

However in arch/powerpc/mm/pgtable_64.c

Code: Select all

172 void __iomem * ioremap(phys_addr_t addr, unsigned long size)
173 {
174         unsigned long flags = _PAGE_NO_CACHE | _PAGE_GUARDED;
175
176         if (ppc_md.ioremap)
177                 return ppc_md.ioremap(addr, size, flags);
178         return __ioremap(addr, size, flags);
179 }
180
181 void __iomem * ioremap_flags(phys_addr_t addr, unsigned long size,
182                              unsigned long flags)
183 {
184         if (ppc_md.ioremap)
185                 return ppc_md.ioremap(addr, size, flags);
186         return __ioremap(addr, size, flags);
187 }

Since ps3 linux kernel is 64 bit, then there is indeed a difference in that we don't supply _PAGE_GUARDED anymore, which should give a small speedup as it will allow out-of-order accesses (ref PowerPC Manual vol 3 section 4.2.4).

I would be very interested to know if this brings any speed-up (I doubt it will be significant but who knows without testing? :))

[thalamus]

>> depends on MTD
>>
Yep you're right. I've tested that change and it works.

>>_PAGE_NO_CACHE
>>
I just gave that a try by adding this line to ps3vram.c :-
#include <asm/pgtable-ppc64.h>

and modding this line
priv->base = priv->real_base = ioremap(ddr_lpar, ddr_size)
to this
priv->base = priv->real_base = ioremap_flags(ddr_lpar, ddr_size, _PAGE_NO_CACHE)

I then ran a bunch of iozone tests on the ps3 hard disk, then the original ps3vram driver, then on the modded NO_CACHE driver.

The test shown below was run 3 times on each device.
iozone -i 0 -i 1 -s 131072 -r 1024

PS3DA
KB reclen write rewrite read reread
131072 1024 26668 27536 25457 25628
131072 1024 26916 26477 25353 25716
131072 1024 27233 26499 25724 25717


PS3VRAM WithCache
KB reclen write rewrite read reread
131072 1024 15692 20137 10409 10524
131072 1024 15861 20887 10297 10320
131072 1024 16851 22698 10295 10306


PS3VRAM NoCache
KB reclen write rewrite read reread
131072 1024 9533 13649 10127 9468
131072 1024 10136 13900 9934 8437
131072 1024 9394 12211 9895 10050

Firstly ps3vram is slower than disk. Not great.
Secondly, _PAGE_NO_CACHE is slower still. Really not great.

I would still expect an advantage from using the original ps3vram driver as the tests above don't take into account the looong seek times created on a physical disk while it's thrashing around under load.

That said I'm still feeling a bit glum looking at those results.

If any more info on blits/DMA turns up, do let me know.

[ralferoo]

Firstly ps3vram is slower than disk. Not great.
Secondly, _PAGE_NO_CACHE is slower still. Really not great.
...
That said I'm still feeling a bit glum looking at those results.

Don't be - it's still useful work.

For instance, the Ubuntu installer doesn't work properly because it runs out of memory (why my system is an Ubuntu hybrid done by booting from the installation disk, making partions manually, adding the swap partition and debootstrap'ing into them). Anything that can make that process smoother will be good for people, especially given how poor performance is running from a live CD.

Secondly, I'm planning a live-CD image of my games library as a kind of runtime package and this swap disk will be very useful for that as I can't guarantee that people have swap space available on disk. Most of the time, I expect everything to be able to live in main memory, but a chunk of swap would be a very useful safety net.

So, if you see it solving a different problem, it does that perfectly.

I'm still holding out for being able to use it for sprites/textures and having the GPU blit things for me... :)

[Glaurung]

Hi,

I've been working on improving the existing ps3vram driver with our recent RSX discoveries. Basically it is possible to ask the RSX to perform DMA XDR system memory to DDR video memory and vice versa. Using DMA is _much_ faster than accessing the ioremapped video memory directly. However relatively large regions of memory have to be transfered for it to be efficient. Also it requires physically contiguous pages.

So I changed the ps3vram driver to allocate a 2MB contiguous XDR buffer for use as bounce buffer area and FIFO area. This buffer is split in pages of 128kB and a simple caching system is used to minimize transfers between XDR and DDR. The read and write operations were changed to check the cache first and trigger a page upload/download if needed. Both read and write performance is much improved (100-150MB/s) compared to direct access, although not stellar compared to the capabilities of the hardware (~20GB/s). I think one limitation is the mtdblock access by chuncks of 512 bytes only, reading/writing from mtd0 instead is about twice as fast.

The driver is still experimental, feel free to test if interested:
git clone http://mandos.homelinux.org/~glaurung/git/ps3vram.git/

Note: this _should_ work with FW >= 2.1, but I've not tested it (only 2.01). As for mixing this with other RSX fun such as 3D or Xorg, don't do it. These applications get exclusive access to RSX which would block ps3vram upload/download transfers.

[crossfader_killa]

Hi,

The driver is still experimental, feel free to test if interested:
git clone http://mandos.homelinux.org/~glaurung/git/ps3vram.git/

Note: this _should_ work with FW >= 2.1, but I've not tested it (only 2.01). As for mixing this with other RSX fun such as 3D or Xorg, don't do it. These applications get exclusive access to RSX which would block ps3vram upload/download transfers.

I am interested, but I don't even know what I m suppose to use from the directory you linked and also how am I suppose to implement those things to my PS3.

Thanks for helping me out with this.

[eddd]

Hi,

I've been working on improving the existing ps3vram driver with our recent RSX discoveries. Basically it is possible to ask the RSX to perform DMA XDR system memory to DDR video memory and vice versa. Using DMA is _much_ faster than accessing the ioremapped video memory directly. However relatively large regions of memory have to be transfered for it to be efficient. Also it requires physically contiguous pages.

So I changed the ps3vram driver to allocate a 2MB contiguous XDR buffer for use as bounce buffer area and FIFO area. This buffer is split in pages of 128kB and a simple caching system is used to minimize transfers between XDR and DDR. The read and write operations were changed to check the cache first and trigger a page upload/download if needed. Both read and write performance is much improved (100-150MB/s) compared to direct access, although not stellar compared to the capabilities of the hardware (~20GB/s). I think one limitation is the mtdblock access by chuncks of 512 bytes only, reading/writing from mtd0 instead is about twice as fast.

The driver is still experimental, feel free to test if interested:
git clone http://mandos.homelinux.org/~glaurung/git/ps3vram.git/

Note: this _should_ work with FW >= 2.1, but I've not tested it (only 2.01). As for mixing this with other RSX fun such as 3D or Xorg, don't do it. These applications get exclusive access to RSX which would block ps3vram upload/download transfers.

Hi, when I try to load this module I get:

Code: Select all

[root@localhost ~]# modprobe ps3vram
FATAL: Error inserting ps3vram (/lib/modules/2.6.24-rc7-g5b09688b/extra/ps3vram.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Dmesg reports:

Code: Select all

ps3vram: Unknown symbol add_mtd_device
ps3vram: Unknown symbol del_mtd_device

When compiling I get this warning:

Code: Select all

WARNING: ".add_mtd_device" [/usr/src/ps3vram/ps3vram.ko] undefined!
WARNING: ".del_mtd_device" [/usr/src/ps3vram/ps3vram.ko] undefined!

Which makes sense... but why is this? These are defined in linux/mtd/mtd.h and I know that the compile is finding this header correctly (I added some garbage into the code which successfully broke the compile) so I know that's not the problem.

Any ideas where I'm going wrong? This is on firmware 2.10. Thanks in advance.

edit- since these are only called once each, I tried commenting them out (I have no idea what they do so this probably isn't a good idea), the module compiles fine and loads BUT I can't seem to identify any RAM improvements, which makes me think that they're probably important functions :)

[ralferoo]

Hi, when I try to load this module I get:

Code: Select all

[root@localhost ~]# modprobe ps3vram
FATAL: Error inserting ps3vram (/lib/modules/2.6.24-rc7-g5b09688b/extra/ps3vram.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Dmesg reports:

Code: Select all

ps3vram: Unknown symbol add_mtd_device
ps3vram: Unknown symbol del_mtd_device

When compiling I get this warning:

Code: Select all

WARNING: ".add_mtd_device" [/usr/src/ps3vram/ps3vram.ko] undefined!
WARNING: ".del_mtd_device" [/usr/src/ps3vram/ps3vram.ko] undefined!

Which makes sense... but why is this? These are defined in linux/mtd/mtd.h and I know that the compile is finding this header correctly (I added some garbage into the code which successfully broke the compile) so I know that's not the problem.

Any ideas where I'm going wrong? This is on firmware 2.10. Thanks in advance.

Try running

Code: Select all

uname -a

to make sure the random hex digits at the end of the kernel are the same as in your module. If not, it won't work. If you running kernel doesn't have hex digits at all, then you'll need to edit your .config so that your kernel modules also don't use this information.

Note that this system is designed so that you don't use modules that are incompatible with the kernel you use. You should only circumvent this system if you know the kernels are built with the same options.

[eddd]

Try running

Code: Select all

uname -a

to make sure the random hex digits at the end of the kernel are the same as in your module. If not, it won't work. If you running kernel doesn't have hex digits at all, then you'll need to edit your .config so that your kernel modules also don't use this information.

Note that this system is designed so that you don't use modules that are incompatible with the kernel you use. You should only circumvent this system if you know the kernels are built with the same options.

Yeah it's the same, thanks for the suggestion though. Any other ideas?

[jimparis]

Your kernel is missing CONFIG_MTD.

[eddd]

Your kernel is missing CONFIG_MTD.

That was it, thanks!

[hedele]

Hey there!

I tried to compile this driver using YDL 6.0 but got some mtd related errors. Turns out the YDL kernel doesn't have mtd support enabled.

I recompiled the kernel with CONFIG_MTD, did modprobe mtdblock and modprobe ps3vram, nothing happened and the following appeared in dmesg:

Code: Select all

ps3fb: mmap framebuffer P(1130000)->V(f6e18000)
ps3vram: lv1_gpu_memory_allocate failed

needless to say, it ain't working. What could cause that problem?
I'm running kernel 2.6.23-9.ydl6.1custom, on a 40GB PAL PS3 with Firmware 2.10

lsmod output:

Code: Select all

Module                  Size  Used by
ps3vram                19068  0
mtdblock               11920  0

Edit: I calculated the given Hex values of
ps3fb: mmap framebuffer P(1130000)->V(f6e18000)
, the difference corresponds to about 232 MB... why is ps3fb allocating all the vram when it should only be using ~18 MB? Also, this problem persists when using init 3, going single user mode without X.

[jimparis]

There was stuff changed in fw 2.10 and recent kernels regarding lv1_gpu_memory_allocate.. I'm not sure exactly but I seem to recall that ps3fb allocates more space by default now. You could try reducing the ddr_size in ps3vram.c (start with something small like 16MB).

[hedele]

ah well, off to recompile the kernel again...

... or not. Look at that:

Code: Select all

#define DDR_SIZE                                (0)     /* used no ddr */
#define GPU_OFFSET                              (64 * 1024)
#define GPU_IOIF                                (0x0d000000UL)

so, changing DDR_SIZE probably won't help, and that bunch of code kinda assures me in that.

Code: Select all

         status = lv1_gpu_memory_allocate(DDR_SIZE, 0, 0, 0, 0,
                                         &ps3fb.memory_handle, &ddr_lpar);
        if (status) {
                printk(KERN_ERR "%s: lv1_gpu_memory_allocate failed: %d\n",
                       __func__, status);
                goto err;
        }
        DPRINTK("ddr:lpar:0x%lx\n", ddr_lpar);

        status = lv1_gpu_context_allocate(ps3fb.memory_handle, 0,
                                          &ps3fb.context_handle,
                                          &lpar_dma_control, &lpar_driver_info,
                                          &lpar_reports, &lpar_reports_size);

I don't think there is anything that can be fixed by a simple change of a constant... any suggestions? thanks for sharing your ideas btw

[jimparis]

That's not what the code looks like anymore (I think DDR_SIZE=0 allocations don't even run on recent firmware). Check
http://git.kernel.org/?p=linux/kernel/g ... eo/ps3fb.c

[hedele]

Actually that code DOES run, since i recompiled my kernel a few times with the included .c (changed the overscan margins) - and on firmware 2.1 as well.

However, I'm going to replace the supplied ps3fb.c with the one you gave me and will give it a shot. thanks for the advice!

[hedele]

OK building this now over night... wish me luck :)

Edit: No that .c does not compile. Throws several errors. Since I guess you guys won't be able to make too much sense out of the german errors, I'll try to translate them.

Code: Select all

drivers/video/ps3fb.c:322: Error: Parameter 1 (»id«) has incomplete type
drivers/video/ps3fb.c: In Function »ps3fb_vmode«:
drivers/video/ps3fb.c:331: Error: »PS3AV_MODE_480I« not declared (first usage in this function)
drivers/video/ps3fb.c:331: Error: »PS3AV_MODE_WUXGA« not declared
drivers/video/ps3fb.c:334: Error: »PS3AV_MODE_1080P50« not declared
drivers/video/ps3fb.c:339: Error: type of formal parameter 1 is incomplete
drivers/video/ps3fb.c: In Function »ps3fb_find_mode«:

... same errors two times over

drivers/video/ps3fb.c:656: Error: too few arguments for function »ps3av_set_video_mode«
drivers/video/ps3fb.c: In function »ps3fb_ioctl«:
drivers/video/ps3fb.c:843: Errir: too few arguments for function »ps3av_get_auto_mode«
make[2]: *** [drivers/video/ps3fb.o] error 1
make[1]: *** [drivers/video] error 2
make: *** [drivers] error 2

Well, seems ps3fb.c in the git is somewhat broken :/

By the way i found out that there is a possibility to set the default framebuffer size in the kernel config, but that is already set to 18 MiB.