[haiku-appserver] Re: drawing thread

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 21 Oct 2004 14:34:30 +0200 CEST


> > Does Accelerantdriver already has the engine stuff in now?
>       AFAIK, no. You should give Gabe some examples of how to use the 2D 
> engine.
Hmm, so I need to think about it, as I never exactly needed to think 
about that before.

>       We have no other choice if we want d.b. At least I don't see it...
>       That means we should use MTRR to the best.

> > So this kind of doublebuffering would be fast (bursts, FW) and 
> > sounds 
> > like a good plan (double-buffering 'source' bitmaps are in main 
> > mem).
> > If locking is done: but you could of course just benchmark both 
> > options 
> > for yourself and see if I am correct ;-)
> > 
> > If you _don't_ use doublebuffering, then suddenly you can't 
> > 'guarantee' 
> > every thread will do serialized access optimally: now the app's 
> > behaviour will determine this. Video will off course be 
> > 'serialized' in 
> > the app, but if some figure is to be drawn onscreen (a transparant 
> > box 
> > or whatever), then this can't be done in a serial fashion (because 
> > the 
> > content of the box is not touched).
> There are 2 cases:
> 1) we have no transparent layer in app_server
>       * without d.b. it is guaranteed drawing is done right, because of 
> the 
> non-overlapping visible region each layer has.
> 2) we have transparent layers in app_server.
>       * it is no problem for views inside a window. They are always 
> rendered 
> from back to front.
>       * _it is_ a problem with transparent windows as they are 2 threads 
> drawing independently. Here, there is no other solution than to force 
> double buffering for the transparent window or not to allow 
> transparent 
> windows when global double buffering is disabled.

I'm not sure I follow. I didn't think about app_server internals. I was 
merely thinking of some app that for some reason directly writes in the 
buffer in cardRAM. You cannot foretell what an app is going to do. Who 
_knows_ what it wants.. Maybe it wants to write something to the 
highest adress pixel, and then the lowest, and then the highest - 1, 
etc.. This is not serial and never will be accelerated by the bus. If 
it were done via doublebuffering however, it would: because the source 
buffer can be copied to the destbuffer in a serial fashion, while the 
app may happily poke around in the sourcebuffer residing in main mem.

> > It's a good idea to have (at least) 32bit word alignment in place 
> > for 
> > the source bitmaps in main mem BTW.
>       Yup, Christian Packmann also said that in regard to MMX/SSE 
> acceleration.
Sounds very valid :-)
I am saying this because of other reasons however: I know I stated for 
instance MTRR working with bytes, but come to think about it, I think 
it was 32bit words.. Probably there are more places in the hardware as 
well that prefer these kinds of alignments.

>       I'm talking about GeForce 3/4/5/6 pixel shaders. You know... the 
> biggest revolution in 3D graphics in years! Programs that can be 
> executed on the GPU - Drawing/Filling ovals, shapes, etc.
OK, sounds nice.
One problem exists however: these programs are kind of a machine code 
that is card architecture specific. The instructions are one of the 
best kept secrets in the graphics industry I am assuming (so AFAIK). 
This means that _this_ is likely going to be a part of the engine we 
won't be able to use. At all. If I setup 3D acc, it will be a mixture 
of real 3D acc and MESA. I think I said this before at some point...

AFAIK the input program delivered by directX or openGL apps is compiled 
or interpreted somehow, and translated to the internal code the engine 
knows before being executed. (lets call it microcode for now)

Then one thing more: you say the shaders can execute programs. True, no 
doubt. But they have to stay somewhere: in the graphics memory that 
(maybe) doesn't get swapped out on low mem like other parts containing 
bitmaps and other 3D scene stuff. At least, that would be logical to me 
ATM. (So _not_ inside some internal extra buffer, though I might be 

> > This is a step I am going to investigate at some point, hopefully 
> > in 
> > the not (too) distant future. The main problem here is to get cache 
> > coherency working OK I expect. There's a second step also (GART and 
> > aperture), but that only improves speed if you are going to fetch 
> > mutliple bitmaps 'simultaneously' (so that's one reason why 
> > normally 
> > this stuff is only used for 3D acc: the second reason is stability.
>       I'll give you one too:
>       We'll need to copy regions from main memory, that means lots of 
> rectangles which can be interpreted as: many bitmaps 
> 'simultaneously'. 
> :-) ;-)
Hehe. IF that is true, than those GART/aperture AGP transfers speedup 
the process more.
However, I don't see it right now. You can't foretell what part of the 
screen you have to update next: as you can't foretell where a window 
hiding some other stuff will be dragged next (direction might change 
for instance). The way I see it is that you will be in fact fetching 
different pieces of different buffers at different times.

> > If you want to use 2D acc later on, you should consider real AGP 
> > transfers 
> > and so acc itself (by letting engine fetch from main mem) as being 
> > an 
> > option.
>       Of course. That is 99% of what we'll have in R1, except that, 
> instead 
> of instructing the CPU to copy in vidMem, we'd instruct the graphic 
> engine to fetch from main mem.
>       Am I wrong?

I'm afraid I can't answer because I am not following you. I think you 
misread my sentence?
lets rewrite it a bit:
question: how are we going to transfer a bitmap to the graphicscard 
1. does the driver report it can do acceleration on main mem? yes: use 
it (in the way you state: engine fetching from main mem). No:
2. lets write the bitmap, preferably in a serial fashion, to the 
graphicscard. But where?:
-------- 1. does the driver report it can do local offscreen 
acceleration? yes: use triple buffering if you want. No,
---------2. write directly onscreen.

And another subquestion might apply:
->Do we have AGP FW? Yes, use it. No: shutoff bustransfer intensitive 
extra system drewling feature.

Anyway: or something to that effect.

>       With pixel shaders at hand we won't be needing main memory anymore.
How do you figure?

> I'm SURE this is the way to go.
So I'm afraid you are a bit too much in dreamland... Although I 
certainly would love to see it :-)

>       Fetching from main mem is the best solution until we reach that 
> stage.
Of course. For AGP that is the fastest solution by far. But still, keep 
in mind we will be working on PCIe in the near future probably. I for 
one still have to readup on that subject to see if a AGP like setup 
still exists, or if this 'feature' has been totally abandoned for 
something better.

PCIe is said to be PCI compatible: not AGP compatible. Although nVidia 
_for now_ still uses a local AGP bridge on their cards. This is just a 
temporary marketing/financial workaround however. If PCIe is going to 
be a success, they will drop that immediately probably.

> > (Quake2 on my laptop runs at 3.9fps already with MESA6.1, so in 
> > openGL 
> > mode (compared to those 92FPS in internal software rendering mode I 
> > once talked about))
>       You need good 3D drivers. I'm sure Quake2 will run at 600-700FPS 
> with 
> the same settings.
Of course. But the point was, that if you keep the 'load' relatively 
low, you could live with MESA only on systems that lack hardware acc.
I am certainly hoping that any desktop system will not need to use 3D 
engines as heavily as those nice games...

On the other hand, maybe your 3D stuff should be that 'drewling 
feature' that simply can be shut off if a system does not support 
hardware acc. But still: keep in mind that we will probably never have 
full featured acc: it will always be a mix between some hardware acc'd 
functions and software based stuff.

>       I've thought about that also, a little. One simple solution is to 
> have 
> app_server use only 1/3rd of video memory, but that is not a viable 
> solution. :-P
Indeed. Here you can think of multiple strategies as well I guess. If 
needed at all: who knows.

> > Hey, I still miss something else that's interesting as well I 
> > think. I 
> > understand what you mean by double/triple buffering, and I 
> > understand 
> > why you want to do that. But still, I am wondering about another of 
> > BeOS it's shortcomings: updating the screen in such a way that you 
> > won't see distortions if you drag a window (for instance). I mean: 
> > tearing. Some people talk about double buffering in this context: 
> > having a copy of the entire screen in cardRAM that is switched 
> > between 
> > during retraces.
>       You mean: page flipping. :-) ;-) B-)
Yeah, yeah: you could call it that. Only normally it's used for apps I 
guess, but I meant it for system-internal use only.

> > This of course requires both buffers to be updated 
> > with everything, and you can talk and think a lot about strategies 
> > to 
> > get this done with minimal overhead.
>       I'm listening... :-)
This is a subject I haven't thought about much. Two versions could be:
1. just draw everything to both buffers, but delay writing to the one 
onscreen untill it's offscreen.
2. Draw only to the offscreen buffer, and draw just the differences 
applied there to the onscreen buffer once it goes offscreen.

> > But the goal it serves would be a perfect, undistorted screen 
> > output at 
> > all times, which would be nice to have as well at some point.. 
> > (just 
> > updating the single screenbuffer during retrace is much too 
> > expensive I 
> > guess, as this leaves very little time to update the buffer: the 
> > retrace is a relative very short piece in time compared to 'full-
> > time 
> > acc', as is used now.)
>       Wait a second, you are not talking about page flipping?
Not as you saw it, no. Talk to Apple users: it seems this system I am 
talking about is at least used there.

>       A while back you were talking about Allegro game library. Isn't 
> page 
> flipping the technique used by it for double buffering. Isn't the 
> page 
> flipping process ordered by the gaming library, and done on next 
> retrace?

> Then, why are you talking about _every_ retrace?
because now we have a system 'feature'. OTOH: if nothing changes 
onscreen, no flip is needed of course. You could think multiple ways 
here as well (as usual :)
1. just flip every retrace
2. only flip if something changed.

Whatever.. Maybe if you start thinking about this stuff a reason for 
one of them comes to mind ;-)



Other related posts: