* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-03 20:35 ` Petr Vandrovec
@ 2003-03-03 21:25 ` Geert Uytterhoeven
2003-03-03 21:32 ` Antonino Daplas
` (3 subsequent siblings)
4 siblings, 0 replies; 34+ messages in thread
From: Geert Uytterhoeven @ 2003-03-03 21:25 UTC (permalink / raw)
To: Petr Vandrovec
Cc: Antonino Daplas, James Simmons, Linux Kernel Mailing List,
Linux Fbdev development list
On Mon, 3 Mar 2003, Petr Vandrovec wrote:
> My main concern now is 12x22 font... Accelerator setup
> is so costly for each separate painted character that for 8bpp
> accelerated version is even slower than unaccelerated one :-(
> (and almost twice as slow when compared with 2.4.x).
Have you already tried Antonino's patches to use one imageblit for multiple
characters with (fontwidth % 8) != 0? It should help.
BTW, I still have to try it with amifb.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-03 20:35 ` Petr Vandrovec
2003-03-03 21:25 ` Geert Uytterhoeven
@ 2003-03-03 21:32 ` Antonino Daplas
2003-03-05 20:23 ` James Simmons
2003-03-04 21:29 ` Jurriaan
` (2 subsequent siblings)
4 siblings, 1 reply; 34+ messages in thread
From: Antonino Daplas @ 2003-03-03 21:32 UTC (permalink / raw)
To: Petr Vandrovec
Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list
On Tue, 2003-03-04 at 04:35, Petr Vandrovec wrote:
> My main concern now is 12x22 font... Accelerator setup
> is so costly for each separate painted character that for 8bpp
> accelerated version is even slower than unaccelerated one :-(
> (and almost twice as slow when compared with 2.4.x).
I submitted a patch to James, which he already applied to his tree, that
addresses this problem. It conglomerates the series of bitmaps into 1,
so only one fb_imageblit is necessary. It should give faster painting
than the original 2.5.x code, hopefully faster than 2.4.x code, but
slower than 8x16 painting because of the additional packing.
>
> And one (or two...) generic questions: why is not pseudo_palette
> u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
Yes, all drivers should treat the pseudo_palette as u32* anyway, so why
not change pseudo-palette from void* to u32*?
> And why we do not fill this pseudo_palette with
> i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> pseudocolor? This allowed me to remove couple of switches and tests
> from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> but I did not changed these two in my benchmarks below).
I also agree for a different reason. Cards with unconventional formats
(such as monochrome at 8 bpp - 0 for black , 0xff for white) will not
work with the current code.
Tony
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-03 21:32 ` Antonino Daplas
@ 2003-03-05 20:23 ` James Simmons
2003-03-06 1:18 ` Antonino Daplas
0 siblings, 1 reply; 34+ messages in thread
From: James Simmons @ 2003-03-05 20:23 UTC (permalink / raw)
To: Antonino Daplas
Cc: Petr Vandrovec, Linux Kernel Mailing List, Linux Fbdev development list
> > And one (or two...) generic questions: why is not pseudo_palette
> > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
>
> Yes, all drivers should treat the pseudo_palette as u32* anyway, so why
> not change pseudo-palette from void* to u32*?
See other email.
> > And why we do not fill this pseudo_palette with
> > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> > pseudocolor? This allowed me to remove couple of switches and tests
> > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> > but I did not changed these two in my benchmarks below).
>
> I also agree for a different reason. Cards with unconventional formats
> (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not
> work with the current code.
Isn't that the job of setcolreg?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-05 20:23 ` James Simmons
@ 2003-03-06 1:18 ` Antonino Daplas
0 siblings, 0 replies; 34+ messages in thread
From: Antonino Daplas @ 2003-03-06 1:18 UTC (permalink / raw)
To: James Simmons
Cc: Petr Vandrovec, Linux Kernel Mailing List, Linux Fbdev development list
On Thu, 2003-03-06 at 04:23, James Simmons wrote:
>
> > > And one (or two...) generic questions: why is not pseudo_palette
> > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> >
> > Yes, all drivers should treat the pseudo_palette as u32* anyway, so why
> > not change pseudo-palette from void* to u32*?
>
> See other email.
>
> > > And why we do not fill this pseudo_palette with
> > > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> > > pseudocolor? This allowed me to remove couple of switches and tests
> > > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> > > but I did not changed these two in my benchmarks below).
> >
> > I also agree for a different reason. Cards with unconventional formats
> > (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not
> > work with the current code.
>
> Isn't that the job of setcolreg?
>
setcolreg does that for directcolor and truecolor modes, because they're
the only ones that uses the pseudo_palette. See all driver codes, the
pseudo_palette is never initialized if in pseudo_color.
The purpose of the pseudo_palette is to enable to write pixels to the
framebuffer without knowing the color format at all. So, if you have
monochrome, then black is 0 and white is 1. But for monochrome 8bpp,
black is 0 and white is 0xff.
fbcon will send 0's and 1's, thus 0 and 1 will be written to the
framebuffer. If the drawing functions referred to the pseudo_palette,
whatever the visual format, then 0 and 0xff will be written, as it
should be.
Tony
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-03 20:35 ` Petr Vandrovec
2003-03-03 21:25 ` Geert Uytterhoeven
2003-03-03 21:32 ` Antonino Daplas
@ 2003-03-04 21:29 ` Jurriaan
2003-03-04 21:46 ` Petr Vandrovec
2003-03-09 21:29 ` Petr Vandrovec
2003-03-05 20:22 ` James Simmons
2003-03-28 14:19 ` 2.5.66 fbdev performance (was Re: Re: FBdev updates) Petr Vandrovec
4 siblings, 2 replies; 34+ messages in thread
From: Jurriaan @ 2003-03-04 21:29 UTC (permalink / raw)
To: Petr Vandrovec
Cc: Antonino Daplas, James Simmons, Linux Kernel Mailing List,
Linux Fbdev development list
From: Petr Vandrovec <vandrove@vc.cvut.cz>
Date: Mon, Mar 03, 2003 at 09:35:00PM +0100
> On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote:
> > On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> > >
> > > I was for five weeks in U.S., so I did not do anything with
> > > matroxfb during that time. I plan to use fillrect and copyrect
> > > from generic code (although it means unnecessary multiply on
> > > generic side, and division in matroxfb, but well, if we gave
> > > up on reasonable speed for fbdev long ago...). But I simply
> > > want loadfont and putcs hooks for character painting. And if
> > > fbdev maintainer does not want to give me them, well, then
> > > matroxfb and fbdev are not compatible.
> >
> > Petr,
> >
> > I submitted the Tile Blitting patch to James some time ago, it has
> > tilefill, tilecopy and tileblit hooks. These hooks should eliminate the
> > "multiply in fbcon, divide in driver" bottleneck.
> >
> > It should result in the same behavior as you would expect in the the 2.4
> > API, so you can use text mode with your matroxfb driver. These same
> > hooks will also help optimize drawing if we need to use fonts like
> > 12x22.
>
> Hi,
> while waiting on these updates I updated matroxfb a bit
> (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> so that it now uses fb_* for cfb modes, and putcs/... hooks for
> text mode.
There is a regression here: I boot my kernel like this:
kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1
and have the following .config:
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_MGA=y
CONFIG_RAW_DRIVER=y
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FBCON_ADVANCED=y
CONFIG_FONT_SUN12x22=y
CONFIG_FONTS=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_ACCEL=y
matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 1600x1200x16bpp (virtual: 1600x5241)
matroxfb: framebuffer at 0xD4000000, mapped to 0xe0805000, size 33554432
Console: switching to colour frame buffer device 133x54
fb0: MATROX VGA frame buffer device
pty: 256 Unix98 ptys configured
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Apollo Pro 266T chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xd0000000
[drm] Initialized mga 3.1.0 20021029 on minor 0
I see a continuous strip of alternating blocks, of sub-character size,
at the extreme right end of my screen. The colors seem linked to the
color of the line with the cursor in some way.
After leaving XFRee, a piece of chbg's background picture is shown for a
short while, then the blocks return.
Kind regards,
Jurriaan
--
But the threat of disapproval had terrified me
No more my soul will I reveal
Wargasm - Chameleon
GNU/Linux 2.5.63 SMP/ReiserFS 1x2793 bogomips load av: 1.18 0.46 0.17
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-04 21:29 ` Jurriaan
@ 2003-03-04 21:46 ` Petr Vandrovec
2003-03-09 21:29 ` Petr Vandrovec
1 sibling, 0 replies; 34+ messages in thread
From: Petr Vandrovec @ 2003-03-04 21:46 UTC (permalink / raw)
To: Jurriaan
Cc: Antonino Daplas, James Simmons, Linux Kernel Mailing List,
Linux Fbdev development list
On Tue, Mar 04, 2003 at 10:29:06PM +0100, Jurriaan wrote:
> > text mode.
>
> There is a regression here: I boot my kernel like this:
>
> kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1
>
> I see a continuous strip of alternating blocks, of sub-character size,
> at the extreme right end of my screen. The colors seem linked to the
> color of the line with the cursor in some way.
>
> After leaving XFRee, a piece of chbg's background picture is shown for a
> short while, then the blocks return.
Reproduced. Try this (untested) (it is against clean tree, so you'll
get some line offsets if you had applied my matroxfb patch). Or set
xres to odd value, even values do not work...
Petr Vandrovec
--- linux/drivers/video/console/fbcon.c 2003-03-03 18:42:37.000000000 +0100
+++ linux/drivers/video/console/fbcon.c 2003-03-04 22:44:05.000000000 +0100
@@ -456,7 +456,7 @@
region.color = attr_bgcol_ec(p, vc);
region.rop = ROP_COPY;
- if (rw & !bottom_only) {
+ if (rw && !bottom_only) {
region.dx = info->var.xoffset + rs;
region.dy = 0;
region.width = rw;
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-04 21:29 ` Jurriaan
2003-03-04 21:46 ` Petr Vandrovec
@ 2003-03-09 21:29 ` Petr Vandrovec
2003-03-09 22:27 ` Antonino Daplas
2003-03-11 15:31 ` James Simmons
1 sibling, 2 replies; 34+ messages in thread
From: Petr Vandrovec @ 2003-03-09 21:29 UTC (permalink / raw)
To: jsimmons
Cc: Antonino Daplas, Linux Kernel Mailing List, Linux Fbdev development list
Hi James,
I tried to use fb_cursor and I have quite a lot problems with
it:
(1) it uses global variables for storing last cursor value -
- but there is no global hardware, so after switching from
one fbdev to another you can have cursor with wrong shape,
wrong color and so on...
(2) callback from timer for cursor blinking may set almost any
FB_CUR_* bits. But in this case fb_cursor callback may be
called from interrupt context, while accelerator is busy
and so on... Did I miss some synchronization? Best for me
would be disabling blinking code in fbcon completely:
in VGA mode cursor blinks automatically, and in graphics mode
more lightweight only 'flash' callback is more appropriate
for me. But then there is problem with
(3) cursor_undrawn... I have no idea how is this supposed to work
if fbdev provides hardware cursor... And HZ/50 delay after
putcs makes orientation on screen very complicated, as there
is no cursor while new characters are appearing on screen.
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-09 21:29 ` Petr Vandrovec
@ 2003-03-09 22:27 ` Antonino Daplas
2003-03-09 22:54 ` Petr Vandrovec
2003-03-11 15:31 ` James Simmons
1 sibling, 1 reply; 34+ messages in thread
From: Antonino Daplas @ 2003-03-09 22:27 UTC (permalink / raw)
To: Petr Vandrovec
Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list
On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> Hi James,
> I tried to use fb_cursor and I have quite a lot problems with
> it:
> (1) it uses global variables for storing last cursor value -
> - but there is no global hardware, so after switching from
> one fbdev to another you can have cursor with wrong shape,
> wrong color and so on...
> (2) callback from timer for cursor blinking may set almost any
> FB_CUR_* bits. But in this case fb_cursor callback may be
> called from interrupt context, while accelerator is busy
> and so on... Did I miss some synchronization? Best for me
> would be disabling blinking code in fbcon completely:
> in VGA mode cursor blinks automatically, and in graphics mode
> more lightweight only 'flash' callback is more appropriate
> for me. But then there is problem with
I've also noticed problems with 1 and 2, and I submitted a patch to
James that allocates resources on a per device basis instead of being
global and statically allocated. This includes the cursor data
structures, cursor timer/vbl interrupt service, putcs buffer, and
optionally the softback buffer. The last is probably not very important
for the present setup but may become useful later on (ie, multiple
active consoles).
As for synchronization, I was meaning to ask some pointers on that. The
setup currently works like this:
(blink)
fbcon_cursor fbcon_vbl_handler (interrupt or timer)
| |
-----------------------
|
accel_cursor
|
-----------------------
| |
hardware soft_cursor accel_putcs accel_putc
| | |
-------------- -----------------
|
fb_get_buffer_offset
|
xxxfb_imageblit
|
-------------------
| |
hardware software
I was thinking of placing locks in accel_cursor and
fb_get_buffer_offset, but I'm not sure.
> (3) cursor_undrawn... I have no idea how is this supposed to work
In the present cursor api, the driver just needs to draw/undraw the
cursor whether by software or hardware. So the problem here is with
cursors that does it's own blinking, such as text modes.
> if fbdev provides hardware cursor... And HZ/50 delay after
> putcs makes orientation on screen very complicated, as there
> is no cursor while new characters are appearing on screen.
The delay is only for the blinking. After drawing a character/stream of
characters, an explicit "draw cursor" command immediately follows (I
think) via fbcon_cursor.
Tony
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-09 22:27 ` Antonino Daplas
@ 2003-03-09 22:54 ` Petr Vandrovec
2003-03-09 23:44 ` Antonino Daplas
0 siblings, 1 reply; 34+ messages in thread
From: Petr Vandrovec @ 2003-03-09 22:54 UTC (permalink / raw)
To: Antonino Daplas
Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list
On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
>
> As for synchronization, I was meaning to ask some pointers on that. The
> setup currently works like this:
>
> (blink)
> fbcon_cursor fbcon_vbl_handler (interrupt or timer)
> | |
> -----------------------
> |
> accel_cursor
> |
> -----------------------
> | |
> hardware soft_cursor accel_putcs accel_putc
> | | |
> -------------- -----------------
> |
> fb_get_buffer_offset
> |
> xxxfb_imageblit
> |
> -------------------
> | |
> hardware software
>
>
> I was thinking of placing locks in accel_cursor and
> fb_get_buffer_offset, but I'm not sure.
Maybe just auditing code is enough: cursor_on should be zero while
we are inside accel_putc/putcs (or inside any other fb function), and
if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
sure that fbcon_vbl_handler is not running on other CPU while we set
cursor_on = 0 should be enough.
> > if fbdev provides hardware cursor... And HZ/50 delay after
> > putcs makes orientation on screen very complicated, as there
> > is no cursor while new characters are appearing on screen.
>
> The delay is only for the blinking. After drawing a character/stream of
> characters, an explicit "draw cursor" command immediately follows (I
> think) via fbcon_cursor.
Why we schedule cursor painting at all then? While we are inside putcs,
we cannot paint cursor anyway (as we are busy with painting characters
at cursor position...) and fbcon_cursor(CM_DRAW) should restart timer interval
anyway (so you see cursor while you type characters, and not like Solaris
where cursor appears after you stop typing characters) (unfortunately when
I tried to verify how it behaves on secondary head of matrox (which does not
have hardware cursor), I made a typo and ...
Unable to handle kernel NULL pointer dereference at virtual address 00000196
printing eip:
c02f9258
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c02f9258>] Tainted: PFS
EFLAGS: 00010202
EIP is at fb_open+0x28/0xf0
eax: c6ed2c30 ebx: 00000020 ecx: 00000001 edx: c04848e0
esi: 00000002 edi: 00000000 ebp: c6ed2c30 esp: c4bb3f18
ds: 007b es: 007b ss: 0068
Process con2fb (pid: 18180, threadinfo=c4bb2000 task=d874d940)
Stack: 00000006 c8a8aae4 c4bb2000 00000000 c8a8aae4 c01669ea c6ed2c30 c8a8aae4
dffe6830 c01435e3 c8a8aae4 c6ed2c30 dffe6830 00000000 c015af91 c6ed2c30
c8a8aae4 00000002 bffffe7a dcaa5000 c4bb2000 c015adb7 ca74978c dffe6830
Call Trace:
[<c01669ea>] chrdev_open+0xaa/0x110
[<c01435e3>] file_ra_state_init+0x23/0x40
[<c015af91>] dentry_open+0x1d1/0x1f0
[<c015adb7>] filp_open+0x67/0x70
[<c015b26b>] sys_open+0x5b/0x90
[<c0109983>] syscall_call+0x7/0xb
Code: 8b 86 94 01 00 00 b9 01 00 00 00 8b 10 85 d2 74 1c b8 00 e0
so I'll have to check it tomorrow on real dualhead system...)
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-09 22:54 ` Petr Vandrovec
@ 2003-03-09 23:44 ` Antonino Daplas
0 siblings, 0 replies; 34+ messages in thread
From: Antonino Daplas @ 2003-03-09 23:44 UTC (permalink / raw)
To: Petr Vandrovec
Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list
On Mon, 2003-03-10 at 06:54, Petr Vandrovec wrote:
> On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> > On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> >
> > As for synchronization, I was meaning to ask some pointers on that. The
> > setup currently works like this:
> >
> > (blink)
> > fbcon_cursor fbcon_vbl_handler (interrupt or timer)
> > | |
> > -----------------------
> > |
> > accel_cursor
> > |
> > -----------------------
> > | |
> > hardware soft_cursor accel_putcs accel_putc
> > | | |
> > -------------- -----------------
> > |
> > fb_get_buffer_offset
> > |
> > xxxfb_imageblit
> > |
> > -------------------
> > | |
> > hardware software
> >
> >
> > I was thinking of placing locks in accel_cursor and
> > fb_get_buffer_offset, but I'm not sure.
>
> Maybe just auditing code is enough: cursor_on should be zero while
> we are inside accel_putc/putcs (or inside any other fb function), and
> if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
> sure that fbcon_vbl_handler is not running on other CPU while we set
> cursor_on = 0 should be enough.
I think that's what happens. cursor_on is set to 0 at the beginning of
fbcon_cursor(), and it remains 0 until the next fbcon_cursor() is
CM_DRAW or CM_MOVE. And while cursor_on is 0, fbcon_vbl_handler just
exits immediately. Yes, it's basically the code in 2.4, but instead of
using revc, it uses imageblit, and instead of allowing the drivers to do
the blinking, fbcon does it entirely, whether a hardware or software
cursor method is installed.
>
> > > if fbdev provides hardware cursor... And HZ/50 delay after
> > > putcs makes orientation on screen very complicated, as there
> > > is no cursor while new characters are appearing on screen.
> >
> > The delay is only for the blinking. After drawing a character/stream of
> > characters, an explicit "draw cursor" command immediately follows (I
> > think) via fbcon_cursor.
>
> Why we schedule cursor painting at all then? While we are inside putcs,
> we cannot paint cursor anyway (as we are busy with painting characters
I don't think any cursor painting is done while doing putcs, if the
CM_ERASE, putc/putcs, CM_DRAW/CM_MOVE sequence is followed. Note that I
haven't verified if that particular sequence is followed, I just assume
the console layer does.
Tony
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-09 21:29 ` Petr Vandrovec
2003-03-09 22:27 ` Antonino Daplas
@ 2003-03-11 15:31 ` James Simmons
1 sibling, 0 replies; 34+ messages in thread
From: James Simmons @ 2003-03-11 15:31 UTC (permalink / raw)
To: Petr Vandrovec
Cc: Antonino Daplas, Linux Kernel Mailing List, Linux Fbdev development list
> Hi James,
> I tried to use fb_cursor and I have quite a lot problems with
> it:
I'm working on the code today. I just finished the final touchs on the
pixmap buffer code. The next step is to make the pixmaps have flag for
static data versus dynamic data. You can then use fastfonst with static
buffer. This comes with the tile code. But first the cursor code today.
P.S
You can grab my latest work on the matroxfb driver at
http://phoenix.infradead.org/~jsimmons/matroxfb.diff.gz
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-03 20:35 ` Petr Vandrovec
` (2 preceding siblings ...)
2003-03-04 21:29 ` Jurriaan
@ 2003-03-05 20:22 ` James Simmons
2003-03-06 7:35 ` Sven Luther
2003-03-28 14:19 ` 2.5.66 fbdev performance (was Re: Re: FBdev updates) Petr Vandrovec
4 siblings, 1 reply; 34+ messages in thread
From: James Simmons @ 2003-03-05 20:22 UTC (permalink / raw)
To: Petr Vandrovec
Cc: Antonino Daplas, Linux Kernel Mailing List, Linux Fbdev development list
> Hi,
> while waiting on these updates I updated matroxfb a bit
> (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> so that it now uses fb_* for cfb modes, and putcs/... hooks for
> text mode. I have still dozen of changes in fbcon.c which I have
> to eliminate (mainly logo painting and cursor handling - for now
> I still use revc method, mainly because of I did not make into it yet).
I grabbed your latest patch and started to merge it with my latest work on
the matrox driver. As soon as I'm done merging my matrox changes I will
send you a patch right away.
> My main concern now is 12x22 font... Accelerator setup
> is so costly for each separate painted character that for 8bpp
> accelerated version is even slower than unaccelerated one :-(
> (and almost twice as slow when compared with 2.4.x).
Try the latest patch I released.
> And one (or two...) generic questions: why is not pseudo_palette
> u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
pseudo_palette was originally designed to be a pointer to some kind of
data for color register programming. For example many PPC graphics cards
have a color register region. Now you could have that point to
pseudo_palette. Note pseudo_palette is only visiable in fbmem.c for the
logo drawing code. Personally I liek to see that hidden.
> And why we do not fill this pseudo_palette with
> i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> pseudocolor? This allowed me to remove couple of switches and tests
> from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> but I did not changed these two in my benchmarks below).
??? Does your accel engine require these kinds of values?
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-05 20:22 ` James Simmons
@ 2003-03-06 7:35 ` Sven Luther
2003-03-06 8:05 ` Antonino Daplas
0 siblings, 1 reply; 34+ messages in thread
From: Sven Luther @ 2003-03-06 7:35 UTC (permalink / raw)
To: James Simmons
Cc: Petr Vandrovec, Antonino Daplas, Linux Kernel Mailing List,
Linux Fbdev development list
On Wed, Mar 05, 2003 at 08:22:26PM +0000, James Simmons wrote:
>
> > Hi,
> > while waiting on these updates I updated matroxfb a bit
> > (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> > so that it now uses fb_* for cfb modes, and putcs/... hooks for
> > text mode. I have still dozen of changes in fbcon.c which I have
> > to eliminate (mainly logo painting and cursor handling - for now
> > I still use revc method, mainly because of I did not make into it yet).
>
> I grabbed your latest patch and started to merge it with my latest work on
> the matrox driver. As soon as I'm done merging my matrox changes I will
> send you a patch right away.
>
> > My main concern now is 12x22 font... Accelerator setup
> > is so costly for each separate painted character that for 8bpp
> > accelerated version is even slower than unaccelerated one :-(
> > (and almost twice as slow when compared with 2.4.x).
>
> Try the latest patch I released.
>
> > And one (or two...) generic questions: why is not pseudo_palette
> > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
>
> pseudo_palette was originally designed to be a pointer to some kind of
> data for color register programming. For example many PPC graphics cards
> have a color register region. Now you could have that point to
Does this correspond to the LUT i have in my boards ?
BTW, what is the point in having a pseudo_palette if you can store
the colors in the onchip LUT table.
Friendly,
Sven Luther
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-06 7:35 ` Sven Luther
@ 2003-03-06 8:05 ` Antonino Daplas
2003-03-06 8:25 ` Sven Luther
0 siblings, 1 reply; 34+ messages in thread
From: Antonino Daplas @ 2003-03-06 8:05 UTC (permalink / raw)
To: Sven Luther
Cc: James Simmons, Petr Vandrovec, Linux Kernel Mailing List,
Linux Fbdev development list
On Thu, 2003-03-06 at 15:35, Sven Luther wrote:
> >
> > > And one (or two...) generic questions: why is not pseudo_palette
> > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> >
> > pseudo_palette was originally designed to be a pointer to some kind of
> > data for color register programming. For example many PPC graphics cards
> > have a color register region. Now you could have that point to
>
> Does this correspond to the LUT i have in my boards ?
>
> BTW, what is the point in having a pseudo_palette if you can store
> the colors in the onchip LUT table.
>
The hardware clut typically stores each color channel separately. In
software terms, this is akin to struct fb_cmap. The pseudo_palette, on
the other hand, is a pixel LUT, the contents of which can be directly
written to the framebuffer without it ever knowing the format at all, ie
it does not matter if it's RGB or YUV. This makes the upper layer
independent of the low-lever driver (at least in terms of colorspace
formats).
Tony
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates.
2003-03-06 8:05 ` Antonino Daplas
@ 2003-03-06 8:25 ` Sven Luther
0 siblings, 0 replies; 34+ messages in thread
From: Sven Luther @ 2003-03-06 8:25 UTC (permalink / raw)
To: Antonino Daplas
Cc: Sven Luther, James Simmons, Petr Vandrovec,
Linux Kernel Mailing List, Linux Fbdev development list
On Thu, Mar 06, 2003 at 04:05:32PM +0800, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 15:35, Sven Luther wrote:
> > >
> > > > And one (or two...) generic questions: why is not pseudo_palette
> > > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> > >
> > > pseudo_palette was originally designed to be a pointer to some kind of
> > > data for color register programming. For example many PPC graphics cards
> > > have a color register region. Now you could have that point to
> >
> > Does this correspond to the LUT i have in my boards ?
> >
> > BTW, what is the point in having a pseudo_palette if you can store
> > the colors in the onchip LUT table.
> >
>
> The hardware clut typically stores each color channel separately. In
> software terms, this is akin to struct fb_cmap. The pseudo_palette, on
> the other hand, is a pixel LUT, the contents of which can be directly
> written to the framebuffer without it ever knowing the format at all, ie
> it does not matter if it's RGB or YUV. This makes the upper layer
> independent of the low-lever driver (at least in terms of colorspace
> formats).
Ok, thanks, ...
Friendly,
Sven Luther
^ permalink raw reply [flat|nested] 34+ messages in thread
* 2.5.66 fbdev performance (was Re: Re: FBdev updates)
2003-03-03 20:35 ` Petr Vandrovec
` (3 preceding siblings ...)
2003-03-05 20:22 ` James Simmons
@ 2003-03-28 14:19 ` Petr Vandrovec
2003-03-28 18:50 ` [Linux-fbdev-devel] " Antonino Daplas
4 siblings, 1 reply; 34+ messages in thread
From: Petr Vandrovec @ 2003-03-28 14:19 UTC (permalink / raw)
To: Antonino Daplas
Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list
Hello,
I see a problem with new pixmap based code...
There is 25% slowdown for 8x16 8bpp videomode
after upgrading from 2.5.63 to 2.5.66 :-(
Setup as usual, 1024x768, 100Hz, secondary
head doing nothing (i.e. no fbtv...), CPU
doing nothing except running this test.
P4 1.6GHz, MGA G550. Shown value is system
time in seconds needed to repaint screen 1000
times (avg. from 3 tests) (you can treat it
as time in milliseconds needed to repaint
screen once).
Although speedup for 12x22 font is very nice,
it looks to me that we paid too much for it.
Problem is in the new pixmap handling, especially
pixbuf.output - so now instead of memcpy we
call some function for copying each byte from
font to temporary buffer. As you can see,
"constant" portion of time, independent of
color depth, increased by 1sec for unaccelerated
and by 0.75sec for accelerated putcs.
It is 5% to 25% slowdown (5% for 32bpp unaccelerated,
25% for 8bpp accelerated).
And while we are still faster than 2.4.x, we were
even better...
Petr
NOACCEL, 8x16
2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66
8bpp 10.02 6.96 5.62 6.62
16bpp 20.05 13.25 10.62 11.63
24bpp 30.03 19.05 15.13 16.07
32bpp 45.00 25.74 20.54 21.62
ACCEL, 8x16
2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66
8bpp 7.48 3.38 3.00 3.75
16bpp 7.50 3.38 3.01 3.76
24bpp 7.53 3.56 3.53 4.23
32bpp 8.95 4.37 4.33 5.05
NOACCEL, 12x22
2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66
8bpp 11.54 13.35 10.93 8.96
16bpp 20.00 22.02 18.03 13.61
24bpp 30.03 35.83 29.53 18.07
32bpp 40.12 44.48 36.75 23.22
ACCEL, 12x22
2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66
8bpp 8.57 14.87 12.90 5.72
16bpp 8.57 14.93 12.92 5.72
24bpp 8.56 15.13 13.10 6.20
32bpp 8.56 15.52 13.76 6.98
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Linux-fbdev-devel] 2.5.66 fbdev performance (was Re: Re: FBdev updates)
2003-03-28 14:19 ` 2.5.66 fbdev performance (was Re: Re: FBdev updates) Petr Vandrovec
@ 2003-03-28 18:50 ` Antonino Daplas
0 siblings, 0 replies; 34+ messages in thread
From: Antonino Daplas @ 2003-03-28 18:50 UTC (permalink / raw)
To: Petr Vandrovec
Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list
On Fri, 2003-03-28 at 22:19, Petr Vandrovec wrote:
>
> Problem is in the new pixmap handling, especially
> pixbuf.output - so now instead of memcpy we
> call some function for copying each byte from
> font to temporary buffer. As you can see,
> "constant" portion of time, independent of
> color depth, increased by 1sec for unaccelerated
> and by 0.75sec for accelerated putcs.
> It is 5% to 25% slowdown (5% for 32bpp unaccelerated,
> 25% for 8bpp accelerated).
>
Actually, the slowdown is caused not just by the overhead of the
read/write methods, but also due to the extra work padding and aligning
the bitmaps according to requirements of the hardware. This was because
James wanted support for buffers located not just in system memory but
also graphics/dma memory.
The result is that unaccelerated imageblit will slow down while properly
written accelerated imageblit will experience some speed up (not much,
probably around 5%).
We can:
1. partially reverse the code so it behaves similarly to 2.5.63.
Support for writing to graphics/dma memory will go away.
2. split the code path: one will go to the '2.5.63' path, the other
will go to the '2.5.66' path, depending on the setting of info->pixmap.
3. keep the code as is
Personally, I prefer #1, but it's up to James/Geert.
Tony
^ permalink raw reply [flat|nested] 34+ messages in thread