
|
[haiku-appserver]
||
[Date Prev]
[01-2005 Date Index]
[Date Next]
||
[Thread Prev]
[01-2005 Thread Index]
[Thread Next]
[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.
|

|