Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2002-08-07 10:05:06
|
On 7 Aug 02 at 10:43, Jani Monoses wrote:
> On Tue, 6 Aug 2002 09:06:48 -0700 (PDT)
> James Simmons <cap...@ya...> wrote:
> > I push stuff. The next set of patches will break alot
> > of drivers but I need to do this to get people to port
> > there stuff over to the new api.
>
> Could you outline what the next set of patches will change?
> Thanks
I also hope that performance problems will be solved before we are
forced to not use putcs.
Petr Vandrovec
van...@vc...
|
|
From: Petr V. <VAN...@vc...> - 2002-08-08 18:25:35
|
On 8 Aug 02 at 11:16, James Simmons wrote:
> > I also hope that performance problems will be solved
> > before we are
> > forced to not use putcs.
>
> It will be :-) I need to one align the data. Second I
> plan to implement the patch recently posted here.
Patch still showed about 100% slowdown against 2.4.x, if I interpreted
yesterday's table correctly. It is better than 1000% slowdown, but still...
Petr
|
|
From: James S. <jsi...@in...> - 2002-08-08 18:38:28
|
> On 8 Aug 02 at 11:16, James Simmons wrote: > > > I also hope that performance problems will be solved > > > before we are > > > forced to not use putcs. > > > > It will be :-) I need to one align the data. Second I > > plan to implement the patch recently posted here. > > Patch still showed about 100% slowdown against 2.4.x, if I interpreted > yesterday's table correctly. It is better than 1000% slowdown, but still... I could believe a slow down of 2x but 1000 I don't think so. |
|
From: Petr V. <VAN...@vc...> - 2002-08-08 18:51:48
|
On 8 Aug 02 at 11:32, James Simmons wrote: > > On 8 Aug 02 at 11:16, James Simmons wrote: > > > > I also hope that performance problems will be solved > > > > before we are > > > > forced to not use putcs. > > > > > > It will be :-) I need to one align the data. Second I > > > plan to implement the patch recently posted here. > > > > Patch still showed about 100% slowdown against 2.4.x, if I interpreted > > yesterday's table correctly. It is better than 1000% slowdown, but still... > > I could believe a slow down of 2x but 1000 I don't think so. Message from Antonio Daplas (http://www.geocrawler.com/lists/3/SourceForge/9276/0/9249087/) says: 2.5 old (with offscreen buffers) 10.708 2.5 new 4.378 2.4 2.098 His first message (http://www.geocrawler.com/lists/3/SourceForge/9276/25/9237029/) listed 13.586 for old 2.5 code. So you are right, old code was not 1000% slowdown, only 500%. But main problem is not speed of old code, but speed of new code. And if numbers are right, new code is still 100% slower than 2.4.x code was. Petr Vandrovec |
|
From: Antonino D. <ad...@po...> - 2002-08-08 21:51:18
Attachments:
fb-opt.diff
|
On Fri, 2002-08-09 at 02:51, Petr Vandrovec wrote: > > Message from Antonio Daplas > (http://www.geocrawler.com/lists/3/SourceForge/9276/0/9249087/) > says: > 2.5 old (with offscreen buffers) 10.708 > 2.5 new 4.378 > 2.4 2.098 > > His first message > (http://www.geocrawler.com/lists/3/SourceForge/9276/25/9237029/) > listed 13.586 for old 2.5 code. > > So you are right, old code was not 1000% slowdown, only 500%. But main > problem is not speed of old code, but speed of new code. And if numbers > are right, new code is still 100% slower than 2.4.x code was. > Petr Vandrovec The numbers are correct. However I'm only talking about software drawing here. With a few more optimizations with the code, the scroll time was further cut down to 3.780s. Also, 16bpp and 32bpp is now faster in 2.5 than in 2.4, although 24bpp is still a bit slower because of problems of its weird alignmment. However, ALL hardware accelerated code is much faster than the old one, and will be much, much faster if hardware sync on demand is implemented. (I really want this James :) The extra processing of the font bitmap in putcs() outweighs the benefit of "bulk" writing the data in 8bpp, but becomes insignificant as we go to higher color depths, or as we take advantage of hardware acceleration. I'm attaching diffs for cfbimgblt.c, cfbfillrect.c, cfbcopyarea.c and fbcon-accel.c. This is against vanilla 2.5.27. fbcon-accel.c: process 4 characters at a time, if possible, to squeeze a few more CPU cycles cfbimgblt.c divided into fast_imageblit (for 8, 16, 32 bpp), slow_imageblit (24 bpp) and bitwise_imageblit (default). slow_imageblit involves packaging 4 pixels (or 8 if we have color depths > 32) which are written as double words (1 - 8bpp, 2 - 16bpp, 3 - 24bpp). cfbcopyarea.c uses fast_memmove and fb_memmove for 24 bpp. Anthing wrong with this fb string functions? I seem not to see any performance degradation by using them. cfbfillarea.c Similar concept as slow_imageblit, packages 4-pixels in 24 bpp that are written as 3 double words to the framebuffer. Also is the double word access alignment a strict or optional requirement? Any comments? Tony |
|
From: Holzrichter, B. <bru...@mo...> - 2002-08-09 18:19:36
|
> > http://fbdev.bkbits.net:8080/fbdev-2.5 > Closer, closer.... Here's an FYI. I haven't looked into it any further yet... B. make[3]: Entering directory `/home/bruce/sparctest/drivers/video/aty' sparc64-linux-gcc -Wp,-MD,./.atyfb_base.o.d -D__KERNEL__ -I/home/bruce/sparctest/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -nostdinc -iwithprefix include -DKBUILD_BASENAME=atyfb_base -c -o atyfb_base.o atyfb_base.c atyfb_base.c: In function `atyfb_ioctl': atyfb_base.c:1075: `info2' undeclared (first use in this function) atyfb_base.c:1075: (Each undeclared identifier is reported only once atyfb_base.c:1075: for each function it appears in.) atyfb_base.c:1070: warning: `disp' might be used uninitialized in this function atyfb_base.c: In function `atyfb_init': atyfb_base.c:2086: warning: assignment makes pointer from integer without a cast atyfb_base.c:2184: `defualt_par' undeclared (first use in this function) atyfb_base.c:2376: invalid operands to binary & make[3]: *** [atyfb_base.o] Error 1 make[3]: Leaving directory `/home/bruce/sparctest/drivers/video/aty' make[2]: *** [aty] Error 2 make[2]: Leaving directory `/home/bruce/sparctest/drivers/video' make[1]: *** [video] Error 2 make[1]: Leaving directory `/home/bruce/sparctest/drivers' make: *** [drivers] Error 2 |
|
From: James S. <jsi...@in...> - 2002-08-09 18:49:15
|
> > http://fbdev.bkbits.net:8080/fbdev-2.5 > > > > Closer, closer.... > > Here's an FYI. I haven't looked into it any further yet... Try it again. I pushed some fixes. |
|
From: Holzrichter, B. <bru...@mo...> - 2002-08-12 18:43:44
|
>
> Try it again. I pushed some fixes.
>
Here's a simple one liner fix, pretty self explanatory, if you haven't
caught it yet. ;o)
--- atyfb_base.c.old Mon Aug 12 11:34:44 2002
+++ atyfb_base.c Mon Aug 12 10:57:11 2002
@@ -2241,7 +2241,7 @@
aty_ld_le32(CRTC_H_TOTAL_DISP,
default_par);
crtc.h_sync_strt_wid =
aty_ld_le32(CRTC_H_SYNC_STRT_WID,
- defualt_par);
+ default_par);
crtc.v_tot_disp =
aty_ld_le32(CRTC_V_TOTAL_DISP,
default_par);
crtc.v_sync_strt_wid =
Now looking to track this one down. Haven't found it yet....
ld -m elf64_sparc -T arch/sparc64/vmlinux.lds arch/sparc64/kernel/head.o
arch/sparc64/kernel/init_task.o init/init.o --start-group
arch/sparc64/kernel/kernel.o arch/sparc64/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o security/built-in.o arch/sparc64/math-emu/math-emu.o
/home/bruce/sparctest/lib/lib.a lib/lib.a
/home/bruce/sparctest/arch/sparc64/prom/promlib.a
/home/bruce/sparctest/arch/sparc64/lib/lib.a drivers/built-in.o
sound/sound.o net/network.o --end-group -o vmlinux
drivers/built-in.o: In function `console_init':
drivers/built-in.o(.text.init+0xa78): undefined reference to
`uart_console_init'
make: *** [vmlinux] Error 1
B.
|
|
From: James S. <jsi...@in...> - 2002-08-13 06:21:58
|
> Here's a simple one liner fix, pretty self explanatory, if you haven't > caught it yet. ;o) Oops. Fixed now. > Now looking to track this one down. Haven't found it yet.... > > ld -m elf64_sparc -T arch/sparc64/vmlinux.lds arch/sparc64/kernel/head.o > arch/sparc64/kernel/init_task.o init/init.o --start-group > arch/sparc64/kernel/kernel.o arch/sparc64/mm/mm.o kernel/kernel.o mm/mm.o > fs/fs.o ipc/ipc.o security/built-in.o arch/sparc64/math-emu/math-emu.o > /home/bruce/sparctest/lib/lib.a lib/lib.a > /home/bruce/sparctest/arch/sparc64/prom/promlib.a > /home/bruce/sparctest/arch/sparc64/lib/lib.a drivers/built-in.o > sound/sound.o net/network.o --end-group -o vmlinux > drivers/built-in.o: In function `console_init': > drivers/built-in.o(.text.init+0xa78): undefined reference to > `uart_console_init' New serial tty code. Have no idea for the fix. |
|
From: Holzrichter, B. <bru...@mo...> - 2002-08-14 15:09:24
|
> > Oops. Fixed now. > Whoa, that was neat! ;o) Just an fyi from my last attempt. Upon booting with FB enabled with the changes, The screen was completely filled with blocks displayed on the screen. I could see in the background the display change as it tried to print out the kern messages, but they just mangled the blocks on the screen. It looked like a screen full of extended ascii character 222 and 223's.. :o) However, due to other problems I am having with it, most likely still IDE related, I can't give much more of a report than this.... B. |
|
From: James S. <jsi...@in...> - 2002-08-22 19:26:51
|
> > Oops. Fixed now. > > > Whoa, that was neat! ;o) Can you try the latest changes in my BK tree. |
|
From: Holzrichter, B. <bru...@mo...> - 2002-10-03 19:49:57
|
James, In a blast from the past, not sure if your still interested, but I have not had a whole lot of time to look at these, due to my job/life, etc,etc... If I apply the latest bk to it, I get the following compile error. As I said, I haven't even had time to grep through the thing to even begin to look, but wanted to report them anyways... fbmem.c: In function `fbmem_read_proc': fbmem.c:380: structure has no member named `modename' make[2]: *** [fbmem.o] Error 1 make[2]: Leaving directory `/home/bruce/sparctest/drivers/video' make[1]: *** [video] Error 2 make[1]: Leaving directory `/home/bruce/sparctest/drivers' make: *** [drivers] Error 2 Bruce H.. > -----Original Message----- > From: James Simmons [mailto:jsi...@in...] > Sent: Thursday, August 22, 2002 3:22 PM > To: Holzrichter, Bruce > Cc: lin...@li... > Subject: RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question > > > > > > Oops. Fixed now. > > > > > Whoa, that was neat! ;o) > > Can you try the latest changes in my BK tree. > |
|
From: James S. <jsi...@in...> - 2002-10-13 20:14:37
|
Sorry I have been going threw alot of chabnges recently. Try my lastest tree. I just updated it and I'm nearly done change the api. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net On Thu, 3 Oct 2002, Holzrichter, Bruce wrote: > James, > > In a blast from the past, not sure if your still interested, but I have not > had a whole lot of time to look at these, due to my job/life, etc,etc... > > If I apply the latest bk to it, I get the following compile error. As I > said, I haven't even had time to grep through the thing to even begin to > look, but wanted to report them anyways... > > fbmem.c: In function `fbmem_read_proc': > fbmem.c:380: structure has no member named `modename' > make[2]: *** [fbmem.o] Error 1 > make[2]: Leaving directory `/home/bruce/sparctest/drivers/video' > make[1]: *** [video] Error 2 > make[1]: Leaving directory `/home/bruce/sparctest/drivers' > make: *** [drivers] Error 2 > > Bruce H.. > > > -----Original Message----- > > From: James Simmons [mailto:jsi...@in...] > > Sent: Thursday, August 22, 2002 3:22 PM > > To: Holzrichter, Bruce > > Cc: lin...@li... > > Subject: RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question > > > > > > > > > > Oops. Fixed now. > > > > > > > Whoa, that was neat! ;o) > > > > Can you try the latest changes in my BK tree. > > > |
|
From: Sven L. <lu...@dp...> - 2002-10-14 09:55:30
|
On Sun, Oct 13, 2002 at 01:08:08PM -0700, James Simmons wrote: > > Sorry I have been going threw alot of chabnges recently. Try my lastest > tree. I just updated it and I'm nearly done change the api. BTW, i tried this WE to look at porting the pm3fb driver to the new API, doing a complete rewrite (well, basically starting again from tridentff, tdfxfb and skeletonfb, and getting the code as needed from current pm3fb, which has a lot of unneeded stuff in it). I have not much time though, so it will go slowly. I thought i may as well write a little HOWTO or something such on the way of doing this. Since i have not much fbdev writing experience, maybe i am a good candidate for writing such a thing. I wanted, in the first step, to do just a basic unaccelerated fbdev driver, without mode changes and anything fancy, and once this works, add things incrementally. I believe this approach will be good for future fbdev driver writters. Anyway, now for my question. skeletonfb says that check_var, set_par, setcolreg, pan_display and blank functions are optional or not required. Is that true, and in case i don't want to provide them, whay do i put in the fb_ops structure ? Later, in the fb_ops structure, only set_par, blank and pan_display are labeled as optional. Friendly, Sven Luther |
|
From: James S. <jsi...@in...> - 2002-10-18 18:20:39
|
> I thought i may as well write a little HOWTO or something such on the > way of doing this. Since i have not much fbdev writing experience, maybe > i am a good candidate for writing such a thing. Wow that would be great. > I wanted, in the first step, to do just a basic unaccelerated fbdev > driver, without mode changes and anything fancy, and once this works, > add things incrementally. I believe this approach will be good for > future fbdev driver writters. Good approach to doing this. > Anyway, now for my question. > > skeletonfb says that check_var, set_par, setcolreg, pan_display and > blank functions are optional or not required. Is that true, and in case > i don't want to provide them, whay do i put in the fb_ops structure ? All the functions are optional. They are needed when: fb_open: We need special things done when we open or close /dev/fb fb_release: fb_read: When we have a strange framebuffer that doesn't allow fb_write: linear writes. A good example is the Epson1385 chipset at 16 bpp mode. fb_check_var: When we can change the resolution of the display. fb_set_par: fb_setcolreg: Have a programable color palette. fb_blank: Have hardware support for power management of some kind. fb_pan_display: Hardware scrolling fb_cursor: Hardware cursor. fb_poll: Want to use interrupts such as VLB. fb_sync: To sync the accel engine and framebuffer memory. fb_ioctl: Extra functions you want to support. fb_mmap: Have special memory needs when exposing to userland. fb_rastering: I don't know if we are going to keep this one? The only ones require are the accel functions for drawing on the console. > Later, in the fb_ops structure, only set_par, blank and pan_display are > labeled as optional. That is a mistake. |
|
From: Geert U. <ge...@li...> - 2002-10-22 19:07:25
|
On Fri, 18 Oct 2002, James Simmons wrote:
> fb_rastering: I don't know if we are going to keep this one?
AFAIK these are used by the SPARC people only, to switch the graphics hardware
to frame buffer mode so the logo can be drawn. All other operations are done
using the accel engine on the cards that need fb_rasterimg().
So yes, once the logo is drawn by fb_imageblit(), fb_rasterimg() can be
eliminated by moving its functionality inside the fbdev-specific
fb_imageblit().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: James S. <cap...@ya...> - 2002-08-08 18:16:48
|
> I also hope that performance problems will be solved > before we are > forced to not use putcs. It will be :-) I need to one align the data. Second I plan to implement the patch recently posted here. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com |
Thanks for helping keep SourceForge clean.
X