[interfacekit] Re: WaitForRetrace() and BScreen.. (fwd)

Hi,

this is a forward from Rudolf Cornelissen who read our thread about 
overlay and offscreen bitmaps - and filled out the missing technical 
details ;-)

I don't know how to subscribe him to this list, but I really think we 
should invite him to join, so that he can make his remarks directly to 
the conversation.

So, here it is:

------ Forwarded Message: ------
BTW: Please make sure overlay will get implemented in openBeOS ;-) I 
saw 
another thread on the interface kit from a month or so ago. I really 
don't 
want to have to do without that..

Graphics cards can indeed _not_ blit to/from main memory. At least you 
may 
not depend on that as a lot of cheap brands or motherboard chipsets 
don't 
support it.
Probably the only way to do this is via some sort of DMA. Anyway, you 
don't 
want to overcrowd the AGP or worse: PCI bus with that...

Please be advised that a screen_to_screen blit is nothing more than a 
copy 
and paste command from and to the internal card memory. Because 
sometimes 
(mostly) the source and dest partly overlap, the direction has to be 
determined that should be used. Matrox cards need to be instructed 
about 
this, while Nvidia's engine autodetects this :)

Please be advised also that a 2D engine does not exist next to a 3D 
engine on 
a card. It's the same engine that does both. So it's just an 
'acceleration 
engine'. (though in theory cards can have more than one overlay engine, 
and 
more than one acc engine. In fact BeOS supports that (both) at least in 
the 
accelerant interface. I think I'll try to setup support for a second 
overlayed video output in the Nvidia driver later on because I think 
the 
overlay unit just might suppor that. It still is one unit because both 
outputs will have to be on the same head though.

A 2D only capable card, such as the NeoMagic laptops chips or most 
ondie 
motherboard graphics cards, have a engine that can't do 3D. You could 
talk 
about a 2D engine in this case, while Matrox, ATi and Nvidia have a 3D 
capable engine.

One other thing about the acc engine: It works in the memory as being a 
actual screen buffer. It uses a width and height, so no linear space. 
Though 
on some cards that just might be possible that way.

The acc engine only supports upto a certain width. Matrox can do 16384 
in 8 
bit, 8192 in 16 bit and about 4064 in 32bit, while Nvidia can do 65536, 
32768 
and 16384 (AFAIK ATM: my knowledge here is increasing ;-).
This means you cannot simply setup some B_BITMAP_OFFSCREEN (a non-
overlay 
bitmap that's in the graphics card ram, so not in main memory) that 
could be 
hardware accelerated filled with graphics, and then blit that to the 
onscreen 
memory.
In theory it can be done, but it requires well-planned placing of the 
offscreen bitmaps close to the actual screen, because to the acc_engine 
it's 
in the same 'workspace'. Otherwise the blitting to onscreen mem cannot 
be 
done. Blitting and such within that bitmap could be done, but it would 
require a reinitialisation of the acc engine before it can do that. And 
if 
you would want to use that engine after this action on the onscreen 
buffer 
again, it would need to be re-initialized again.

I think there's a higher limit on the height for the acc engine than on 
the 
width though.

Also, if you would want to use different colorspaces on the offscreen 
bitmaps 
than the actual screen is using, you'd need the acc_engine to translate 
that 
for you. While it can do that, you'd need to set that up. Because in 
Linux 
for instance you might not find that, and you also have no specs, you'd 
have 
a problem. This applies for all not so often used functions in such an 
engine. You'd have to think about options the drivers would need to 
have to 
inform the system that it can or cannot do certain things.


Anyway: my choice would be _not_ relying on those things. Just keep it 
plain 
and simple. Only used widely accepted things the cards can do: 
otherwise 
you'll have to tweak around a lot, and know all limitations of 
acc_engine 
(for instance) precisely. And that's a problem sometimes, as specs are 
not 
given. The linux drivers for instance generally don't care about 
limitations: 
the system just fails. In linux the user is required to know what he or 
she 
is doing... And exacly _that_ is something I'd hate to see appearing in 
BeOS..

At least my BeOS drivers do limit checking and prevent the user from 
asking 
something of the card it cannot or may not do. I think I am describing 
'the 
be way' of doing things here or at least part of it (straight, simple, 
controlled, and using only generally used techniques from cards) . But 
of 
course this all is my humble opinion. I am no expert either.

Thanks for listening and maybe relaying this info :)

I will be off on vacation BTW for a week or so starting the coming 
friday. 
Just so you know ;-)

Best regards,

Rudolf.

----------------

Adios...
   Axel.

Other related posts: