Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <van...@vc...> - 2003-03-13 22:23:54
|
Hi James, after I spent two hours trying to find why my accelerated fb_imageblit oopses (or paints garbage) when painting logo for bpp != 8 I have one simple question for you: Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit when logo image is in reality always 8bpp, as quick look at cfb_imageblit revealed? Should I just assume that image.depth == 1 means that data are 1bpp with fgcol/bgcol valid, and all other depths mean 8bpp input? Thanks, Petr Vandrovec van...@vc... |
|
From: Geert U. <ge...@li...> - 2003-03-14 09:24:28
|
On Thu, 13 Mar 2003, Petr Vandrovec wrote:
> Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit
> when logo image is in reality always 8bpp, as quick look at
> cfb_imageblit revealed?
Should indeed be 8.
> Should I just assume that image.depth == 1 means that data are
> 1bpp with fgcol/bgcol valid, and all other depths mean 8bpp
> input?
This was changed from 1 to 0 in James' latest tree.
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. <jsi...@in...> - 2003-03-11 15:33:45
|
> 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 |
|
From: Nicholas W. <nw...@ne...> - 2003-03-16 22:13:13
|
James Simmons wrote: >>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 > James (or anyone), Do you have something which might apply at least semi-cleanly to fbdev-2.5 current? The reason I ask is because I have to use 2.5.64-ac4 or else my system won't boot. The problem is that Alan has already applied your latest BK patch which kills your matroxfb diff against fbcon.c. Alan has also modified your changes, thus making backing it out quite difficult and prone to error... Thanks in advance :-). Cheers, Nicholas |
|
From: James S. <jsi...@in...> - 2003-03-05 20:23:35
|
> 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? |
|
From: Sven L. <lu...@dp...> - 2003-03-06 07:37:14
|
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 |
|
From: Antonino D. <ad...@po...> - 2003-03-06 08:04:14
|
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 |
|
From: Sven L. <lu...@dp...> - 2003-03-06 08:26:21
|
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 |
|
From: Ivan K. <in...@ju...> - 2003-02-20 15:11:35
|
On Thu, Feb 20, 2003 at 01:09:33AM +0000, James Simmons wrote: > <jsi...@ma...> (03/02/19 1.913.1.1) ... > using standard macros for vgacon.c. Unfortunately, this makes vgacon on non-legacy platforms where the I/O port address doesn't fit in unsigned short almost unfixable. :-( Ivan. |
|
From: Petr V. <van...@vc...> - 2003-03-28 14:19:42
|
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
|
|
From: Antonino D. <ad...@po...> - 2003-03-28 19:09:45
|
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 |
Thanks for helping keep SourceForge clean.
X