[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
Hi,
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!!
notes:
- 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
goal.
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
transfers
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
'counterpart').
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.
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.
Rudolf.
Other related posts:
