[haiku-appserver] Re: user needs to know about the clipping region?

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 05 Dec 2005 21:59:38 +0100 CET


Although a bit late, I want to make a few notes about the subject.

> >     (For dragging things, I think we can use the HW overlays if 
> > available -
> > would spear us a lot of trouble.)
> Yes, but let's think about how to make this work without any changes 
> to the 
> driver API. Because I wouldn't know how to implement those. :-) If 
> you do, be 
> my guest!!

- there is only _one_ overlay engine if you are talking about the 
engine we use for video.
-if overlayed video is running, you can't do your transparancy thing
-you can only do _one_ transparancy thing at a time
-note that the overlay engine has no target in RAM, it just sends its 
output to the monitor (directly!, so DAC)
-I think there's a contradiction here:
 1. Haiku doesn't want to use hardware cursors (AFAIK) because 'these 
days it can be done perfectly using other means'. Note here that the 
cursor hardware _is_ a hardware overlay especially created for this 
 2. you want to do transparancy drawing using hardware overlay. So 
cursor (is example) gets drawn with video overlay engine. 

Eh: that cursor had it's own specialized engine!


AGP bus and transfers.
1. CPU does write over bus: uses PCI transfers and FW if available
2. CPU reads over bus: uses PCI transfers. Note that the actual speed 
is just 1/10th of PCI speed because graphics hardware has fixed verly 
low priority for this type of transfer.
3. GPU does reads over bus (alternate solution for 1.) uses AGP 
4. GPU does writes over bus (alternate solution for 2.). THIS DOES NOT 
EXIST. Apart from the 'TurboCache' technology nVidia 'invented' for the 
GeForce 6200 TC series of GPU's (and of course ATI has it's own 

additional remarks:
PCI + FW == AGP speed wise. (more or less)
FW is troublesome on some hardware (almost all ATI cards AFAIK!)
FW is not always supported.

FW requires no additional specs.
AGP transfers (so by GPU) require additional specs. Although I have it 
going for the command buffer I still never tested for it for actual 
blit functions (transferring a bitmap _litterally_ (so in same 
colorspace as frontbuffer) over the bus. My guess is though that it 
would be simple to get it going on _all_ nVidia cards. (can be a 2D 
command, the 3D version would be troublesome to say the least;-)

PCIe writes and reads should be equally fast for CPU initiated reads/
writes, and GPU initiated reads/writes. 
Unfortunately the write-by-GPU does not exist (as mentioned above) and 
the read-by-CPU keeps being 1/10th of old PCI speed due to thing 
mentioned above.

General rule: prevent/minimize any type of read from graphics card RAM!


graphics memory manager: Would be nice to have. For all cardRAM. It 
should know where the cursor sits (if used), and the visible 
framebuffer, the overlay bitmaps etc. There should be just one manager 
for all mem I'd say.
A driver BTW may need to create some private bitmaps as well. There 
should be room for it to ask that from the memory manager. (double 
buffering for TVout comes to mind as it would need to be done on matrox 
G450/550 for Desktop TVout. But I guess more reasons could be found for 
such a bitmap.


Other related posts: