All of lore.kernel.org
 help / color / mirror / Atom feed
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
                                                


             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.