[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 
->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 
-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 :-)


Other related posts: