[haiku-appserver] Re: drawing thread
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 22 Oct 2004 19:48:41 +0200 CEST
Adi,
> Maybe if Haiku grows enough, we'll receive support from nVIDIA and
> ATi
> with drivers supporting standard sharders specifications: 1.0, 1.1,
> 1.2,
> 2.0, 3.0.
Another option would be a port of DRI I guess: assuming Linux closed
source drivers already have such support. But a port of DRI requires me
to take some in between steps first to understand how this would work,
and to let me adapt the 2d driver to be able to cooperate with those
DRI drivers.
In between steps would be just what I plan to try: 'port' (rewrite) the
utahGLX opensource nVidia driver to work with MESA on BeOS somehow,
then see what's the diff between utahGLX and DRI, and then DRI itself
could be next.
OK: that is me dreaming a bit :)
> > 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.
>
> I'm not getting this...
> When PollerThread needs to copy a bitmap onto screen, it gets all
> it
> needs and then send a this data to the engine. The engine then
> fetches
> the bitmap from main mem and then blit on screen.
> Am I wrong?
Correct. But you are talking about _one_ bitmap. only if you'd tell the
engine to fetch multiple bitmaps _at the same time_ you would gain
speed if GART and aperture are used: the two items will let the engine
think it can fetch _one_ chunk of memory instead of _multiple_,
scattered chunks of memory. (scather/gather stuff) So this hardware
makes scattered pieces of memory appear as one big chunk inside the
graphics aperture: this is where the engine fetches it from. The fact
that it adresses this adress space will let the hostbridge hardware do
translation to the real adresses where the different bitmaps are
located. Hence also the 'continues' updates needed for the GART table:
it contains pointers to those bitmaps along with the sizes in multiples
of pages (4k) or so. So alignment is probably important here too.
Maybe knowing (now) how this works gives you extra ideas for the
future: don't know. :)
> > 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
> > RAM?
> > 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.
>
> I understood perfectly what you said. Yes, that is the way I
> referring
> to also. This misunderstanding is because I was looking from
> app_server's perspective.
> Let me explain again:
> How do we do double buffering? We draw in mainMem, when drawing is
> done, we(the CPU) copy(ies) from here to graphic card's memory - the
> part that is mapped for screen retrace(visible on screen)
> If we want to use AGP, I think(after what you explained), that
> after
> drawing is done in mainMem, we should instruct the graphic engine to
> fetch that bitmap from mainMem and blit it on screen. (Maybe a blit
> is
> not necessary and it can directly copy mainMemBitmap to screen mapped
> video memory.)
Yep. Correct. So the engine would be instructed by you to do a blit:
source is bitmap in main mem, dest is directly in the onscreen buffer.
This is possible after the driver architecture would be updated for it.
This is using real AGP transfers by the engine (automatically used by
it because we'd specify it's blit source to be in main mem)
So not now: you have to let the CPU copy it onscreen, which will
automatically be bus-accelerated with burstwrites and (AGP) FW. This is
no official AGP transfers, but just using a 'extra feature' of AGP
called FW.
Again, you should understand that the first method just now described
(real AGP transfers) is least stable, then comes AGP FW, and then comes
standard PCI as being most stable. AFAIK. So for optimal compatiblity
it would be very nice if you not rely on just real AGP transfers in the
end, but still be able to fallback to the current driver architecture
only using local acceleration (local in graphicsmem), so if needed
standard PCI transfers can be used.
> Drawing instructions are in videoMem. We allocate memory in there.
> Drawing instructions are executed on the GPU.
OK, that was wat I expected also.
> Not dreaming, just need the latest drivers form nVIDIA and ATi
> ported
> on Haiku. ;-) :-)
> Yes, you can say I'm still in a dreamland. :-))))
Unless at some point DRI could be used with closed source drivers I
guess?
> >> 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.
>
> 3. Draw only in the off screen buffer, and blit the differences after
> the page flip? This way we can use the 2D acc engine.
Yes, that is exactly what I meant for 2. Good addition :-)
> There is no reason to flip on every retrace. Page flipping should
> be
> commanded by app_server when drawing into backbuffer is done.
Agreed.
Bye!
Rudolf.
Other related posts:
