From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: James Simmons <jsimmons@infradead.org>
Cc: Antonino Daplas <adaplas@pol.net>,
linux-kernel@vger.kernel.org,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Re: FBdev updates.
Date: Wed, 5 Mar 2003 21:31:05 +0100 [thread overview]
Message-ID: <11EC6AF51A4E@vcnet.vc.cvut.cz> (raw)
On 5 Mar 03 at 20:22, James Simmons 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
> pseudo_palette. Note pseudo_palette is only visiable in fbmem.c for the
> logo drawing code. Personally I liek to see that hidden.
cfbfillrect? cfbimageblit? Both use pseudo_palette, and both convert
it 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).
>
> ??? Does your accel engine require these kinds of values?
Yes. It is 32bit engine, and so it wants 32bit value. And even if
not, code doing
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR)
fg = p->pseudo_palette[rect->color];
else
fg = rect->color;
is horrible. Two conditional jumps on each rectangle. If you'll do
always lookup through pseudo_palette, not only that you get rid of
these jumps, you can also remove calls to pixel_to_pat32 (and accompanying
tables & lookups), as you do this expansion at set_var time,
instead of at blit/clear time.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-------------------------------------------------------
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
WARNING: multiple messages have this Message-ID (diff)
From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: James Simmons <jsimmons@infradead.org>
Cc: Antonino Daplas <adaplas@pol.net>,
linux-kernel@vger.kernel.org,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [Linux-fbdev-devel] Re: FBdev updates.
Date: Wed, 5 Mar 2003 21:31:05 +0100 [thread overview]
Message-ID: <11EC6AF51A4E@vcnet.vc.cvut.cz> (raw)
On 5 Mar 03 at 20:22, James Simmons 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
> pseudo_palette. Note pseudo_palette is only visiable in fbmem.c for the
> logo drawing code. Personally I liek to see that hidden.
cfbfillrect? cfbimageblit? Both use pseudo_palette, and both convert
it 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).
>
> ??? Does your accel engine require these kinds of values?
Yes. It is 32bit engine, and so it wants 32bit value. And even if
not, code doing
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR)
fg = p->pseudo_palette[rect->color];
else
fg = rect->color;
is horrible. Two conditional jumps on each rectangle. If you'll do
always lookup through pseudo_palette, not only that you get rid of
these jumps, you can also remove calls to pixel_to_pat32 (and accompanying
tables & lookups), as you do this expansion at set_var time,
instead of at blit/clear time.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
next reply other threads:[~2003-03-05 20:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-05 20:31 Petr Vandrovec [this message]
2003-03-05 20:31 ` [Linux-fbdev-devel] Re: FBdev updates Petr Vandrovec
-- strict thread matches above, loose matches on Subject: below --
2003-08-16 15:50 updates Chris Heath
2003-08-14 20:52 FBDEV updates James Simmons
2003-08-14 21:57 ` Jon Smirl
2003-03-03 21:32 [Linux-fbdev-devel] Re: FBdev updates Antonino Daplas
2003-03-05 20:23 ` James Simmons
2003-03-06 1:18 ` Antonino Daplas
2003-02-21 9:09 [Linux-fbdev-devel] " Geert Uytterhoeven
2003-02-21 10:46 ` Antonino Daplas
2003-02-20 1:09 James Simmons
2003-02-20 15:02 ` Dave Jones
2003-02-20 18:29 ` Petr Vandrovec
2003-02-21 0:24 ` Antonino Daplas
2003-03-03 20:35 ` [Linux-fbdev-devel] " Petr Vandrovec
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-09 22:54 ` Petr Vandrovec
2003-03-09 23:44 ` Antonino Daplas
2003-03-11 15:31 ` [Linux-fbdev-devel] " James Simmons
2003-03-16 22:10 ` Nicholas Wourms
2003-03-05 20:22 ` James Simmons
2003-03-06 7:35 ` Sven Luther
2002-06-05 16:50 fbdev updates Russell King
2002-06-05 17:21 ` James Simmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11EC6AF51A4E@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=adaplas@pol.net \
--cc=jsimmons@infradead.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.