[haiku-appserver] Re: profiling / acc / ROPs

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 31 Jan 2005 09:48:33 +0100 CET

Hi DW,

> I'm not Stephan, but I can answer at least some of your questions. :)
Thanks!

> GraphicsDefs.h

> enum drawing_mode {
>       B_OP_COPY,
>       B_OP_OVER,
>       B_OP_ERASE,
>       B_OP_INVERT,
>       B_OP_ADD,
>       B_OP_SUBTRACT,
>       B_OP_BLEND,
>       B_OP_MIN,
>       B_OP_MAX,
>       B_OP_SELECT,
>       B_OP_ALPHA
> };
Aha: thanks. Let's see, nvidia driver defines:
   0x00,            /* GXclear */
   0x88,            /* GXand */
   0x44,            /* GXandReverse */
   0xCC,            /* GXcopy */
   0x22,            /* GXandInverted */
   0xAA,            /* GXnoop */
   0x66,            /* GXxor */
   0xEE,            /* GXor */
   0x11,            /* GXnor */
   0x99,            /* GXequiv */
   0x55,            /* GXinvert*/
   0xDD,            /* GXorReverse */
   0x33,            /* GXcopyInverted */
   0xBB,            /* GXorInverted */
   0x77,            /* GXnand */
   0xFF             /* GXset */
};

The values are card-type specific apparantly, so the driver would need 
to 'translate' that.
I don't know if these two lists are analogues: so if they talk about 
the same thing. But it would make sense I guess.
Maybe it's something else after all.
BTW Another thing that can be set in hardware is a bit-pattern to be 
used on fills for example. Currently always using 'all bits set'.

> They are used to specify drawing modes whenever a call is made to the 
> DisplayDriver class. Client applications use them in the BView 
> graphics 
> calls, whether it's FillRect or StrokeShape.


> Do you mean that we would have to extend the graphics driver 
> interface? 
> I don't know if we can do that now or if it has to wait until R2. It 
> would be nice to be able to accelerate anything that we can that's 
> practical to do so.
Indeed. R2 sounds good :)
Anyway, just wanted to let you know that there might be 'missed 
options' here. Although I am guessing Be did not implement them because 
they are used rarely. (?)
Some acceleraters even specificly talk about windows patters (if I 
recall correctly) and literally implemented them as they where used on 
that OS. (Chips and Technologies CT69000, 65555 etc: datasheets 
available)

> That reminds me. What kinds of things *can* a graphics card 
> accelerate?
As you know BeOS uses just four functions, in kind of a hardcoded setup 
(from the list above and the pattern mentioned).
There are two more functions defined for accelerants 
(scaled_filtered_blit and screen_to_screen_transparant_blit).

The first one comes into mind for things like video playback (one could 
use that as a fallback when overlay is missing: but you don't have 
colorkeying then). That function is for instance also used internally 
on Matrox G450 and 550 to 'simulate' high-res TVoutput (it only has 
encoders for the 'raw' resolution a TVset has).
The second one you have to tell _me_. I am not able to visualize this 
in my thoughts. What would that be good for??

Anyway. one of the four function Beos uses is fill_span. The nvidia 
cards can do this specificly as well (now using fill_rect instead 
internally: but I will have a closer look at optimzing that via the 
specific command: I'll also try to issue them at once: as a single 
command can do upto 32 lines issued at once apparantly (instead of 
looping and calling the routine over and over again)).
What I wanted to say is this: the engine's fill_span command can work 
with lines in _any_ direction (2D), not just horizontal ones.

There are about a hundred engine commands available, but most of them 
are for 3D I'd say. I wouldn't know what you'd want to do with them for 
2D acc. 

---

So, to summarize it: I think those 6 commands Be came up with are 
probably the most important ones, that do most of the acceleration 
you'd ever need for 2D. I expect the 'hardcoded' style of certain 
things in them might be done because they are not used often and 
therefore do not speed up the system much as a whole.
So, I am interested in that list and pattern subject I mentioned: to 
see if you guys would/could confirm or deny my thoughts about this 
(always trying to learn :-)


Bye!

Rudolf.


Other related posts: