[haiku-appserver] nVidia hardware known options for new features (R2?)
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sat, 10 Dec 2005 09:32:17 +0100 CET
Hi there,
I've been thinking a bit more about what I think I can setup for you
once we add more functions to the graphics drivers. That is, I think I
know how to do it for all nVidia cards.
->I am already setting up the scaled_filtered_blit function.
We should add support for that function to work with offscreen (but on
card memory) buffers, this function can colorspace convert from 8bit
(NV10 and up), 15,16,32 and B_YCbCr422 and B_YUV422 colorspaces (all
cards) to RGB15,16 and 32: maybe also to RGB8 (NV10 and up).
->Maybe it's possible to setup some form of transparant blit: I don't
know yet.
->I _do_ know (since my 3D attempts) that I can get going on all nVidia
cards the blit function for offscreen bitmaps: but they have to be on
the grapics mem (but may be offscreen for sure!)
You should expect this:
->source and dest must be in same colorspace (unless you would use the
scaled_fitlered_blit version).
->the source has a starting adress (offset from cardRAM), but may need
to be aligned to a page_size defined by the nVidia hardware (probably
something like 16 bytes or so, but it differs per manufacturor so to
speak)
->The source has a width and height
->the source may have a slopspace: like it is also with framebuffers
(the desktop in for exampe 800x600 on older cards in B_CMAP8 (don't
forget about that ;-) is a good example. Also overlay bitmaps have the
slopspace thing as you know.
->Forget about what I set about blitting from main mem: I don't really
dare to say anything about that yet. Also when we are going to
doublebuffer windows offscreen It probably a bad idea to keep them in
main mem due to the large busload you'll create.
->What I want from the system is support for the page_size, and a
fullblown memory manager for managing all these bitmaps. The driver
should not have to think about that. The manager must also support the
overlay bitmaps. I have things like: user/system creates unequally
sized buffers #1, 2 and 3, then deletes 2, and then creates #4 bigger
than 2. What about the gap the old #2 represents? This stuff should be
the systems problem I'd say.
->The offscreen standard blit works quite simple: I need to issue a
2D_SET_SURFACE command inside the driver for each blit coming from
different sources. This command is quite quick as it does not involve
data transfer, and issuing it makes me very flexible :-).
->If you think it's perfectly possible to do the transparant window
borders and dragging using this scenario, then go for it (after R1).
->If this includes a guaranteed flicker-free cursor and it's dragging
bitmap: we can indeed forget about the hardware cursor. If not, I
suggest adding support for RGBA32 cursors in the interface, as modern
nvidia cards (all gf at least) can do that. Remember: this is a overlay
as well. That is, you can use the RGBA32 cursor independant of the
colorspace set for the visible workspace.
--
Note: While the current 2D features only work on colors (not alpha)
(RGB15 and 32 only of course), I think I know since my very first 3D
attempts that I can include the alpha channel for the commands. This I
cannot guarantee 100% yet though.
--
conclusion: all stuff I know for sure except:
-alpha channel including in commands (say estimate 75% chance I can do
it)
-blitting from main mem (say estimate 10% chance I can do it).
===========
Hope this will be enough to think about what direction to go. All
things described are 2D commands in fact, so independant of missing 3D
engine (init) info. And as it's been said that (what OS was that?)
already has support for offscreen bitmaps for window double buffering
(so composing desktop fully on card as you call it AFAICT) for ATI
cards that means we have ATI and nVidia covered.
Greetings :-)
Rudolf.
Other related posts:
