FreeLists / haiku-appserver / [haiku-appserver] Fwd: emails I changed with Rudolf

[Stephan Assmus <superstippi@xxxxxx>]

On 2005-11-15 at 01:10:58 [+0100], Adi Oanca <adioanca@xxxxxxxxx> wrote:

- - - - - - - - - - - - - - - - - - - -
Inline Attachment <Emails from Rudolf.txt> follows:
- - - - - - - - - - - - - - - - - - - -

Hi there,

>    I am one of the 3 developers working on OBOS app_server.
So, along with Darkwyrm and a third person?
>    I have some questions for you, if you be so kind to answer them...
OK, no problem. :)

>*) I want to make [HEAVY] use of gradients along patters in our app_server.
>One thing I want to know is, if I have a buffer of 100 colors(rgba) can the
>driver use those colors to draw a line? 100 pixels long of course. If not
>can a future driver do that. I am interested only if this can be done in 
ONE
>call, NOT by drawing a succession of points; so that hardware acceleration
>be used.
2D acceleration in a driver mostly works with rectangles only. The current 
BeOS supported hooks do this only (I am glad to report because _this_ is 
what's supported on most graphics hardare :).

Basically, the engine can copy pieces of framebuffer to other (overlapping) 
pieces of framebuffer. This framebuffer is that part of the cardRAM that 
you 
use to dump your data in that should be displayed directly, or in a virtual 
window.

Also the engine can invert rectangles, or fill them with _one_ color.

The BeOS fill_span acc function BTW is in fact a rectangle fill, with a 
height of 1 pixel.
fill_span only draws horizontal lines. with _one_ color.

Some engines (3D capable ones only I expect) can do a 
scaled_(filtered_)blit. 
This copy function destination may _not_ overlap the source. While a hook 
for 
this function was defined by Be, it's never used AFAIK.

It only has specific purpose: scaling video if no backend scaler is 
available 
in a card comes into mind.

I strongly advice _not_ to setup bitmaps inside graphicscard RAM in unused 
memory, and then wanting to hardware blit them onscreen. This is because 
most 
engine do _not_ see the RAM as being a linear space, but it works with 
_one_ 
workspace with a X and Y coordinate. It needs this to determine the 
'slopspace' that exists to the 'right' of a certain bitmap that should be 
blitted elsewhere.

You need to understand that in order to blit an offscreen bitmap onto 
visible 
screen, you _must_ setup a (large) virtual workspace, though the user 
shouldn't know about it. The offscreen bitmap (smaller than the visible 
fullscreen size for instance) needs to 'fit' into the offscreen part of 
this 
virtual workspace, adhering to it's bytesPerRow() for instance. The bitmaps 
would also need to be in the same colorspace as the visible screen.

While I _do_ understand why you ask these questions (there's been 
discussion 
before in the interfacekit list in the past about this subject), you would 
through away compatibility with a lot of hardware. The probable exception 
to 
this scenario are only the top brands 3D cards which can probably 
accomodate 
you better.

I say probable because you have to be aware that if you want to use more 
advanced engine features (which we are talking about to pull this stuff 
off) 
you would need documentation on those. You see Linux drivers (which are a 
_very_ important source of information) also mostly use 'normal' engine 
features, and manufacturors don't like to give you the specs either.

Personally, I have to admit I like 'the Be way' here very much. Keep it 
straight and simple please! Only use the 'mainstream' features to reach 
this. 
Though of course 'mainstream' gains more advanced features in time also. 
Which you should aim to follow up on I think. But don't try to use it all, 
or 
use hardware 'to the max' so to speak.
Probably most current 2D only capable engines can't do what you want.

For instance: a simple draw_line function. I expect you can only draw 
horizontal lines on most engines. Chances of an engine supporting vertical 
lines are smaller, while other orientations will be rare already.  Though 
nVidia cards can do that.

You should also be aware that those four functions used by the BeOS DANO 
and 
R5 app_server are solely responsible for the best part of acceleration you 
can get anyway. I mean, what's a line_draw compared to a screen_to_screen 
blit or a rect_fill data-amount wise?

One more remark: It is _not_ so that you can use the engine to access _any_ 
part of the screen. Workspace restrictions exists that are tighter than the 
RAM amount would allow in theory. You can do more pixels in height than in 
width though.


BTW: while reading my 'story' you have to keep in mind I am no guru here 
either. I might be mistaken on some things, or think to easy.. But then 
again: thinking 'easy' is what I'm best in, and it's what helps me keeping 
to 
find out and track down those bugs or unknown features ;-)
And what strikes me most, is that my straight and simple thinking seems to 
be 
_just_ the way Be implemented it (mostly). AFAIK of course.

----

So to answer your question: those 100 colors if they should be displayed in 
one line: should be written by software. No acc here. Not currently on 
BeOS, 
nor likely to be easily or at all implementable.

>*) currently, can I use a double buffering for the hole screen? 
No. The way for instance the pageFlipper demo app (or the Allegro game 
library) does that is by creating _one_ large virtual workspace, and by 
setting the hardware buffer pointer to the part of it which needs to be 
displayed (MOVE_DISPLAY). Note please that this works with X and Y 
coordinates: no linear space.
This way of doing things nicely adheres to the engine restrictions I 
already 
spoke about BTW.

You cannot create independant bitmaps on the card's RAM. There is no Be 
function for that.

In theory it would be no problem to do double or triple buffering for a 
normal screen (you ask this because you want to prevent tearing, or having 
to 
wait for retrace to do screen updates because it slows down everything 
drastically I expect.)

In order for a workspace to be created normally, that is as it is now, you 
have to do a few things though.
->you setup two or three (whatever) buffers with normal X, Y and 
bytesPerRow)
->you set the hardware buffer pointer to buffer 1. You don't have to wait 
for 
retrace because the driver should do that for you if needed (if it's not 
needed it's because the cards hardware already does this automatically)
->You init the acc_engine to work on buffer2.
->you blit or do what ever you want to do on that because it's offscreen 
(not 
displayed)
->you set the hardware buffer pointer to buffer 2 (driver takes carre of 
retrace sync again)
->you init the acc_engine to work on buffer1
->you blit in buffer 1 because it's offscreen.
->etc.

You need to init the acc_engine because of its restrictions, or the 
restrictions a lot of engines have. Blitting between both buffers because 
you 
want to do delta-updating only (speeds up everything: less bandwidth on 
bus, 
GPU and it's RAM needed) is not possible on a lot of hardware _unless_ you 
use the current way of doing things in BeOS (one large virtual workspace 
with 
MOVE_DISPLAY: really, it's nice having that the way it is!)

>Is 2D
>acceleration used for the backbuffer too???
No, since it does not exist.

>Can I blit a rectangle from the frontbuffer to the backbuffer, also by 
using
>2D acceleration? Can 2D acc be used for EVERY piece of memory allocated in
>video memory[used for backbuffering]?
OK, already answered that both. Be carefull about changing all this... I 
think it's a very bad idea for R1 at least.

>*) If I'll allocate 100x100x32 bytes directly into video card's 
memory(AFAIK
>this is possible, no?) representing a 100x100 bitmap, that memory can be
>used for *hardware[2D acc]* blitting onto frontbuffer(backbuffer too?) 
isn't
>it?
No, as already explained above ;-)

>*) where can I find a paper/book explaining the 2D part of a video card?
>also, if you can give me a link/book/paper for the 3D part I'd be highly
>grateful! :-)
It's hard to come by this documentation. In fact, I don't even have that. I 
use the experience I gained from working on those three drivers I did, from 
looking at Matrox register level specs, and from analyzing Linux Xfree 
drivers.

The VGA programmers manual I suggested (in my drivers howto) (Richard F. 
Ferraro: out of print AFAIK), the third (latest at least I think) edition 
contains info about a 2D engine.

Also another book I suggested here contains some information. It will tell 
you that the engine described (Being a representative example!) only 
supports 
those features (except screen_to_screen_scaled_filtered_blit) that BeOS 
already has defined. And nothing more. And keep in mind those restrictions 
the functions have I told you about!

>*) what did you do for Be Inc?
Nothing, apart from buying R4, R4.5 and R5 ;-)

BeOS _is_ the only OS for me because of a simple reason: it does everything 
simple, and straigtforward. _Whatever_ you look at in the BeOS: keep that 
in 
mind. They did things in a certain way because of a very valid reason, even 
if you can't see it at a specific time. Not just because it was convenient 
at 
a certain time or so. (exceptions granted ;-)

My experience is that if you start looking further and deeper into a 
subject: 
you'll find this time and again.

>Thank you,
>Adi.
You are welcome. Don't hesitate to call again. I'd like to do what I can to 
keep OBOS on the right track ;-)
After all, I don't want to loose the 'Be' type of OS...

Rudolf.

--------------------------------------------------------------------
Hi again,

BTW: About me saying _no_ to you being able to setup a independant bitmap 
in 
graphics card RAM:

There is _one_ exception to this rule: hardware overlay.
You (an app) can construct a bitmap with the B_BITMAP_WILL_OVERLAY flag. 
This 
will let the app_Server call the graphics driver to let the driver do 
memory 
allocation on the card. You may setup three bitmaps this way, so you can 
setup the so called 'double buffering' feature. Keep in mind that 
technically 
speaking, this is in fact _triple_ buffering!!

The reason for using an extra buffer is CPU time and  otherwise having to 
wait much more before  the onscreen buffer becomes offscreen (and so: 
available) again.

Be aware that _no_ other flag you can specify will create a bitmap in 
graphics card RAM. (Believe me: the driver would know about it _and_ have a 
function for that: it needs to manage it's own memory, especially when 3D 
comes into play!).

Using more than 3 overlay buffers is _never_ used ATM. In fact, my drivers 
have an allocation restriction of 3 overlay buffers. Which (in theory) 
could 
be lifted easily of course. )

Overlay uses another engine on the graphics card: the BES (backend scaler). 
This engine is totally independant of the 2D or (3D capable) engine.

This BES will colorspace convert, scale, and filter (interpolate) the 
bitmaps 
to be RGB24 (better 'known' as RGB32) before they are overlayed on your 
screen. Overlaying means it will _not_ be written into the graphicscard 
RAM. 
It will just be sent to the DAC, so monitor, whenever it asks for 
screenbuffer data in the coordinates the overlay 'occupies'. 

The overlay bitmap colorspace _all_ cards support (if they have a BES) is 
B_YCbCr422. This is probably because this space was defined and registered 
by 
nVidia (as FourCC space YUY2: see http://www.fourcc.org)

Some cards also support other spaces, like B_YCbCr411, or RGB16, RGB32. A 
nice thing about those overlayed bitmaps is that they don't need to be in 
the 
same format as the workspace is. It's no problem to display your Desktop in 
8bit colordepth, while the overlay input is in B_YCbCr422 or RGB16 (for 
instance), while the BES will show the output onscreen in RGB32!

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

OK. Of course the hardware cursor is a seperate bitmap also. This bitmap 
mostly is in a four color space (black, while, inverted or transparant) 
occupying 2Kb or 4Kb RAM. (the bitmap is mostly 32x32 pixels in size, 
though 
BeOS uses 16x16 only: the rest is just filled with transparant color).

Don't change this either: although _some_ cards are more flexible about 
this 
(nVidia can do RGB32 in 64x64 pixels, taking up more RAM of course!)

Be's cursor exists this way because it's supported on most hardware...

BTW: Those cursor bitmaps mostly are allocated in graphicscard RAM, though 
_some_ cards have it in a special, in a serial fashion accessible, 
registerRAM. Hence the need for a driver function to set the bitmap, 
instead 
of some app or the app_server just dumping it directly in cardRAM...

The cursor is also an overlayed bitmap, although it cannot be scaled and 
such.

Best regards,

Rudolf.


-------------------------------------------------------------------------
Hi there,

>    Wait a second... I'm missing something. What happens when BeOS is
>playing let's say... 5 videos at a time, each using triple buffering?
Not possible. The first instance of the mediaplayer in use claims the 
overlay 
hardware, and creates three buffers for it. The properties will tell you 
it's 
using overlay (VLC, mediaplayer)

The second instance cannot claim the overlay unit as it's already in use. 
the 
bes can only be used for _one_  video output at a time. The second instance 
of the mediaplayer must fall-back to bitmap output mode, and uses three 
input 
bitmaps for double buffering. This time the bitmaps are in main system 
memory, _not_ in the graphics card memory.

The third instance must do the same.

Check it out: you'll find this is working nicely, in the way it should ;-)

The total picture is even somewhat more complicated than this.

Let's say you want to create a mediaplayer. You want to do this:
->try to setup three buffers for overlay use. OK? use it as double buffered 
overlay. Fail: next step:
->try to setup one buffer for overlay use (you already know from the 
previous 
step if this can be done ;-). OK? use it as single buffered overlay. Fail: 
next step:
->use bitmap mode in double or single buffered mode.

The reason for sometimes just one (or two) overlay bitmaps succeeding in 
creation, is lack of graphicscard memory. Happens a lot on notebooks. (For 
instance my neomagic notebook has 2Mb RAM, Could do triple buffered MPEG1 
(384x288), single buffered DivX(640x480), bitmap output DVD. (720x480 or 
720x576)

The exact 'moment' for not being able to create those overlay bitmaps 
depends 
on desktop colordepth and virtual resolution of course. (memory management 
inside driver takes care of determining all this.)

One important thing for use with overlay bitmaps is this:
You (app) may _never_ copy a bitmap pointer to another var. You _must_ use 
the original pointer. When the user changes desktop resolution for 
instance, 
the overlay bitmaps will be destroyed by the app_server, the mode will be 
set 
by the app_server, and then the app_server requests new overlay bitmaps 
from 
the driver. However, the order of asking for bitmaps can be different than 
the app did this before, so the bitmaps get swapped in memory. Also they 
can 
be on a different adress, or they may not even be created at all.

The app, if using copied pointers, will segfault or produce a mess 
onscreen. 
It may use copies I expect, but then it has to monitor for screenprefs 
changes to re-copy the pointers.

BTW, changing workspaces also lets the app_server kill the overlay bitmaps, 
set the mode for the other workspace, and re-aquire the bitmaps with the 
driver. This succeeds if RAM is available, but again, the order of the 
bitmaps and the occupied adresses may vary.

Faults with using copies were done by VLC in the past... (I have been 
monitoring them since a long time, and every now and then I have to set 
them 
straight ;-)

One thing I am not entirely clear about: there should be some sort of 
semafore system to prevent the app_server from deleting a buffer while an 
app 
is in the process of writing it. Thomas Kurchel says (to my best knowledge) 
that this thing does not exist in BeOS, but he insists it should: think 
about 
3D! You have a large amount of 'bitmaps' floating around in graphicscard 
RAM 
then, which may or may not be 'swapped out' by the driver as it needs the 
ram 
for more frequently used ones (speed optimisation)..

If you use the DLL wrapper DivX codec with mediaplayer, you'll notice 
mediaplayer crashing every now and then on workspace switches: this must be 
the not implementing locking/semafore system: at least in the codec.

Do you think the bitmap->lock() and unlock() functions are the method to 
make 
sure they are mutually exclusive accesible? Thomas said this is how it's 
done 
in Windows. Of course (for 3D) the pointers to the bitmaps may be changed 
on 
any time, so this locking mechanism is _very_ important there and then...

-----

OK, here's another one. BeOS accelerant hooks are layed out in such a way 
it 
is possible for hardware to have more than one acc engine or backend scaler 
(overlay unit).
You can ask the driver the number of units.

While Thomas and I never say a card that has either of this, Be foresaw 
that 
this could happen, and I think they are right about that.

This is an area I want to experiment with in the (near) future: I expect 
the 
nVidia GeForce cards just _may_ have a possibility to use the (single!) bes 
for two movies at the same time. I am going to try to implement that in the 
driver later on, of course modifying the overlay buffer restriction to be 6 
bitmaps then.

If BeOS support is really complete, we should be able to start two 
instances 
of the mediaplayer using overlay, while the third falls back to bitmap 
output.

>    Fascinating! :-) Really!!!
I think so too. It's been (and still is) a great adventure for me to find 
this all out :) For instance I can hardly wait to do dual overlay 
capability, 
or start tweaking with 3D (once I learn enough about that _and_ still have 
spare time)...

>    Cursor is one thing I know for certain it will be changed!
>    DW has decided that long time ago! And I think he wants a 32x32 RGB32,
>for R1! Is that supported on most cards?
No: trouble!!

You see: DW does not really know what hardware can or cant do: BeUnited 
warned me about that.
Unfortunately DW and I are apparantly not able to communicate 
professionally 
about this technical stuff. While he's a nice guy, and the few 'talks' we 
had 
were nice, he systematically stops responding to my mails once they get too 
technical.

So, please: keep an eye on where the app_Server is going!

>    I haven't discussed with him, but can he do that with the current
>drivers???
No again. just the 4 color cursors in 16x16 res.

Though 32x32 can be done on most (maybe even all cards) _but_ the drivers 
need to be updated for that as well.

You have to be aware of another hardware restriction which Be R5 and DANO 
do 
wrong (still can't pinpoint if I can influence that somehow within the 
driver: setting the app_server straight I mean).

You have a 'hot' position within the cursor bitmap. This is used so for 
instance a 'wheel' shaped cursor can have the hotspot in the centre of the 
wheel so you click exactly right on an item (know what I mean??)

This is a nice feature, but it does not check for bounds!!

Let me explain: Some cards (Matrox) have the reference point of the cursor 
bitmap at the right-lower corner. Some (most I even think) other cards 
(nVidia, neoMagic) have this reference point at the left-top. While the 
app_server should not be concerned about that (the drivers correct this 
internally) this _has_ influence on the behaviour I will now outline.

OK. Now there is a hardware restriction which says: you may _never_ place a 
single bit of the cursor bitmap (so 32x32..) beyond the left or top of the 
screen! If you still _do_ that, the cursor will magically dissapear 
immediately as a whole.

This means that the app_server should redraw the cursor bitmap once it's 
going to overlap those boundaries: so clipping the bitmap while moving the 
remaining part up and/or to the left within the bitmap space. Also it has 
to 
modify the 'hotspot' given to the driver accordingly.
If this is done, the user thinks the cursor is partly offscreen, while the 
hotspot still applies.

This requirement does not exist for the right and lower part of the visible 
screen BTW, on all cards. This is because of the way the hardware works 
internally:

The cursor position is determined locked to the monitors horizontal and 
vertical retrace signals (syncs). The cursor hardware has counters which 
count what part of the screen is currently 'drawn' on the monitor (this 
works 
serially: one pixel at the time (cathode ray scan: CRT you know? LCD's 
still 
get the data that way also BTW)

The counters start running (reset) when the screen is drawn, and can only 
be 
positive. Hence: a negative position is in fact a very large positive 
postion: very low, or very much to the right, being offscreen definately!

Some cards (Matrox) still have a positive value if the bitmap is partly 
offscreen (right-lower corner is ref point!), while most others immediately 
go negative (left-top corner is ref point.)

So, you have two options here:
-> always do clipping in the app_server software OR
-> ask the driver if it can do something negative. If no, software 
clipping, 
if yes: hardware clipping in driver.

This would mean an extension to the Accelerant hook thing.

Well, you get the picture ;-)

You see, you app_server guys _need_ to know what hardware can and cannot 
do! 
(Thanks again for mailing ;-)

>One last thing.
>    We decided that after R1 we should have an implementation of OpenGL, 
and
>then an app_server based on OpenGL.
Ah. Very interesting subject! ;-)

I am a beginner here, though I am collecting info and bits and pieces about 
the generally needed setup. You should ask Thomas Kurchel also about this 
subject: he once wrote his own 3D game engine! (so no driver, but he must 
have a better idea about the 'interface', as you can already tell from what 
I 
just wrote down about bitmap locking().

For 3D, you need:
->AGP motherboard chipset drivers, to setup the GART (whatever that may be: 
ask Thomas: he fiddled with it already!)
->The drivers need to enable AGP mode: the current drivers use PCI mode 
(AGP 
is 'just' an extension to PCI)
AGP mode means enabling 1X, 2X, 4X or 8X transfer (speed) mode, and 
enabling 
SBA (sideband adressing). The items meantioned here can apparantly be done 
100% within the graphics card driver. Ask Thomas though.

The above two things are needed to let the card access main system memory 
to 
fetch and/or dump those more often used and/or not soo often used anymore 
bitmaps to/from grahicscard RAM (GART I think). Because you need all the 
speed you can get here (bus== bottleneck otherwise you need to enable AGP 
modes.

Now you can setup hardware 3D support which will actually speed things up 
drastically. (without those AGP things you can still setup hardware 3D 
support, but with a serious speed penalty. Nice for testing already 
though..).

What I just now heard (a few times ;-) is it works like this:

->You have the apps and the system.
->You have the graphics card driver below this;
->You have MESA (software openGL) below this.

What happens is that the driver monitors the MESA calls. If it sees calls 
for 
things it can do in hardware it intercepts it and does it. I suspect the 
monitoring by the driver is nessesary as it needs to be informed about 
_everything_ that is happening. It's a (serial) pipeline after all, and 
also 
you have the extensive memory management facilities needed in the driver( 
again: ask Thomas about his thoughts here: his ATI driver has more of this 
already (better framework I guess: centralized management) than I did for 
my 
drivers (implicitly, decentralized management for every function yet)

OK. The funny thing is 2D acc works the other way around BTW!
You have:
->The apps
->the app_server
->the driver.

The app_server (which is software) draws inside onscreen bitmaps for apps 
(unless they 'dump' data directly into them themselves of course). A window 
has a background color, just like the desktop (both setup with a function 
called rectangle_fill. 
If you have a window with a list view of files for instance, while the 
window 
only displayes part of the contained files (window is too small to show 
everything), you see file by file being (software) drawn in it (fast!). If 
the drawing program (tracker?) determines it needs to fit in a file 
(Because 
it's shown alfabetically, while the order of drawing is _not_ 
alfabetically), 
it uses a function called blit to move the already shown file lower 
onscreen 
withing that window, so space is created in which it can software draw the 
next fileentry that goes in between.

OK. The app_server determines how the drawing proceeds. It asks the driver 
for a blit hook and a rect_fill hook every time a new mode is set. The 
driver 
has the option to give that or not (except for synchronisation hooks), 
depending on if the driver can do it in hardware for the mode set.

If the app_server is instructed to blit by tracker in this example, it will 
do it itself in software if it got no hook from the driver, otherwise it 
relays the command to the driver.
Same goes for all other acc function hooks.

You see the driver is at bottom of the chain for 2D acc, while it sits 'in 
the middle' for 3D acc.

BTW: the hooks for overlay are also re-aquired by the app_Server after 
every 
mode switch. In theory I can prevent the app_server or apps use overlay if 
I 
don't want that for a mode. The apps will be instructed to fallback to 
bitmap 
mode then (via the API which should be extended here BTW: Be never 
completed 
that: overlay is setup 'experimentally' (could also explain bitmap 
locking() 
not being in place if that is so))


-------

Now I want to say one thing about the cursor: Strangely enough the 
app_Server 
requests these hooks from the driver only on startup. _Not_ after every 
mode.

This really is a shame: it would give me the option of preventing the 
app_Server from using the cursor in modes I cannot do it (Matrox dualhead 
stretch modes: the second head has no cursor hardware), while I _would_ be 
able to use it in singlehead modes (BDirectWindow Windowed mode needs 
this!! 
I can explain why BTW ;-)

The software cursor is being generated inside the app_Server if it cannot 
aquire the cursor hooks from the driver.
Which brings me to a fault in the current R5/DANO app_Server: if you set a 
virtual mode, the app_server misses the MOVE_DISPLAY functionality. It 
really 
should do that. Explanation:

On harware cursor use: the driver itself calls MOVE_DISPLAY within the 
MOVE_CURSOR routines when ever it's needed. Because on software cursor use 
the cursor hooks are not exported, the driver knows nothing about the 
software mouse position. The app_server should monitor that and call 
MOVE_DISPLAY if needed!!

(Strangely enough this _does_ work in failsave B/W video mode. Did you know 
this are in fact R3 graphics drivers being at work?? (being app_Server add-
ons)

OK, OK I'll shut up ;-)

>    Will it be hard for you guys(driver developers) to provide drivers that
>have support for OpenGL 1.4 ?
Thomas can pull that off _if_ MESA is in place I would think. Ask him 
though...

I can do it just maybe as well: got MAtrox docs, got nVidia 'pointers' 
(bits 
and pieces of info) which might get me into action. I could use Thomas as 
an 
example implementation very much though...

BTW: It's been said R5 has everything in place as well! There are just no 
drivers for it. (would make sense regarding how the stuff is layered 
(driver 
being in the middle, software GL under that ;-)


BTW2 ADI: Can I rely on you to make my mails known in the openBeOS 
'community' as far as is needed according to you? I'd hate to write this 
more 
than once... Thanks!


Best regards,

Rudolf.


-----------------------------------------------------
Hi again,

I am trying to keep up here ;-)
Currently I have a few extensive technical 'threads' going though I'm 
afraid. 
While I don't mind that, writing these Emails really costs a _lot_ of time.

Yesterday I though to myself: Why, if Adi lived in the neighbourhoud, I'd 
better just drop by and drink some coffee with him. Talking really saves a 
lot of time compared to the slow 'input' of writing...

Anyway: don't worry, I should answer all your mails.. Unless I drown so to 
speak or loose some mail in the 'large' inboxes by now.. :-/


BTW: What comes to mind ATM is the cursor thing: You told me you did not 
see 
a reason for both clipping _and_ updates on the hot position.
You did not understand me completely I'm afraid, as _both_ are needed..

With clipping here I mean: the say circle shaped cursor should be rewritten 
in the bitmap with only the lower half in it when it's upper half should be 
above the visible screen. With this I mean that it should be written 
'higher' 
in the bitmap: in the upper half's memory! So this means the hot postion 
changed also by this amount of vertical pixels, and should be modified 
accordingly.

In the driver code, the internal cursor Y and X coordinates may not become 
negative. As the hot postition is subtracted from the actual position 
(Which 
runs down to 0,0) this is currently not quaranteed. In practice you mostly 
see the hot position being 2,2 in the 'hand' (being the finger, which is 
not 
placed at the exact 'border' in the bitmap area). I had to restrict the 
nVidia and neoMagic driver to 0,0 internally to prevent loosing the 
cursor...

Of course, I'd like it better if we could think of some other solution that 
gives the same effect without all this 'tweaking' in the driver and 
app_server combined. I can't think of another solution though :-/

Hope this clears this. If not, don't hesitate to let me know ;-)


Talk to you later!

Rudolf.

----------------------------------------------------------------------------
------
Hi again :)

>    Yes. Why the question mark?
I was just curious who the third person is :)

>> Some engines (3D capable ones only I expect) can do a
>scaled_(filtered_)blit.
>    Can you explain more? Is it used when BES is unavailable? Won't this
>affect performance?
It's never used AFAIK. The app_server does not ask for it's hook for 
instance. 
I was just stating a possible use, _but_ only for fullscreen video in a 
BWindowScreen style workspace, as copying needs to be done from an ever 
offscreen to an (sometimes:double buffering) onscreen area somehow.

It can only be used fullscreen because it works with rectangles also. Other 
windows or dropdown menus and the like would get overwritten.. (this is no 
overlaying method)

>    OK. Got that! That brings me another question: What stops me from
>requesting a virtual screen that uses almost all video card's memory? so
>that I can have many, many offscreen bitmaps.
Nothing :)
Expect to loose acc_engine cabability though. Which brings me to this: 
display_mode.flags has for instance b31 defined as "B_SUPPORTS_OVERLAYS" 
(Be 
overlay header file)

I can imagine it would be handy to have a B_SUPPORTS_ACCELERATION flag as 
well. say bit 30. A user could ask proposemode if a certain virtual screen 
size would still have acceleration in a mode. Currently the user has to 
actually set a mode, and then try to get the hooks. IF that fails, it knows 
it has no acc capability.
Also: The Matrox engine for instance has seperate max. settings for 
different 
acc engine commands. RECT_FILL, RECT_INVERT and SPAN_FILL can use upto 16MB 
,while blit  can use more. It can happen you set a mode that:
-has full acc;
-has partial acc (blit only)
-has no acc. (my drivers: Be's drivers limit all cards to 2048x2048 
screensize, which is always accelerated. So this problem does not exist in 
practice then).

--

Be aware though that setting the max virtual workspace will prevent you 
using 
overlay. Overlay needs RAM to place (three) bitmaps of it own.


>    YES! for 4 years nVidia ATi and Intel were the ones that occupied more
>than 90% of the market. Use their advanced features we shall! I don't think
>we'd loose compatibility... there is software emulation! :-) ... there is
>the almighty "switch"! :-)))
OK. I can understand one wanting to go that way. Though personally I am not 
very fond of it (work, work, work, and costs time, time, time... R2 people!)

I hope someone can get it to work in the drivers all-right. Would be nice 
;-)

Forget the non-RGB32 cursor also then: just switch, just like for clipping/
non-clipping cursor capability ;-)

>    PLEASE, enumerate the "normal" engine features, for me to have a big
>picture! thanks!

->screen_to_screen blit
->screen_to_screen_transparant_blit (never exported, so never used)
->fill_rectangle
->invert_rectangle
->fill_span

That's it.
The last defined one in BeOS is:
->screen_to_screen_scaled_filtered_blit. (never exported, so never used)
This function in fact uses a 3D feature: the texture engine.

The function blit and rectangle can both be given a 'pattern'
We use 'invert', 'fill' and 'transparant. 

There are maybe 16 pattern that can be used though (see it as things like 
AND, OR, XOR, CLEAR, SET and such)
All functions use rectangle shaped areas.

>    Be Inc. disappeared 2.5 years ago, BeOS R5 has 4+ years, Riva TNT2 is
>now GeForce5 *very* soon 6; did the mainstream gained more features?
Shall I send you a nVidia header file? Though it's a NV10 file (more or 
less 
complete AFAICT), you'll get the picture. (NV10 is GeForce256)

Be warned though. If you want to see more or less what's all in it, you'd 
better take some time off. (1Mb in size)
Say 2/3'd of the file _just_ described the acc engine.

The last half of the file describes the acc engine commands. While I'd like 
to get a crack at it, I have to tell you I give you only a (very) small 
chance I succeed in understanding enough to get basic 3D up and running. 2D 
only things are simpler, and I suppose it would be relatively easy to add 
16 
more to the 8 or so already setup (sub) commands for that.
(nVidia has seperate command for setting the pattern, setting the workspace 
size (clipping region) and doing the blit for instance. All three together 
is 
_one_ BeOS command screen_to_screen_blit. You need to have all parts 100% 
correctly in place to get it working. Otherwise: system locks up.)

2D extension alone is already going to take months probably though!

>    Rudolf, mate, some things get old, they are still good, but technology
>doesn't progress in vain! :-)
OK, but R2 or later I'd say. Of course you are correct here, but I still 
think you should not 'burn your fingers' on it for R1.

>    I'm sorry but, that's exactly what I aim!
Then you are in for trouble as the last few percent will be manufacturor 
specific, and nolonger 'generally useable'. I expect: remember, I am no 
guru.

>> Probably most current 2D only capable engines can't do what you want.
>    Then... restrictions... software emulation.
Then also: slowness. Suddenly I have to think of Windows.. ;-)

>    So how do you know that? From where did have the specs? Can I have 
them?
>:-)
OK, including header file. Please, try to get an idea of the avaible 
commands 
yourself if you can. I never looked further than I needed to do (apart from 
some very quick looks): that's enough of a challenge as it is already!

>    If you say Linux, then, again how? nVidia divers for Linux are 
binaries.
No. Manufacturor supplied drivers are. Those are _not_ included in the 
distributions. Check out the XFree86 sourcodetree, you'll find open source 
drivers there.

On a sidenote, I just checked RedHat compatibility for nVidia cards. TNT1-
GeForce3, 2D only. In fact, my driver goes further already apparantly ;-)

>    What do you mean by that comparison?
compare the data-amount that have to be moved for both. It's almost nill 
compared to very much.
Unless of course computations have to be made for non horizontal and non 
vertical line. (can't remember the english word for such a line :-/  )

>OK, another questions:
>    Does Linux's XFree:
>        1) use double buffering?
>        2) use a virtual screen?
>        3) handle offscreen bitmaps?
No,
no, and
no AFAICT.

The BeOS drivers are _much_ better defined. I have spent considerable 
amounts 
of time just testing for actual limitations so I can setup those virtual 
modes correctly for instance. This info cannot befound elsewhere (no header 
files, no linux sources or comments: they just 'don't care': A linux user 
is 
supposed to be technical. He or she should not set a mode that does not 
work. 
We however, (should) try to free the user from that burden. Hence my 
precise 
work on this.)

>Thank you for your help!
You are welcome.

OK: Got to sign off for tonight! The other mail(s) will have to wait a day 
or 
two more :-/

Best regards,

Rudolf.

-------------------------------------------------------------------
Hi there Adi,

Sorry about the delay: I am doing my best to keep answering all my mails 
_and_ do some coding in between. It's hard sometimes though due to large 
amounts of mail, or real life :-/

Anyway, here it is ;-)


>> One important thing for use with overlay bitmaps is this:
>> You (app) may _never_ copy a bitmap pointer to another var. You _must_ 
use
>> the original pointer. When the user changes desktop resolution for
>instance,
>> the overlay bitmaps will be destroyed by the app_server, the mode will be
>set
>> by the app_server, and then the app_server requests new overlay bitmaps
>from
>> the driver.
>    What about that data that those 3 overlays contained?
>    BTW you were referring to the value returned by BBitmap::Bits(), isn't
>it? not BBitmap pointers!
Yes, you are right. It's the pointer returned by that function. As the Be 
Book says:
"Returns a pointer to the bitmap data"

So it _is_ a pointer. Which is should be I guess, as a pointer can be 
changed 
to point to another adress.
A copy of this pointer can _not_ be changed by the system however.

>    Help me here a bit! The system has linear memory space, where does
>graphic memory fit in? How can that be accessed? Does the OS kernel maps
>graphic RAM somewhere? 0xC000? If OS kernel with its virtual addressing 
does
>that, and if  graphic RAM be mapped by it, AND if  the system has the max 
of
>RAM 4GB, how can video memory be addressed?
The graphics kernel driver uses a function called map_physical_memory() to 
map the areas in the cards (that are mappable) itself, to look like there 
in 
main memory. Once you mapped areas, you can access them as if they were RAM 
in the mainboard. this is called memory mapped I/O.
You can map areas with no user space access, read only, write only or full 
access.

The old ISA cards that use memory mapped adresses below 1Mb are not really 
useable by BeOS AFAIK. Those cards used the adres you mentioned indeed. The 
current cards however are just mapped 'somewhere convenient' into the 
complete 32bit adress space AFAIK.

If you would literally have 4Gb RAM in your system, I guess mapping cards 
will fail, or some of the installed RAM has to be disabled. The 4GB space 
is 
shared between RAM and devices.

Mapping applies for all graphics cardRAM, and most registers in the 
chipset. 
Some older cards are partly 'PCI' and partly 'ISA': those can map the RAM 
to 
memory, but not (all of) the registers. Registers that cannot be mapped to 
memory will be accessed by the accelerant via kerneldriver calls. The 
kerneldriver uses the ISA and/or PCI I/O functions to access those 
registers 
in this case. This also applies for PCI config space registers that might 
be 
needed by the driver, _if_ they are unmappable. If they _are_ mappable, 
that 
means they are both accessible from PCI config space (which is _not_ 
mappable 
directly), _and_ they are accessible in the same way the normal mappable 
registers of the card are. If you map that area, you also map the PCI 
config 
space registers for that card then.

>    To answer your question: No. BBitmap::Lock() and Unlock() do EXACTLY 
the
>same thing as BWindow::Lock()/Unlock() because they actually call BWindow's
>methods.
Here you have to help me :-/
Can you explain in just plain english (for dummies in this case) what these 
functions are used for? It's unclear to me.. :-/

>    There are 2(undocumented) public methods in BBitmap's class 
declaration,
>witch I can't test right now:
>         status_t LockBits(uint32 *state = NULL);
>         void UnlockBits();
>    I don't have a disassembly of libbe.so either, but, I bet it sends a
>message to appserver to acquire an internal semaphore, status_t returning
>B_OK if successful.
>    I don't know for sure!!! Try it! :-) In fact I'm asking you to, you 
made
>me curious! :-)))
I am very curious too: that's why I forwarded this snippet of your mail to 
Thomas Kurschel (ATI driver) as he has the best chance to figure it out. 
Although he is a lot more busy than me with real life, I asked him to mail 
you about this anyway, and keep me informed also.

I did not yet receive a reply about this, so I'll just wait a bit more for 
it 
;-)

>    Thanks for explaining! Really! You wrote quite a few stories in those 3
>emails! :-)))
You are welcome! :)

>ago, I read all Microsoft had on DirectX Graphics back then, as well as
>numerous articles on the net over those years, closely following progress 
of
>graphic hardware. Unfortunately, I haven't done performance with it! yet!
>:-) :-(.
I can see how you can have mixed feelings about that ;-)

>> ->You have the apps and the system.
>> ->You have the graphics card driver below this;
>> ->You have MESA (software openGL) below this.
>
>    Nope! I don't think so. The order is the same:
>        app
>        MESA
>        driver
>
>    What happens is: OpenGL looks for a feature in driver, if it finds it,
>uses it. If not... software emulation.
>    90% sure. At least that's how I remember! :-)
Hmm. Could be. I was just 'quoting' what I've been told by some 'anonymous' 
user. Maybe you could ask Thomas about this.. If he has something to say 
about it, I'd like to hear it as well...

>    :-) I know... remember... I work on the server. :-)
Aha: so this is already in place then? ;-)

>code for OBOS's app_server? Yup! Me! :-)
I suppose it _is_ fun to setup this important part of the system ;-)

Anyway, I just told you this because I happened to monitor this. I am glad 
you recognize it ;-)
Another thing is that the app_server only aquires the acc engine to do a 
command list (one command with a list of arguments). The app_server then 
releases the engine only to acquire it again if it wants to use the engine 
again (apparantly). So it owns the acc_engine every time only over a very 
short period of time.

Just telling because I monitored it. I guess it's important for the obos 
app_server _not_ to aquire it and just keep it ...

>    Assuming mode="resolution change", I don't think the driver can bilt a
>portion of the old resolution into the new one!! Or CAN it?!?!? 8-|
'Simple' engines cannot, while those 'advanced' 3D cards might be able to 
do 
it. I _think_ I saw something regarding this somewhere, but I am not sure.

This means the engine would need to be told (just guessing a bit):
-> the old space
->the new space
->the old bytes_per_row,
->the new bytes_per_row,
->the rectangle source coor and size,
->the rectangel dest coor.

Of course the RAM those old and new screens reside in, must be not too far 
apart. I suppose they possibly may overlap in theory.

Anyway: for R1 I wouldn't try to do this, you are again talking about 
engine 
commands rarely used on linux XFree AFAIK.

>> Now I want to say one thing about the cursor: Strangely enough the
>app_Server
>> requests these hooks from the driver only on startup. _Not_ after every
>mode.
>    So you want that on a resolution change the following hook to be 
called:
>typedef status_t (*set_cursor_shape)(uint16 width, uint16 height, uint16
>hot_x, uint16 hot_y, uint8 *andMask, uint8 *xorMask);
>    ?
this is _already_ the case I expect. set_cursor_shape is called numerous 
times.
I meant this:
void * get_accelerant_hook(uint32 feature, void *data)
for:
(SET_CURSOR_SHAPE);
(MOVE_CURSOR);
(SHOW_CURSOR);

(this is also the way it happens for the acc engine commands (monitored the 
actual acc_hooks. Did not yet look at acc sync hooks.. I think those are 
not 
re-exported (re-aquired or what ever you'd call it :) though) , and the 
overlay commands BTW)

>> BTW2 ADI: Can I rely on you to make my mails known in the openBeOS
>> 'community' as far as is needed according to you? I'd hate to write this
>more
>> than once... Thanks!
>    I think only DW, Gabe and Marcus should know about this. I see no point
>bothering other people.
OK. That's what I meant :-)

>> Unfortunately DW and I are apparantly not able to communicate
>professionally
>> about this technical stuff. While he's a nice guy, and the few 'talks' we
>had
>> were nice, he systematically stops responding to my mails once they get
>too
>> technical.
>
>    One reason may be you explain how stuff works. :-) I'm under the
>impression that you are a guy that thinks with 1) 2) 3) ... You also are
>very direct! Although you DO explain ALL there is be known, you do it in a
>way that make people dizzy! :-) I'm having quite a time understanding what
>you want to say, only on the second/third reading really understanding what
>you meant. Try to sound a bit clearer, especially because we're discussing
>technical problems. :-) Please don't mind! :-)))
I guess you are right about me. I just create a waterfall of information :-)
I understand that can make people dizzy, but I do it also to 'protect' 
myself 
against forgetting to tell you important 'related' things that come into 
mind: I might just as easily forget to mention them alltogether if I don't 
just spill them.

I guess I am kind of hoping you take the time to 'order' things for me in 
your head or in some doc., and come back on subjects that need extra 
explanation. This way I know you already know about some things that 
otherwise might be forgotten.

Also, you probably need to keep in mind, that what I tell you about those 
engines will be somewhat biased at the least: If I hear you talking about 
using a whole lot of new acc engine functions in whole new ways (for non-
Windows that is) I see a huge pile of work coming this way, which I 
honestly 
don't know if I want to even try to get it working because of the amount of 
work required.
Thomas and I sometimes talk a little bit about 3D in the drivers, and the 
general feeling is we are already tired of 3D before we would even begin. 
The 
clearer the picture gets about what needs to be done to get it working, the 
more tired we already become. This is due to understanding/seeing what the 
amount of work is that we would need to do :-/

I _do_ thing it would be nice to see double buffering (or whatever you'd 
call 
it) in BeOS, so we can prevent tearing.

I've been thinking about it a little, and it seems fairly simple to setup:

->create front and back buffer
->draw in back buffer by app_server and apps
->during retrace, blit back_buffer to front buffer.

That would mean you use the current buffer as backbuffer, so you only need 
to 
'add' a frontbuffer, and implement blitting to it during retrace.

Both simple tasks to do (as long as those buffers are in fact one large 
virtual workspace: in height), and it _could_ be done inside a driver 
without 
BeOS or the app_server even knowing about it!

The hard part is getting the blit to work during every retrace: How do you 
make sure you can 'squeeze' it in between app_Server and/or app_commands? 
Or 
do you need some kind of app_server sync to get this going reliably? If so, 
then the app_server _does_ need to know about it after all..

Anyway: this is a subject I am going to look into myself someday, as Matrox 
TVout on G450/G550 relies on the same trick! In windows the driver does 
this: 
the downside is you see the 'updates' rate on TV dropping to about 4 times 
per second on heavy acc_engine load for 3D or 2D.
This needs to be overcome in order to be usable I think... (Both for TVout 
and double buffering the normal framebuffer)

Best regards,

Rudolf.

---------------------------------------------------------
Hi again,

>I didn't followed closely the thread on R3 legacy drivers, so don't mind me
>asking a simple question:
>    For R5 and OBOS R1 we should use ONLY Accelerant.h ? GraphicCard.h is a
>reminiscence from R3, isn't it? we shouldn't we that, don't we?

GraphicsCard.h is the interface used for R3 graphics drivers. It's still 
used 
in a few spots.

-------

Spot 1:

For applications and the API only BWindowScreen is of importance. Have a 
look 
at the BeBook for R5 for BWindowScreen. You'll find many references to the 
file GraphicsCard.h.
In every case were structs or functions are used that are based on this R3 
interface, BWindowScreen must do translation for R5 drivers. You have to 
tell 
_me_ if BWindowScreen is part of the app_server. (Is it?)

AFAIK Jack Burton (Italy) is working on the implementation of 
BWindowScreen. 
Does that mean it's _not_ in the app_server?

OK: In order to do the translation, BWindowSCreen loads a clone accelerant 
'privately'. It asks the acceleration hooks from the accelerant _if_ they 
are 
requested with BWindowScreen's CardhookAt() function. So if only blit() is 
requested, the fill_rect() hook is not requested (Of course this is a 
detail 
not very important: it doesn't matter much if a obos BWindowScreen just 
asks 
for all the hooks at once I think, apart from maybe a little speed slowdown 
if so.)

A difference for example that the acc hooks had in R3 compared to R4/R5 is 
that in R3 you can only send one set of arguments to the command, so for 
one 
acc engine execution pass. These days you can send a list of argument sets, 
so the engine can be told to do a lot of blits in one call.

Besides the CardHookAt() function, also some information functions such as 
FrameBufferInfo() are still R3 style.

Things like: CanControlFrameBuffer() and MoveDisplayArea() are R5 style 
already and don't use the cloned accelerant for interfacing to the driver. 
They work directly on the primary accelerant.

In order to test for yourself what functions use the clone, just disable 
cloning ability in the accelerant (let it fail). You'll see which part of 
BWindowScreen still works, and which part doesn't. This situation (failing 
cloning) was happening on all non-be drivers upto now!

Matrox driver 0.15 (in the works) will fix this, and the newest ATI driver 
will fix this also (Thomas made the same mistake I did: we spoke about it). 
Also the nVidia and NeoMagic driver fail ATM.
The reason is a mistake in the R4 graphicsdriver kit Be released, though 
being alpha quality.
(There are tens of mistakes in there BTW.. I found more in the past.)

--------

Spot 2:

If the app_server determines there is no R5 graphics driver on the system 
(user or system folders), it will fall back on VESA (if preselected: in 
fact 
VESA is already running then even _if_ supporting drivers are found, but 
you 
mostly won't notice as a complete driver overwrites everything the VESA 
call 
programmed in the card).

If no VESA was preselected, or VESA VBE2.0 is not supported on the 
graphicscard at hand, the app_server falls back to the B/W fail safe mode 
you 
will know.

OK. Here's the 'nice' part: One thing almost all cards (still) have in 
common 
is the standard VGA modes from the old days. You can write an almost 
generic 
driver that can set such a mode on all cards that exist: using the ISA I/O 
and Memory space (The 0xA0000-0xBFFFF window for 128kB graphics RAM (paged 
if 
needed) (The VGA BIOS resided at 0xC0000-0xC7fff mostly and will not be 
used 
I expect.)

Unfortunately not _all_ cards apparantly behave nicely, so you still need 
some seperate drivers to catch them all.

In BeOS R5, the app_server falls back to those drivers which BeOS has. 
Unfortunately, these drivers are still R3 style! These are add-ons to the 
app_server, and you'll find them in the add-ons/app_server/ folder.

(I think) these drivers are pure kernel drivers. (can you tell me? I am 
curious...). On most systems, the 'supervga' add-on will be loaded. It 
selects 640x480 VGA mode in 16 colors via a palette. The palette is 
programmed in such a way that grey tones are created, so we at least have 
16 
usable tones (instead of just a few per color).

(I think) the app_server takes care of 'publishing' the dev/ hierarchy name 
'stub', to present an R5 compatible interface to the loaded R3 add_on.

The stub.accelerant at last is used to interface to the 'stub kernel 
driver' 
so we have the whole thing running.

->Of course I think we should not want to use this old stuff anymore. It's 
no 
problem to create a real R5 driver that forms the superVGA  R3 driver 
replacement. Of course, it _is_ work to be done, but better spent time 
there 
than letting the app_server do interfacing to R3 add-ons I would say.

It's not something that is _very_ inportant also ATM, as we seem to have 
the 
number three cards running with fully functional drivers anyway ;-)

I _do_ think VESA 2.0 support has to be implemented though: this is _very_ 
handy to develop graphicsdrivers without the use of a secondary card or a 
testbed. (I do this all the time, and in fact, it's the _only_ option you 
have on laptops!)

Of course, VESA3.0 support has to be setup as well. Maybe we could even 
forget about 2.0, as the newer cards all support 3.0 (unless we want to 
keep 
compatiblity with those cards anyway)

VESA 3 has the advantage is is usable in protected mode. This means we can 
actually create a R5 style graphics driver for it. You'd have on the fly 
modesetting (colordepth, resolution, refreshrate), and you'd have 
functionality for virtual workspaces. Acc, cursor and overlay are out of 
the 
question though AFAIK.

You see, it surely beats 2.0 features!

--------

OK, you are up to speed now on the R3 stuff I think ;-)

>    You asked me on the third person that works on app_server. This name is
>Gabe Yoder, and he is DarkWyrn(Yon Yoder)'s brother.
>    Among all three of us you should've been talking with him at best,
>because his part is to make drawing primitives available to app_server. But
>lately his Personal Life required all its time, and because I needed those
>instructions working, and because I am curious about some things I was the
>one who contacted you. :-) Don't worry you won't write the same things
>twice! :-)
Thanks for the insight, and thanks for informing those people :)

>    My job was to make the client part (BWindow and BView). After I 
finished
>those I went on the communication part between server and client in order 
to
>render BWindow operational. Did that for some features. But I found that DW
>needed help on app_server. So the next thing I did was to implement 
clipping
>and redrawing code(VERY hard job). But that new code needs a new top
>hierarchy(Desktop, Screen, Workspace classes) classes that DW didn't
>implemented to good, or at all. We are finishing the design(note that
>support for multiple monitors is included) as speaking. In the rest, DW did
>an excellent job!
It would be nice if you could explain somehow how the app_Server works 
(more 
or less). I really don't know much about it.. :-/

Also, I am curious to what you are planning for multiple monitor support. 
Do 
you mean that you load a second primary accelerant for a secondary 
graphicscard so you can display another workspace there, or a stretched one?
If so, you can't live without my (or Be's) Matrox driver, as it's the only 
one _with_ card coldstart support... ;-)

>BTW: I am not that well documented on monitor/graphic card
>parameters/features so I'm asking you to help me a bit! Using Accelerant.h,
>please send me a prototype of the Screen class that should have all
>app_server is supposed to know about a graphic card/screen combination.
>Thanks!
I'd like to help out here, but this is an area I am completely new in so to 
speak.
You will have to help me get on the 'road'. Please send me a few iterations 
of where the below stuff could lead to, and explain a bit in plain English 
(using sentences :)

Sorry about that... I'd like to learn here! 

> Here is how currently Screen class looks like:
>
>class Screen
>{
>public:
>        Screen(DisplayDriver *driver, const int32 &ID);
>        ~Screen(void);
>
>   void    SetSpace(const uint32 &colorspace);
>   uint32    Space(void) const;
>
> // TODO: get/set prototype methods for graphic card features
>
>   int32    ScreenNumber(void) const;
>
>private:
>   DisplayDriver*  fDriver;
>
> // TODO: members in witch we should store data.
>
>   int32    fID;
>};


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


>    OK, now, a HUUUUGE *PLEASE*!
>Can you write a driver that uses a BApplication/BWindow/BView combination 
to
>show a screen in a window? And FAST!? Please note that I want multiple
>monitors to be supported. And under no circumstance one "virtual" graphic
>card to know about others. I don't know... make it so that the system
>appears to have N graphic cards. Thanks!
Can't you just place two graphicscards in your system? It's no problem to 
load two accelerants and display different things on them today!
(For instance I have a video consumer node here that displays captured 
video 
from a BT848 card on a nVidia card: even on TVout if you want. You just 
need 
one old nVidia card for that (TNT1-GF2 or so), and you need a Matrox card 
(MIL1-MIL2 with Be driver, or G100-G550 with my driver).

Of course if my Matrox driver is OK, you can also insert two Matrox cards 
;-)

I think it's a bit a waste of time to create a fake driver if the real ones 
are at your disposal, though I can see it being handy for people not having 
two cards of which one is a Matrox...

Best regards,

Rudolf.

-------------------------------------------------------------------
Hi again,

>    Nope! ATM the only thing I know is that it "shares" the driver with 
the 
>app_server.
>app_server temporarily suspends its lock on the driver and allows 
>BWindowScreen to do its magic.
Ah, thanks :)

>    Because We have drivers for the newer cards I see no reason(unless you 
>have something also
>to do!) doing a VESA 3.0 driver. 2.0 will sufficce!
2.0 has to be done elsewhere: you have a file called vesa that the system 
reads on boot, before switching to protected mode. The system has to make a 
call to the VGA BIOS at 0xC0000-0xC7FFF to set the corresponding mode. (so 
realmode call).

This isn't very complicated, it's documented fairly well (open VESA 
standard)

This also isn't a normal driver you see (2.0).

3.0 is something I _could_ do, if I have spare time. It's on my wishlist, 
but 
not for now. 

>    Anyway, I definitely think a VESA driver is needed!
Agreed :)

>    OK. I'll send you an email later on this subject.
Thanks :)

>Screen). There will be 2 types of functionality:
>    1-BigScreen - all monitors will be used for a big Desktop area. 
(contains 
>n Screen objects)
>    n-SmallScreens - each monitor has its own set of windows witch 
maximize/
>go_fullscreen in
>there( 1 Screen object only). So multiple Desktop areas. Navigation 
between 
>them will be done by
>a key combination or(if selected) when the mouse reaches the edge of one 
>monitor
Sounds very nice!

>> Sorry about that... I'd like to learn here!
>    This is a class that is responsible with changing/getting monitor 
>resolution. It also knows
>the available modes for the given graphic card/monitor ensemble.
>    It's not a big important class.
Well, I can tell you in words what that class does more or less (interface 
class<>driver)

>    Well... I can cay that I am disappointed of your answer here. We need 
>that driver, more than
>you can imagine. We don't want to support only 2 Monitors/graphic_cards, 
we 
>want to use all we
>can find in the system.
Hey, just plug in four Matrox cards and you're set :)
OK, cost money and is harder for multiple dev's to setup. But once you have 
that, you have the real thing.
Simulation is nice, but will contain mistakes/errors / different behaviour 
sometimes. Personally I hate loosing time over that..

> We also need that driver for making our driver subsystem more clear. 
>Currently there is
>a mess, because DW implemented a complicated design - he(me neither) 
didn't 
>know how to write
>such a driver. That driver will help us *a lot*!
>    If you have no time, or have other problems, I'll go ask Thomas. We *
>really* need it!
>    PLEASE help!
Well, apart from myself just plugging in the needed cards if _I_ needed to 
test with that stuff, I also don't have time, not the knowledge to set this 
up.

You want to create something that has it's 'top' interface on a lowlevel 
(acceleration hooks), while it's low interface (to the hardware) must 
interface above the top interface to classes as BScreen.
I never wrote a real nice C++ app, nor did I write big apps for BeOS, so I 
am 
going to loose a lot of time trying to graps what I need to do, if not me 
bumping against a brickwall at some point because it turns out not to be 
possible.

You will be a better judge than me regarding the theoretical possibility of 
this 'driver'.
Then you also want speed: well. Plain driver? simulation is probably not 
going to give you that. Don't know.

I do think Thomas has bigger chances to pull this off than me, but he 
apparantly has even less time than me :-/

Rudolf.

-------------------------------------------------------------
Hi!

>    Yes, He's right! a surface(bitmap) may be lost in 3D programming! For 
>example when switching from the fullscreen game to the MS Windows desktop. 
[ 
>Window's app_server must take some graphic memory for displaying]. It's 
the 
>same thing I was asking you about earlier.
OK. Then I think we can leave it that way with overlay also :)

There are more things you can discuss about. For instance when someone sets 
up a BWindowScreen. Some Be drivers clear the memory to zeros for you, 
while 
most do not. (Mine do not).

This means currently an app using BWindowSCreen must clear mem itself 
because 
it cannot rely on the driver doing that.
I can see advantages to both ways. Not clearing the memory can save some 
time 
if the app wants to fill it with real data, while clearing it anyway seems 
to 
be 'cleaner' to the user for me.

>    Yes, but locking can be made from different threads.
I get that. So you mean a thread might have to wait until another thread 
releases the lock? (Kind like a semaphore?)

>If you want to know more about in which order to obtain and execute what
>hooks, have a look at the alpha quality Be R4 graphicsdriver kit. I 
included
>it in this mail.
>Read the doc file 'R4_Graphics_Driver_Docs' please ;-)
>    If you can give me a link. that email was too big for my Internet 
>connection(dial-up) witch lately work like hell!

Look on your HD ;-)
It's under optional/sample_code/add_ons/drivers/graphics if I am correct.

>Flipping is easy: a totally independant 'task' ;-)
>    Huh?
With that I mean that setting the 'hardware pointer' to some part of the 
already configured framebuffer does have nothing to do with for instance 
the 
acc engine or overlay or the cursor. It's a piece of 'independant' hardware 
inside the graphics chip. You could also say that for overlay versus acc 
engine for instance (more or less).

>    Once windows/views will start having shadows, double buffering at view 
>level seems to be the perfect solution. Still, this might consume an 
>incredible amount of memory. It'll have to be discussed onto interfacekit 
>list!
Yes, of course :) Don't do anything hasty please.. (I won't  ;-)

>But then: can't we (you) just sync to retrace on the dragging of a window 
for
>just the inside drawing in the window? as that's the main distortion 
anyway,
>that should give the same result. As long as apps using DirectWindow do 
this
>also of course :-/
>    Guess so. But, that's not the problem. It's that the area that becomes 
>visible it's cleared first with BView's 'view_color'. Usually white.
If you look at it closely: _everything_ that draws on the visible screen 
should be synced to retrace, because everything will cause distortions one 
way or the other.
Fixing just part of the stuff may be enough for the human eye, but that 
doesn't mean it's 'perfect' technically speaking. Though I'll take the 
human 
eye thing if that saves a lot of trouble and/or bandwidth ;-)

>> One thing I'm sure we need is BView double buffering, but that
>>does not require
>>drivers to be involved in this.
>Can you elaborate a bit? I'm not too familiar with all those classes and 
how
>they 'hang' together (hierarchy)
>    On the hierarchy I'll tell you in the email I have promised.
OK :)

>    A BView is a 'surface' apps can draw into. Every window has tens for 
>there. Each one is independent of each other. If they can draw into an off-
>screen surface, then we could eliminate all the ugly things that we see. 
Also 
>We could apply all kinds of effects like shadows/simple alpha blending/
>antialiasing/etc.
>    I'll write about these in the email I'll be sending to you. Hey, maybe 
>that will be my first newsletter article! :-)
That's a good idea indeed! I mean, we should all share our knowledge to 
help 
eachother out with interfacing to each other :-))

Rudolf.


---------------------------------------------------------
Hi Adi,

>> 3.0 is something I _could_ do, if I have spare time. It's on my 
wishlist, 
>but
>> not for now.
>    It's not immediately needed, so take your time.
Thanks :) I will..

>    What about R2's app_server? How will that be done?
>    I can answer here: using the "view" driver!
>    Until R2, we must see how the app_server behaves in full screen. Well, 
>momentarly we have
>that posibility, but with very poor support. BTW, ATM we work with our 
>current "view" driver.
To be honest I don't know what 'testbeds' you use ATM. For me to understand 
this you'll have to explain in words, as I am not too good with very 
abstract 
things (I'm a bit of a 'hands on' guy now and then.. I need to see theory 
used in practice in order to grasp the theory. The upside about this (for 
me) 
is that things explained to me that way always 'stick' like glue :)

>> You want to create something that has it's 'top' interface on a lowlevel
>> (acceleration hooks), while it's low interface (to the hardware) must
>> interface above the top interface to classes as BScreen.
>    Yes, I know. We, now have 3 drivers: a real driver that works with an 
>accelerant clone, one
>that (doesn't)works with BDirectWindow, and one that works with BWindow/
>BView.
BTW I _am_ interested in if and how this would work, such a full blown 
'fake' 
driver as you want. I just lack the time and knowledge (I think) to be able 
to quickly set something up as I explained :-/

>> I never wrote a real nice C++ app, nor did I write big apps for BeOS, so 
I 
>am
>> going to loose a lot of time trying to graps what I need to do, if not me
>> bumping against a brickwall at some point because it turns out not to be
>> possible.
>    OK, I fully understand! Really! I must confess, that the most complex 
>BeOS app that I did
>had 3 BButtons and 2 BViews! :-))) I have almost 0 experience programming 
>BeOS. :-)))
Cool. Nice to see that guys like you and me _can_ mean something in 'OS 
development' despite our lack of experience in maybe important fields :)
The fun is learning things this way of course ;-)

>> You will be a better judge than me regarding the theoretical possibility 
of
>> this 'driver'.
>> Then you also want speed: well. Plain driver? simulation is probably not
>> going to give you that. Don't know.
>    No I don't want speed!!! I want stability and correctness.
Nice :) I second that ;-)

>> I do think Thomas has bigger chances to pull this off than me, but he
>> apparantly has even less time than me :-/
>    I'll talk to him. BTW, emails sent to him take weeks before being 
>replied? :-)))
Sometimes yeah. Unfortunately. Use   "Thomas Kurschel" <topical@xxxxxxx>
as this adress is known to be read ;-)

These days luckily he responds a bit faster than usual, although he seems 
to 
do that in the middle of the night, from work! Please be gentle with him ;-)

Rudolf.

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

> No, you didn't understood me. I was referring to the "data" inside the
>bitmap(the image)!
The data is lost and the app is required to write new data. Which of course
is no problem at all because overlay is used for video, displaying 10-
30frames per second.


> Once the resolution changes from 640x480 to 1280x960, and if the overlay
>data is found where
>1280x960's frame buffer should be, they are destroyed! I don't think that
>should happen!
> IMHO,
>the driver should copy the image into main memory and then reconstruct the
>overlays, thus the
>"image data" won't be lost.
Nope. The driver can't tell the difference from the app_server releinquising
overlay or the app doing that.

For 3D stuff it will be different anyway, because when we support _that_ we
need to be in AGP mode with direct access to main memory enabled. I still
think I remember someone saying that an app using 3D should always verify if
it's bitmap(s) still exist and if not redraw it itself!
Better ask Thomas what he thinks about this subject...

> Is it so, how it works?
The old overlay bitmap can indeed be where the new workspace gets defined
(partly).

>So, in short: Lock() and Unlock() are ways to mediate access to the
>communication channel.
OK. So Locking a bitmap means that bitmap gets solely access to the pipe, 
and
unlocking it means the pipe is free again (for another to grab it)?

>> Another thing is that the app_server only aquires the acc engine to do a
>> command list (one command with a list of arguments). The app_server then
>> releases the engine only to acquire it again if it wants to use the 
engine
>> again (apparantly). So it owns the acc_engine every time only over a very
>> short period of time.
> Sure! Otherwise how could clone_accelerant() of BDirectWindow work!?
Indeed. I thought so :)

>> I meant this:
>> void * get_accelerant_hook(uint32 feature, void *data)
>> for:
>> (SET_CURSOR_SHAPE);
>> (MOVE_CURSOR);
>> (SHOW_CURSOR);
> I don't quite understand what you mean.
Ah. OK.

When the accelerant gets loaded by the app_server (or another 'program', 
like
a media consumer node ;-)
the app_server wants to use its functions.

But there's only one public function avaiable in it:
void * get_accelerant_hook(uint32 feature, void *data)

This function is used to gain access to the real functions in the 
accelerant.
There can be different functions to execute a command for different display
modes for example.

So the app_server wants to know whether the accelerant can draw a cursor.
Therefore it asks this one public function for a pointer to these 'hooks':
(SET_CURSOR_SHAPE);
(MOVE_CURSOR);
(SHOW_CURSOR);

If the accelerant returns null pointers, the app_server has to do its own
software cursor thing. IF not, it will use the accelerant.
The accelerant has already inited some vars to safe defaults, and the cursor
is turned off (INIT_ACCELERANT). The app_server will now SET_CURSOR_SHAPE,
MOVE_CURSOR to mid of screen and SHOW_CURSOR.

Currently this is only done upon starting use of the accelerant. If this 
were
done after each modeswitch, the accelerant would gain the ability to force
the app_server to use the softcursor, or to do the hardcursor itself.
Depending on mode capabilities of the hardware that is.

If you want to know more about in which order to obtain and execute what
hooks, have a look at the alpha quality Be R4 graphicsdriver kit. I included
it in this mail.
Read the doc file 'R4_Graphics_Driver_Docs' please ;-)

>> Also, you probably need to keep in mind, that what I tell you about those
>> engines will be somewhat biased at the least: If I hear you talking about
>> using a whole lot of new acc engine functions in whole new ways (for non-
>> Windows that is) I see a huge pile of work coming this way, which I
>honestly
>> don't know if I want to even try to get it working because of the amount
of
>> work required.
> Then I think the idea of an OpenGL based app_server for R2 fails.
Well, still I _am_ interested in openGL. ;-)
Just not at this moment because a lot of work finetuning the _current_
drivers has yet to be done.
Also Thomas should have a lot more time to work on it as he has a tough job
currently apparantly.

>> Thomas and I sometimes talk a little bit about 3D in the drivers, and the
>> general feeling is we are already tired of 3D before we would even begin.
>The
>> clearer the picture gets about what needs to be done to get it working,
the
>> more tired we already become. This is due to understanding/seeing what 
the
>> amount of work is that we would need to do :-/
> Yup! It seems I'm right! No OpenGL server for R2.
>
>> I _do_ thing it would be nice to see double buffering (or whatever you'd
>call
>> it) in BeOS, so we can prevent tearing.
> Definitely!
>
>> I've been thinking about it a little, and it seems fairly simple to 
setup:
>>
>> ->create front and back buffer
>> ->draw in back buffer by app_server and apps
>> ->during retrace, blit back_buffer to front buffer.
> Nah! Blitting is expensive! I think we should try flipping the buffers!
You still need to blit differences otherwise you will be working on an
outdated buffer..

>> Both simple tasks to do (as long as those buffers are in fact one large
>> virtual workspace: in height), and it _could_ be done inside a driver
>without
>> BeOS or the app_server even knowing about it!
> Nope. app_server has to decide when the flipping occurs.
Flipping is easy: a totally independant 'task' ;-)

>One thing I'm not sure of, is if app_server should use fullscreen double
>buffering. I'm not sure
>it is useful.
If you drag a window around you'll see tearing big time. So this is not only
inside the window being dragged, but also in the outline and redrawing stuff
that trails behind it (I think).
On the other hand: the inside of the window being dragged is by far the
largest part so if you only do that, the tearing might be near invisible
indeed.
But then: can't we (you) just sync to retrace on the dragging of a window 
for
just the inside drawing in the window? as that's the main distortion anyway,
that should give the same result. As long as apps using DirectWindow do this
also of course :-/

> One thing I'm sure we need is BView double buffering, but that
>does not require
>drivers to be involved in this.
Can you elaborate a bit? I'm not too familiar with all those classes and how
they 'hang' together (hierarchy)

> Anyway, double buffering isn't one thing to
>be concerned about
>ATM!
Indeed ;-)
Apart from me wanting to setup decent TVout for Desktop use on Matrox G450/
G550 that is. But I'll also take it if it draws unsynced to retrace. If it's
'as good as Windows' (mumble...) I'll take it :)

Rudolf.

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

Hi there,

>    I am one of the 3 developers working on OBOS app_server.
So, along with Darkwyrm and a third person?
>    I have some questions for you, if you be so kind to answer them...
OK, no problem. :)

>*) I want to make [HEAVY] use of gradients along patters in our app_server.
>One thing I want to know is, if I have a buffer of 100 colors(rgba) can the
>driver use those colors to draw a line? 100 pixels long of course. If not
>can a future driver do that. I am interested only if this can be done in ONE
>call, NOT by drawing a succession of points; so that hardware acceleration
>be used.
2D acceleration in a driver mostly works with rectangles only. The current 
BeOS supported hooks do this only (I am glad to report because _this_ is 
what's supported on most graphics hardare :).

Basically, the engine can copy pieces of framebuffer to other (overlapping) 
pieces of framebuffer. This framebuffer is that part of the cardRAM that you 
use to dump your data in that should be displayed directly, or in a virtual 
window.

Also the engine can invert rectangles, or fill them with _one_ color.

The BeOS fill_span acc function BTW is in fact a rectangle fill, with a 
height of 1 pixel.
fill_span only draws horizontal lines. with _one_ color.

Some engines (3D capable ones only I expect) can do a scaled_(filtered_)blit. 
This copy function destination may _not_ overlap the source. While a hook for 
this function was defined by Be, it's never used AFAIK.

It only has specific purpose: scaling video if no backend scaler is available 
in a card comes into mind.

I strongly advice _not_ to setup bitmaps inside graphicscard RAM in unused 
memory, and then wanting to hardware blit them onscreen. This is because most 
engine do _not_ see the RAM as being a linear space, but it works with _one_ 
workspace with a X and Y coordinate. It needs this to determine the 
'slopspace' that exists to the 'right' of a certain bitmap that should be 
blitted elsewhere.

You need to understand that in order to blit an offscreen bitmap onto visible 
screen, you _must_ setup a (large) virtual workspace, though the user 
shouldn't know about it. The offscreen bitmap (smaller than the visible 
fullscreen size for instance) needs to 'fit' into the offscreen part of this 
virtual workspace, adhering to it's bytesPerRow() for instance. The bitmaps 
would also need to be in the same colorspace as the visible screen.

While I _do_ understand why you ask these questions (there's been discussion 
before in the interfacekit list in the past about this subject), you would 
through away compatibility with a lot of hardware. The probable exception to 
this scenario are only the top brands 3D cards which can probably accomodate 
you better.

I say probable because you have to be aware that if you want to use more 
advanced engine features (which we are talking about to pull this stuff off) 
you would need documentation on those. You see Linux drivers (which are a 
_very_ important source of information) also mostly use 'normal' engine 
features, and manufacturors don't like to give you the specs either.

Personally, I have to admit I like 'the Be way' here very much. Keep it 
straight and simple please! Only use the 'mainstream' features to reach this. 
Though of course 'mainstream' gains more advanced features in time also. 
Which you should aim to follow up on I think. But don't try to use it all, or 
use hardware 'to the max' so to speak.
Probably most current 2D only capable engines can't do what you want.

For instance: a simple draw_line function. I expect you can only draw 
horizontal lines on most engines. Chances of an engine supporting vertical 
lines are smaller, while other orientations will be rare already.  Though 
nVidia cards can do that.

You should also be aware that those four functions used by the BeOS DANO and 
R5 app_server are solely responsible for the best part of acceleration you 
can get anyway. I mean, what's a line_draw compared to a screen_to_screen 
blit or a rect_fill data-amount wise?

One more remark: It is _not_ so that you can use the engine to access _any_ 
part of the screen. Workspace restrictions exists that are tighter than the 
RAM amount would allow in theory. You can do more pixels in height than in 
width though.


BTW: while reading my 'story' you have to keep in mind I am no guru here 
either. I might be mistaken on some things, or think to easy.. But then 
again: thinking 'easy' is what I'm best in, and it's what helps me keeping to 
find out and track down those bugs or unknown features ;-)
And what strikes me most, is that my straight and simple thinking seems to be 
_just_ the way Be implemented it (mostly). AFAIK of course.

----

So to answer your question: those 100 colors if they should be displayed in 
one line: should be written by software. No acc here. Not currently on BeOS, 
nor likely to be easily or at all implementable.

>*) currently, can I use a double buffering for the hole screen? 
No. The way for instance the pageFlipper demo app (or the Allegro game 
library) does that is by creating _one_ large virtual workspace, and by 
setting the hardware buffer pointer to the part of it which needs to be 
displayed (MOVE_DISPLAY). Note please that this works with X and Y 
coordinates: no linear space.
This way of doing things nicely adheres to the engine restrictions I already 
spoke about BTW.

You cannot create independant bitmaps on the card's RAM. There is no Be 
function for that.

In theory it would be no problem to do double or triple buffering for a 
normal screen (you ask this because you want to prevent tearing, or having to 
wait for retrace to do screen updates because it slows down everything 
drastically I expect.)

In order for a workspace to be created normally, that is as it is now, you 
have to do a few things though.
->you setup two or three (whatever) buffers with normal X, Y and bytesPerRow)
->you set the hardware buffer pointer to buffer 1. You don't have to wait for 
retrace because the driver should do that for you if needed (if it's not 
needed it's because the cards hardware already does this automatically)
->You init the acc_engine to work on buffer2.
->you blit or do what ever you want to do on that because it's offscreen (not 
displayed)
->you set the hardware buffer pointer to buffer 2 (driver takes carre of 
retrace sync again)
->you init the acc_engine to work on buffer1
->you blit in buffer 1 because it's offscreen.
->etc.

You need to init the acc_engine because of its restrictions, or the 
restrictions a lot of engines have. Blitting between both buffers because you 
want to do delta-updating only (speeds up everything: less bandwidth on bus, 
GPU and it's RAM needed) is not possible on a lot of hardware _unless_ you 
use the current way of doing things in BeOS (one large virtual workspace with 
MOVE_DISPLAY: really, it's nice having that the way it is!)

>Is 2D
>acceleration used for the backbuffer too???
No, since it does not exist.

>Can I blit a rectangle from the frontbuffer to the backbuffer, also by using
>2D acceleration? Can 2D acc be used for EVERY piece of memory allocated in
>video memory[used for backbuffering]?
OK, already answered that both. Be carefull about changing all this... I 
think it's a very bad idea for R1 at least.

>*) If I'll allocate 100x100x32 bytes directly into video card's memory(AFAIK
>this is possible, no?) representing a 100x100 bitmap, that memory can be
>used for *hardware[2D acc]* blitting onto frontbuffer(backbuffer too?) isn't
>it?
No, as already explained above ;-)

>*) where can I find a paper/book explaining the 2D part of a video card?
>also, if you can give me a link/book/paper for the 3D part I'd be highly
>grateful! :-)
It's hard to come by this documentation. In fact, I don't even have that. I 
use the experience I gained from working on those three drivers I did, from 
looking at Matrox register level specs, and from analyzing Linux Xfree 
drivers.

The VGA programmers manual I suggested (in my drivers howto) (Richard F. 
Ferraro: out of print AFAIK), the third (latest at least I think) edition 
contains info about a 2D engine.

Also another book I suggested here contains some information. It will tell 
you that the engine described (Being a representative example!) only supports 
those features (except screen_to_screen_scaled_filtered_blit) that BeOS 
already has defined. And nothing more. And keep in mind those restrictions 
the functions have I told you about!

>*) what did you do for Be Inc?
Nothing, apart from buying R4, R4.5 and R5 ;-)

BeOS _is_ the only OS for me because of a simple reason: it does everything 
simple, and straigtforward. _Whatever_ you look at in the BeOS: keep that in 
mind. They did things in a certain way because of a very valid reason, even 
if you can't see it at a specific time. Not just because it was convenient at 
a certain time or so. (exceptions granted ;-)

My experience is that if you start looking further and deeper into a subject: 
you'll find this time and again.

>Thank you,
>Adi.
You are welcome. Don't hesitate to call again. I'd like to do what I can to 
keep OBOS on the right track ;-)
After all, I don't want to loose the 'Be' type of OS...

Rudolf.

--------------------------------------------------------------------
Hi again,

BTW: About me saying _no_ to you being able to setup a independant bitmap in 
graphics card RAM:

There is _one_ exception to this rule: hardware overlay.
You (an app) can construct a bitmap with the B_BITMAP_WILL_OVERLAY flag. This 
will let the app_Server call the graphics driver to let the driver do memory 
allocation on the card. You may setup three bitmaps this way, so you can 
setup the so called 'double buffering' feature. Keep in mind that technically 
speaking, this is in fact _triple_ buffering!!

The reason for using an extra buffer is CPU time and  otherwise having to 
wait much more before  the onscreen buffer becomes offscreen (and so: 
available) again.

Be aware that _no_ other flag you can specify will create a bitmap in 
graphics card RAM. (Believe me: the driver would know about it _and_ have a 
function for that: it needs to manage it's own memory, especially when 3D 
comes into play!).

Using more than 3 overlay buffers is _never_ used ATM. In fact, my drivers 
have an allocation restriction of 3 overlay buffers. Which (in theory) could 
be lifted easily of course. )

Overlay uses another engine on the graphics card: the BES (backend scaler). 
This engine is totally independant of the 2D or (3D capable) engine.

This BES will colorspace convert, scale, and filter (interpolate) the bitmaps 
to be RGB24 (better 'known' as RGB32) before they are overlayed on your 
screen. Overlaying means it will _not_ be written into the graphicscard RAM. 
It will just be sent to the DAC, so monitor, whenever it asks for 
screenbuffer data in the coordinates the overlay 'occupies'. 

The overlay bitmap colorspace _all_ cards support (if they have a BES) is 
B_YCbCr422. This is probably because this space was defined and registered by 
nVidia (as FourCC space YUY2: see http://www.fourcc.org)

Some cards also support other spaces, like B_YCbCr411, or RGB16, RGB32. A 
nice thing about those overlayed bitmaps is that they don't need to be in the 
same format as the workspace is. It's no problem to display your Desktop in 
8bit colordepth, while the overlay input is in B_YCbCr422 or RGB16 (for 
instance), while the BES will show the output onscreen in RGB32!

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

OK. Of course the hardware cursor is a seperate bitmap also. This bitmap 
mostly is in a four color space (black, while, inverted or transparant) 
occupying 2Kb or 4Kb RAM. (the bitmap is mostly 32x32 pixels in size, though 
BeOS uses 16x16 only: the rest is just filled with transparant color).

Don't change this either: although _some_ cards are more flexible about this 
(nVidia can do RGB32 in 64x64 pixels, taking up more RAM of course!)

Be's cursor exists this way because it's supported on most hardware...

BTW: Those cursor bitmaps mostly are allocated in graphicscard RAM, though 
_some_ cards have it in a special, in a serial fashion accessible, 
registerRAM. Hence the need for a driver function to set the bitmap, instead 
of some app or the app_server just dumping it directly in cardRAM...

The cursor is also an overlayed bitmap, although it cannot be scaled and 
such.

Best regards,

Rudolf.


-------------------------------------------------------------------------
Hi there,

>    Wait a second... I'm missing something. What happens when BeOS is
>playing let's say... 5 videos at a time, each using triple buffering?
Not possible. The first instance of the mediaplayer in use claims the overlay 
hardware, and creates three buffers for it. The properties will tell you it's 
using overlay (VLC, mediaplayer)

The second instance cannot claim the overlay unit as it's already in use. the 
bes can only be used for _one_  video output at a time. The second instance 
of the mediaplayer must fall-back to bitmap output mode, and uses three input 
bitmaps for double buffering. This time the bitmaps are in main system 
memory, _not_ in the graphics card memory.

The third instance must do the same.

Check it out: you'll find this is working nicely, in the way it should ;-)

The total picture is even somewhat more complicated than this.

Let's say you want to create a mediaplayer. You want to do this:
->try to setup three buffers for overlay use. OK? use it as double buffered 
overlay. Fail: next step:
->try to setup one buffer for overlay use (you already know from the previous 
step if this can be done ;-). OK? use it as single buffered overlay. Fail: 
next step:
->use bitmap mode in double or single buffered mode.

The reason for sometimes just one (or two) overlay bitmaps succeeding in 
creation, is lack of graphicscard memory. Happens a lot on notebooks. (For 
instance my neomagic notebook has 2Mb RAM, Could do triple buffered MPEG1 
(384x288), single buffered DivX(640x480), bitmap output DVD. (720x480 or 
720x576)

The exact 'moment' for not being able to create those overlay bitmaps depends 
on desktop colordepth and virtual resolution of course. (memory management 
inside driver takes care of determining all this.)

One important thing for use with overlay bitmaps is this:
You (app) may _never_ copy a bitmap pointer to another var. You _must_ use 
the original pointer. When the user changes desktop resolution for instance, 
the overlay bitmaps will be destroyed by the app_server, the mode will be set 
by the app_server, and then the app_server requests new overlay bitmaps from 
the driver. However, the order of asking for bitmaps can be different than 
the app did this before, so the bitmaps get swapped in memory. Also they can 
be on a different adress, or they may not even be created at all.

The app, if using copied pointers, will segfault or produce a mess onscreen. 
It may use copies I expect, but then it has to monitor for screenprefs 
changes to re-copy the pointers.

BTW, changing workspaces also lets the app_server kill the overlay bitmaps, 
set the mode for the other workspace, and re-aquire the bitmaps with the 
driver. This succeeds if RAM is available, but again, the order of the 
bitmaps and the occupied adresses may vary.

Faults with using copies were done by VLC in the past... (I have been 
monitoring them since a long time, and every now and then I have to set them 
straight ;-)

One thing I am not entirely clear about: there should be some sort of 
semafore system to prevent the app_server from deleting a buffer while an app 
is in the process of writing it. Thomas Kurchel says (to my best knowledge) 
that this thing does not exist in BeOS, but he insists it should: think about 
3D! You have a large amount of 'bitmaps' floating around in graphicscard RAM 
then, which may or may not be 'swapped out' by the driver as it needs the ram 
for more frequently used ones (speed optimisation)..

If you use the DLL wrapper DivX codec with mediaplayer, you'll notice 
mediaplayer crashing every now and then on workspace switches: this must be 
the not implementing locking/semafore system: at least in the codec.

Do you think the bitmap->lock() and unlock() functions are the method to make 
sure they are mutually exclusive accesible? Thomas said this is how it's done 
in Windows. Of course (for 3D) the pointers to the bitmaps may be changed on 
any time, so this locking mechanism is _very_ important there and then...

-----

OK, here's another one. BeOS accelerant hooks are layed out in such a way it 
is possible for hardware to have more than one acc engine or backend scaler 
(overlay unit).
You can ask the driver the number of units.

While Thomas and I never say a card that has either of this, Be foresaw that 
this could happen, and I think they are right about that.

This is an area I want to experiment with in the (near) future: I expect the 
nVidia GeForce cards just _may_ have a possibility to use the (single!) bes 
for two movies at the same time. I am going to try to implement that in the 
driver later on, of course modifying the overlay buffer restriction to be 6 
bitmaps then.

If BeOS support is really complete, we should be able to start two instances 
of the mediaplayer using overlay, while the third falls back to bitmap 
output.

>    Fascinating! :-) Really!!!
I think so too. It's been (and still is) a great adventure for me to find 
this all out :) For instance I can hardly wait to do dual overlay capability, 
or start tweaking with 3D (once I learn enough about that _and_ still have 
spare time)...

>    Cursor is one thing I know for certain it will be changed!
>    DW has decided that long time ago! And I think he wants a 32x32 RGB32,
>for R1! Is that supported on most cards?
No: trouble!!

You see: DW does not really know what hardware can or cant do: BeUnited 
warned me about that.
Unfortunately DW and I are apparantly not able to communicate professionally 
about this technical stuff. While he's a nice guy, and the few 'talks' we had 
were nice, he systematically stops responding to my mails once they get too 
technical.

So, please: keep an eye on where the app_Server is going!

>    I haven't discussed with him, but can he do that with the current
>drivers???
No again. just the 4 color cursors in 16x16 res.

Though 32x32 can be done on most (maybe even all cards) _but_ the drivers 
need to be updated for that as well.

You have to be aware of another hardware restriction which Be R5 and DANO do 
wrong (still can't pinpoint if I can influence that somehow within the 
driver: setting the app_server straight I mean).

You have a 'hot' position within the cursor bitmap. This is used so for 
instance a 'wheel' shaped cursor can have the hotspot in the centre of the 
wheel so you click exactly right on an item (know what I mean??)

This is a nice feature, but it does not check for bounds!!

Let me explain: Some cards (Matrox) have the reference point of the cursor 
bitmap at the right-lower corner. Some (most I even think) other cards 
(nVidia, neoMagic) have this reference point at the left-top. While the 
app_server should not be concerned about that (the drivers correct this 
internally) this _has_ influence on the behaviour I will now outline.

OK. Now there is a hardware restriction which says: you may _never_ place a 
single bit of the cursor bitmap (so 32x32..) beyond the left or top of the 
screen! If you still _do_ that, the cursor will magically dissapear 
immediately as a whole.

This means that the app_server should redraw the cursor bitmap once it's 
going to overlap those boundaries: so clipping the bitmap while moving the 
remaining part up and/or to the left within the bitmap space. Also it has to 
modify the 'hotspot' given to the driver accordingly.
If this is done, the user thinks the cursor is partly offscreen, while the 
hotspot still applies.

This requirement does not exist for the right and lower part of the visible 
screen BTW, on all cards. This is because of the way the hardware works 
internally:

The cursor position is determined locked to the monitors horizontal and 
vertical retrace signals (syncs). The cursor hardware has counters which 
count what part of the screen is currently 'drawn' on the monitor (this works 
serially: one pixel at the time (cathode ray scan: CRT you know? LCD's still 
get the data that way also BTW)

The counters start running (reset) when the screen is drawn, and can only be 
positive. Hence: a negative position is in fact a very large positive 
postion: very low, or very much to the right, being offscreen definately!

Some cards (Matrox) still have a positive value if the bitmap is partly 
offscreen (right-lower corner is ref point!), while most others immediately 
go negative (left-top corner is ref point.)

So, you have two options here:
-> always do clipping in the app_server software OR
-> ask the driver if it can do something negative. If no, software clipping, 
if yes: hardware clipping in driver.

This would mean an extension to the Accelerant hook thing.

Well, you get the picture ;-)

You see, you app_server guys _need_ to know what hardware can and cannot do! 
(Thanks again for mailing ;-)

>One last thing.
>    We decided that after R1 we should have an implementation of OpenGL, and
>then an app_server based on OpenGL.
Ah. Very interesting subject! ;-)

I am a beginner here, though I am collecting info and bits and pieces about 
the generally needed setup. You should ask Thomas Kurchel also about this 
subject: he once wrote his own 3D game engine! (so no driver, but he must 
have a better idea about the 'interface', as you can already tell from what I 
just wrote down about bitmap locking().

For 3D, you need:
->AGP motherboard chipset drivers, to setup the GART (whatever that may be: 
ask Thomas: he fiddled with it already!)
->The drivers need to enable AGP mode: the current drivers use PCI mode (AGP 
is 'just' an extension to PCI)
AGP mode means enabling 1X, 2X, 4X or 8X transfer (speed) mode, and enabling 
SBA (sideband adressing). The items meantioned here can apparantly be done 
100% within the graphics card driver. Ask Thomas though.

The above two things are needed to let the card access main system memory to 
fetch and/or dump those more often used and/or not soo often used anymore 
bitmaps to/from grahicscard RAM (GART I think). Because you need all the 
speed you can get here (bus== bottleneck otherwise you need to enable AGP 
modes.

Now you can setup hardware 3D support which will actually speed things up 
drastically. (without those AGP things you can still setup hardware 3D 
support, but with a serious speed penalty. Nice for testing already 
though..).

What I just now heard (a few times ;-) is it works like this:

->You have the apps and the system.
->You have the graphics card driver below this;
->You have MESA (software openGL) below this.

What happens is that the driver monitors the MESA calls. If it sees calls for 
things it can do in hardware it intercepts it and does it. I suspect the 
monitoring by the driver is nessesary as it needs to be informed about 
_everything_ that is happening. It's a (serial) pipeline after all, and also 
you have the extensive memory management facilities needed in the driver( 
again: ask Thomas about his thoughts here: his ATI driver has more of this 
already (better framework I guess: centralized management) than I did for my 
drivers (implicitly, decentralized management for every function yet)

OK. The funny thing is 2D acc works the other way around BTW!
You have:
->The apps
->the app_server
->the driver.

The app_server (which is software) draws inside onscreen bitmaps for apps 
(unless they 'dump' data directly into them themselves of course). A window 
has a background color, just like the desktop (both setup with a function 
called rectangle_fill. 
If you have a window with a list view of files for instance, while the window 
only displayes part of the contained files (window is too small to show 
everything), you see file by file being (software) drawn in it (fast!). If 
the drawing program (tracker?) determines it needs to fit in a file (Because 
it's shown alfabetically, while the order of drawing is _not_ alfabetically), 
it uses a function called blit to move the already shown file lower onscreen 
withing that window, so space is created in which it can software draw the 
next fileentry that goes in between.

OK. The app_server determines how the drawing proceeds. It asks the driver 
for a blit hook and a rect_fill hook every time a new mode is set. The driver 
has the option to give that or not (except for synchronisation hooks), 
depending on if the driver can do it in hardware for the mode set.

If the app_server is instructed to blit by tracker in this example, it will 
do it itself in software if it got no hook from the driver, otherwise it 
relays the command to the driver.
Same goes for all other acc function hooks.

You see the driver is at bottom of the chain for 2D acc, while it sits 'in 
the middle' for 3D acc.

BTW: the hooks for overlay are also re-aquired by the app_Server after every 
mode switch. In theory I can prevent the app_server or apps use overlay if I 
don't want that for a mode. The apps will be instructed to fallback to bitmap 
mode then (via the API which should be extended here BTW: Be never completed 
that: overlay is setup 'experimentally' (could also explain bitmap locking() 
not being in place if that is so))


-------

Now I want to say one thing about the cursor: Strangely enough the app_Server 
requests these hooks from the driver only on startup. _Not_ after every mode.

This really is a shame: it would give me the option of preventing the 
app_Server from using the cursor in modes I cannot do it (Matrox dualhead 
stretch modes: the second head has no cursor hardware), while I _would_ be 
able to use it in singlehead modes (BDirectWindow Windowed mode needs this!! 
I can explain why BTW ;-)

The software cursor is being generated inside the app_Server if it cannot 
aquire the cursor hooks from the driver.
Which brings me to a fault in the current R5/DANO app_Server: if you set a 
virtual mode, the app_server misses the MOVE_DISPLAY functionality. It really 
should do that. Explanation:

On harware cursor use: the driver itself calls MOVE_DISPLAY within the 
MOVE_CURSOR routines when ever it's needed. Because on software cursor use 
the cursor hooks are not exported, the driver knows nothing about the 
software mouse position. The app_server should monitor that and call 
MOVE_DISPLAY if needed!!

(Strangely enough this _does_ work in failsave B/W video mode. Did you know 
this are in fact R3 graphics drivers being at work?? (being app_Server add-
ons)

OK, OK I'll shut up ;-)

>    Will it be hard for you guys(driver developers) to provide drivers that
>have support for OpenGL 1.4 ?
Thomas can pull that off _if_ MESA is in place I would think. Ask him 
though...

I can do it just maybe as well: got MAtrox docs, got nVidia 'pointers' (bits 
and pieces of info) which might get me into action. I could use Thomas as an 
example implementation very much though...

BTW: It's been said R5 has everything in place as well! There are just no 
drivers for it. (would make sense regarding how the stuff is layered (driver 
being in the middle, software GL under that ;-)


BTW2 ADI: Can I rely on you to make my mails known in the openBeOS 
'community' as far as is needed according to you? I'd hate to write this more 
than once... Thanks!


Best regards,

Rudolf.


-----------------------------------------------------
Hi again,

I am trying to keep up here ;-)
Currently I have a few extensive technical 'threads' going though I'm afraid. 
While I don't mind that, writing these Emails really costs a _lot_ of time.

Yesterday I though to myself: Why, if Adi lived in the neighbourhoud, I'd 
better just drop by and drink some coffee with him. Talking really saves a 
lot of time compared to the slow 'input' of writing...

Anyway: don't worry, I should answer all your mails.. Unless I drown so to 
speak or loose some mail in the 'large' inboxes by now.. :-/


BTW: What comes to mind ATM is the cursor thing: You told me you did not see 
a reason for both clipping _and_ updates on the hot position.
You did not understand me completely I'm afraid, as _both_ are needed..

With clipping here I mean: the say circle shaped cursor should be rewritten 
in the bitmap with only the lower half in it when it's upper half should be 
above the visible screen. With this I mean that it should be written 'higher' 
in the bitmap: in the upper half's memory! So this means the hot postion 
changed also by this amount of vertical pixels, and should be modified 
accordingly.

In the driver code, the internal cursor Y and X coordinates may not become 
negative. As the hot postition is subtracted from the actual position (Which 
runs down to 0,0) this is currently not quaranteed. In practice you mostly 
see the hot position being 2,2 in the 'hand' (being the finger, which is not 
placed at the exact 'border' in the bitmap area). I had to restrict the 
nVidia and neoMagic driver to 0,0 internally to prevent loosing the cursor...

Of course, I'd like it better if we could think of some other solution that 
gives the same effect without all this 'tweaking' in the driver and 
app_server combined. I can't think of another solution though :-/

Hope this clears this. If not, don't hesitate to let me know ;-)


Talk to you later!

Rudolf.

----------------------------------------------------------------------------------
Hi again :)

>    Yes. Why the question mark?
I was just curious who the third person is :)

>> Some engines (3D capable ones only I expect) can do a
>scaled_(filtered_)blit.
>    Can you explain more? Is it used when BES is unavailable? Won't this
>affect performance?
It's never used AFAIK. The app_server does not ask for it's hook for 
instance. 
I was just stating a possible use, _but_ only for fullscreen video in a 
BWindowScreen style workspace, as copying needs to be done from an ever 
offscreen to an (sometimes:double buffering) onscreen area somehow.

It can only be used fullscreen because it works with rectangles also. Other 
windows or dropdown menus and the like would get overwritten.. (this is no 
overlaying method)

>    OK. Got that! That brings me another question: What stops me from
>requesting a virtual screen that uses almost all video card's memory? so
>that I can have many, many offscreen bitmaps.
Nothing :)
Expect to loose acc_engine cabability though. Which brings me to this: 
display_mode.flags has for instance b31 defined as "B_SUPPORTS_OVERLAYS" (Be 
overlay header file)

I can imagine it would be handy to have a B_SUPPORTS_ACCELERATION flag as 
well. say bit 30. A user could ask proposemode if a certain virtual screen 
size would still have acceleration in a mode. Currently the user has to 
actually set a mode, and then try to get the hooks. IF that fails, it knows 
it has no acc capability.
Also: The Matrox engine for instance has seperate max. settings for different 
acc engine commands. RECT_FILL, RECT_INVERT and SPAN_FILL can use upto 16MB 
,while blit  can use more. It can happen you set a mode that:
-has full acc;
-has partial acc (blit only)
-has no acc. (my drivers: Be's drivers limit all cards to 2048x2048 
screensize, which is always accelerated. So this problem does not exist in 
practice then).

--

Be aware though that setting the max virtual workspace will prevent you using 
overlay. Overlay needs RAM to place (three) bitmaps of it own.


>    YES! for 4 years nVidia ATi and Intel were the ones that occupied more
>than 90% of the market. Use their advanced features we shall! I don't think
>we'd loose compatibility... there is software emulation! :-) ... there is
>the almighty "switch"! :-)))
OK. I can understand one wanting to go that way. Though personally I am not 
very fond of it (work, work, work, and costs time, time, time... R2 people!)

I hope someone can get it to work in the drivers all-right. Would be nice ;-)

Forget the non-RGB32 cursor also then: just switch, just like for clipping/
non-clipping cursor capability ;-)

>    PLEASE, enumerate the "normal" engine features, for me to have a big
>picture! thanks!

->screen_to_screen blit
->screen_to_screen_transparant_blit (never exported, so never used)
->fill_rectangle
->invert_rectangle
->fill_span

That's it.
The last defined one in BeOS is:
->screen_to_screen_scaled_filtered_blit. (never exported, so never used)
This function in fact uses a 3D feature: the texture engine.

The function blit and rectangle can both be given a 'pattern'
We use 'invert', 'fill' and 'transparant. 

There are maybe 16 pattern that can be used though (see it as things like 
AND, OR, XOR, CLEAR, SET and such)
All functions use rectangle shaped areas.

>    Be Inc. disappeared 2.5 years ago, BeOS R5 has 4+ years, Riva TNT2 is
>now GeForce5 *very* soon 6; did the mainstream gained more features?
Shall I send you a nVidia header file? Though it's a NV10 file (more or less 
complete AFAICT), you'll get the picture. (NV10 is GeForce256)

Be warned though. If you want to see more or less what's all in it, you'd 
better take some time off. (1Mb in size)
Say 2/3'd of the file _just_ described the acc engine.

The last half of the file describes the acc engine commands. While I'd like 
to get a crack at it, I have to tell you I give you only a (very) small 
chance I succeed in understanding enough to get basic 3D up and running. 2D 
only things are simpler, and I suppose it would be relatively easy to add 16 
more to the 8 or so already setup (sub) commands for that.
(nVidia has seperate command for setting the pattern, setting the workspace 
size (clipping region) and doing the blit for instance. All three together is 
_one_ BeOS command screen_to_screen_blit. You need to have all parts 100% 
correctly in place to get it working. Otherwise: system locks up.)

2D extension alone is already going to take months probably though!

>    Rudolf, mate, some things get old, they are still good, but technology
>doesn't progress in vain! :-)
OK, but R2 or later I'd say. Of course you are correct here, but I still 
think you should not 'burn your fingers' on it for R1.

>    I'm sorry but, that's exactly what I aim!
Then you are in for trouble as the last few percent will be manufacturor 
specific, and nolonger 'generally useable'. I expect: remember, I am no guru.

>> Probably most current 2D only capable engines can't do what you want.
>    Then... restrictions... software emulation.
Then also: slowness. Suddenly I have to think of Windows.. ;-)

>    So how do you know that? From where did have the specs? Can I have them?
>:-)
OK, including header file. Please, try to get an idea of the avaible commands 
yourself if you can. I never looked further than I needed to do (apart from 
some very quick looks): that's enough of a challenge as it is already!

>    If you say Linux, then, again how? nVidia divers for Linux are binaries.
No. Manufacturor supplied drivers are. Those are _not_ included in the 
distributions. Check out the XFree86 sourcodetree, you'll find open source 
drivers there.

On a sidenote, I just checked RedHat compatibility for nVidia cards. TNT1-
GeForce3, 2D only. In fact, my driver goes further already apparantly ;-)

>    What do you mean by that comparison?
compare the data-amount that have to be moved for both. It's almost nill 
compared to very much.
Unless of course computations have to be made for non horizontal and non 
vertical line. (can't remember the english word for such a line :-/  )

>OK, another questions:
>    Does Linux's XFree:
>        1) use double buffering?
>        2) use a virtual screen?
>        3) handle offscreen bitmaps?
No,
no, and
no AFAICT.

The BeOS drivers are _much_ better defined. I have spent considerable amounts 
of time just testing for actual limitations so I can setup those virtual 
modes correctly for instance. This info cannot befound elsewhere (no header 
files, no linux sources or comments: they just 'don't care': A linux user is 
supposed to be technical. He or she should not set a mode that does not work. 
We however, (should) try to free the user from that burden. Hence my precise 
work on this.)

>Thank you for your help!
You are welcome.

OK: Got to sign off for tonight! The other mail(s) will have to wait a day or 
two more :-/

Best regards,

Rudolf.

-------------------------------------------------------------------
Hi there Adi,

Sorry about the delay: I am doing my best to keep answering all my mails 
_and_ do some coding in between. It's hard sometimes though due to large 
amounts of mail, or real life :-/

Anyway, here it is ;-)


>> One important thing for use with overlay bitmaps is this:
>> You (app) may _never_ copy a bitmap pointer to another var. You _must_ use
>> the original pointer. When the user changes desktop resolution for
>instance,
>> the overlay bitmaps will be destroyed by the app_server, the mode will be
>set
>> by the app_server, and then the app_server requests new overlay bitmaps
>from
>> the driver.
>    What about that data that those 3 overlays contained?
>    BTW you were referring to the value returned by BBitmap::Bits(), isn't
>it? not BBitmap pointers!
Yes, you are right. It's the pointer returned by that function. As the Be 
Book says:
"Returns a pointer to the bitmap data"

So it _is_ a pointer. Which is should be I guess, as a pointer can be changed 
to point to another adress.
A copy of this pointer can _not_ be changed by the system however.

>    Help me here a bit! The system has linear memory space, where does
>graphic memory fit in? How can that be accessed? Does the OS kernel maps
>graphic RAM somewhere? 0xC000? If OS kernel with its virtual addressing does
>that, and if  graphic RAM be mapped by it, AND if  the system has the max of
>RAM 4GB, how can video memory be addressed?
The graphics kernel driver uses a function called map_physical_memory() to 
map the areas in the cards (that are mappable) itself, to look like there in 
main memory. Once you mapped areas, you can access them as if they were RAM 
in the mainboard. this is called memory mapped I/O.
You can map areas with no user space access, read only, write only or full 
access.

The old ISA cards that use memory mapped adresses below 1Mb are not really 
useable by BeOS AFAIK. Those cards used the adres you mentioned indeed. The 
current cards however are just mapped 'somewhere convenient' into the 
complete 32bit adress space AFAIK.

If you would literally have 4Gb RAM in your system, I guess mapping cards 
will fail, or some of the installed RAM has to be disabled. The 4GB space is 
shared between RAM and devices.

Mapping applies for all graphics cardRAM, and most registers in the chipset. 
Some older cards are partly 'PCI' and partly 'ISA': those can map the RAM to 
memory, but not (all of) the registers. Registers that cannot be mapped to 
memory will be accessed by the accelerant via kerneldriver calls. The 
kerneldriver uses the ISA and/or PCI I/O functions to access those registers 
in this case. This also applies for PCI config space registers that might be 
needed by the driver, _if_ they are unmappable. If they _are_ mappable, that 
means they are both accessible from PCI config space (which is _not_ mappable 
directly), _and_ they are accessible in the same way the normal mappable 
registers of the card are. If you map that area, you also map the PCI config 
space registers for that card then.

>    To answer your question: No. BBitmap::Lock() and Unlock() do EXACTLY the
>same thing as BWindow::Lock()/Unlock() because they actually call BWindow's
>methods.
Here you have to help me :-/
Can you explain in just plain english (for dummies in this case) what these 
functions are used for? It's unclear to me.. :-/

>    There are 2(undocumented) public methods in BBitmap's class declaration,
>witch I can't test right now:
>         status_t LockBits(uint32 *state = NULL);
>         void UnlockBits();
>    I don't have a disassembly of libbe.so either, but, I bet it sends a
>message to appserver to acquire an internal semaphore, status_t returning
>B_OK if successful.
>    I don't know for sure!!! Try it! :-) In fact I'm asking you to, you made
>me curious! :-)))
I am very curious too: that's why I forwarded this snippet of your mail to 
Thomas Kurschel (ATI driver) as he has the best chance to figure it out. 
Although he is a lot more busy than me with real life, I asked him to mail 
you about this anyway, and keep me informed also.

I did not yet receive a reply about this, so I'll just wait a bit more for it 
;-)

>    Thanks for explaining! Really! You wrote quite a few stories in those 3
>emails! :-)))
You are welcome! :)

>ago, I read all Microsoft had on DirectX Graphics back then, as well as
>numerous articles on the net over those years, closely following progress of
>graphic hardware. Unfortunately, I haven't done performance with it! yet!
>:-) :-(.
I can see how you can have mixed feelings about that ;-)

>> ->You have the apps and the system.
>> ->You have the graphics card driver below this;
>> ->You have MESA (software openGL) below this.
>
>    Nope! I don't think so. The order is the same:
>        app
>        MESA
>        driver
>
>    What happens is: OpenGL looks for a feature in driver, if it finds it,
>uses it. If not... software emulation.
>    90% sure. At least that's how I remember! :-)
Hmm. Could be. I was just 'quoting' what I've been told by some 'anonymous' 
user. Maybe you could ask Thomas about this.. If he has something to say 
about it, I'd like to hear it as well...

>    :-) I know... remember... I work on the server. :-)
Aha: so this is already in place then? ;-)

>code for OBOS's app_server? Yup! Me! :-)
I suppose it _is_ fun to setup this important part of the system ;-)

Anyway, I just told you this because I happened to monitor this. I am glad 
you recognize it ;-)
Another thing is that the app_server only aquires the acc engine to do a 
command list (one command with a list of arguments). The app_server then 
releases the engine only to acquire it again if it wants to use the engine 
again (apparantly). So it owns the acc_engine every time only over a very 
short period of time.

Just telling because I monitored it. I guess it's important for the obos 
app_server _not_ to aquire it and just keep it ...

>    Assuming mode="resolution change", I don't think the driver can bilt a
>portion of the old resolution into the new one!! Or CAN it?!?!? 8-|
'Simple' engines cannot, while those 'advanced' 3D cards might be able to do 
it. I _think_ I saw something regarding this somewhere, but I am not sure.

This means the engine would need to be told (just guessing a bit):
-> the old space
->the new space
->the old bytes_per_row,
->the new bytes_per_row,
->the rectangle source coor and size,
->the rectangel dest coor.

Of course the RAM those old and new screens reside in, must be not too far 
apart. I suppose they possibly may overlap in theory.

Anyway: for R1 I wouldn't try to do this, you are again talking about engine 
commands rarely used on linux XFree AFAIK.

>> Now I want to say one thing about the cursor: Strangely enough the
>app_Server
>> requests these hooks from the driver only on startup. _Not_ after every
>mode.
>    So you want that on a resolution change the following hook to be called:
>typedef status_t (*set_cursor_shape)(uint16 width, uint16 height, uint16
>hot_x, uint16 hot_y, uint8 *andMask, uint8 *xorMask);
>    ?
this is _already_ the case I expect. set_cursor_shape is called numerous 
times.
I meant this:
void * get_accelerant_hook(uint32 feature, void *data)
for:
(SET_CURSOR_SHAPE);
(MOVE_CURSOR);
(SHOW_CURSOR);

(this is also the way it happens for the acc engine commands (monitored the 
actual acc_hooks. Did not yet look at acc sync hooks.. I think those are not 
re-exported (re-aquired or what ever you'd call it :) though) , and the 
overlay commands BTW)

>> BTW2 ADI: Can I rely on you to make my mails known in the openBeOS
>> 'community' as far as is needed according to you? I'd hate to write this
>more
>> than once... Thanks!
>    I think only DW, Gabe and Marcus should know about this. I see no point
>bothering other people.
OK. That's what I meant :-)

>> Unfortunately DW and I are apparantly not able to communicate
>professionally
>> about this technical stuff. While he's a nice guy, and the few 'talks' we
>had
>> were nice, he systematically stops responding to my mails once they get
>too
>> technical.
>
>    One reason may be you explain how stuff works. :-) I'm under the
>impression that you are a guy that thinks with 1) 2) 3) ... You also are
>very direct! Although you DO explain ALL there is be known, you do it in a
>way that make people dizzy! :-) I'm having quite a time understanding what
>you want to say, only on the second/third reading really understanding what
>you meant. Try to sound a bit clearer, especially because we're discussing
>technical problems. :-) Please don't mind! :-)))
I guess you are right about me. I just create a waterfall of information :-)
I understand that can make people dizzy, but I do it also to 'protect' myself 
against forgetting to tell you important 'related' things that come into 
mind: I might just as easily forget to mention them alltogether if I don't 
just spill them.

I guess I am kind of hoping you take the time to 'order' things for me in 
your head or in some doc., and come back on subjects that need extra 
explanation. This way I know you already know about some things that 
otherwise might be forgotten.

Also, you probably need to keep in mind, that what I tell you about those 
engines will be somewhat biased at the least: If I hear you talking about 
using a whole lot of new acc engine functions in whole new ways (for non-
Windows that is) I see a huge pile of work coming this way, which I honestly 
don't know if I want to even try to get it working because of the amount of 
work required.
Thomas and I sometimes talk a little bit about 3D in the drivers, and the 
general feeling is we are already tired of 3D before we would even begin. The 
clearer the picture gets about what needs to be done to get it working, the 
more tired we already become. This is due to understanding/seeing what the 
amount of work is that we would need to do :-/

I _do_ thing it would be nice to see double buffering (or whatever you'd call 
it) in BeOS, so we can prevent tearing.

I've been thinking about it a little, and it seems fairly simple to setup:

->create front and back buffer
->draw in back buffer by app_server and apps
->during retrace, blit back_buffer to front buffer.

That would mean you use the current buffer as backbuffer, so you only need to 
'add' a frontbuffer, and implement blitting to it during retrace.

Both simple tasks to do (as long as those buffers are in fact one large 
virtual workspace: in height), and it _could_ be done inside a driver without 
BeOS or the app_server even knowing about it!

The hard part is getting the blit to work during every retrace: How do you 
make sure you can 'squeeze' it in between app_Server and/or app_commands? Or 
do you need some kind of app_server sync to get this going reliably? If so, 
then the app_server _does_ need to know about it after all..

Anyway: this is a subject I am going to look into myself someday, as Matrox 
TVout on G450/G550 relies on the same trick! In windows the driver does this: 
the downside is you see the 'updates' rate on TV dropping to about 4 times 
per second on heavy acc_engine load for 3D or 2D.
This needs to be overcome in order to be usable I think... (Both for TVout 
and double buffering the normal framebuffer)

Best regards,

Rudolf.

---------------------------------------------------------
Hi again,

>I didn't followed closely the thread on R3 legacy drivers, so don't mind me
>asking a simple question:
>    For R5 and OBOS R1 we should use ONLY Accelerant.h ? GraphicCard.h is a
>reminiscence from R3, isn't it? we shouldn't we that, don't we?

GraphicsCard.h is the interface used for R3 graphics drivers. It's still used 
in a few spots.

-------

Spot 1:

For applications and the API only BWindowScreen is of importance. Have a look 
at the BeBook for R5 for BWindowScreen. You'll find many references to the 
file GraphicsCard.h.
In every case were structs or functions are used that are based on this R3 
interface, BWindowScreen must do translation for R5 drivers. You have to tell 
_me_ if BWindowScreen is part of the app_server. (Is it?)

AFAIK Jack Burton (Italy) is working on the implementation of BWindowScreen. 
Does that mean it's _not_ in the app_server?

OK: In order to do the translation, BWindowSCreen loads a clone accelerant 
'privately'. It asks the acceleration hooks from the accelerant _if_ they are 
requested with BWindowScreen's CardhookAt() function. So if only blit() is 
requested, the fill_rect() hook is not requested (Of course this is a detail 
not very important: it doesn't matter much if a obos BWindowScreen just asks 
for all the hooks at once I think, apart from maybe a little speed slowdown 
if so.)

A difference for example that the acc hooks had in R3 compared to R4/R5 is 
that in R3 you can only send one set of arguments to the command, so for one 
acc engine execution pass. These days you can send a list of argument sets, 
so the engine can be told to do a lot of blits in one call.

Besides the CardHookAt() function, also some information functions such as 
FrameBufferInfo() are s