FreeLists / haiku-appserver / [haiku-appserver] Re: drawing thread

[Adi Oanca <adioanca@xxxxxxxxxxxxx>]

Hi Rudolf,

Rudolf wrote:
> Hi guys,
> 
> I am reading along with this interesting stuff, in order to see if I 
> can get some idea of what's going on and how it all might work at some 
> point..
> I have a remark to make about this locking/doublebuffering/ parallel 
> drawing onscreen, that you probably should keep at the back of your 
> head:
> (I hope one day I'll know what exactly the AccelerantDriver is and what 
> BitmapDriver is: I am looking for normal driver parallels of course ;-)

        DisplayDriver is a class which provides methods for drawing (FillArc, 
StrokeRect, etc.). The routines are inside DD.
        It's up to a subclass to provide the basic methods (StrokeLine, 
FillRect, _and_ GetBufferBits() - not exactly those names, but this is 
the idea.).
        Now, AccelerantDriver uses 2D accelerated driver where possible, where 
not, it writes directly to frame buffer.
        DirectDriver, if I'm not mistaken, is the same as ScreenDriver and uses 
a cloned accelerant.
        BitmapDriver, despite its name I'm not sure it has something with 
drawing on screen, only in bitmaps.
        Last, the one we use ATM, ViewDriver which uses a BWindow/BView/BBitmap 
combination to draw through R5's app_server.

        We use ViewDriver because our instruction clipping code (when in an 
update you are allowed to draw only in a specified region) is not in 
place and we use BView::ConstrainClippingRegion(&reg) for that.
        When Gabe finises the clipping code(read DisplayDrive it's done) we'll 
be able to use the full acceleration an accelerant can give us.

>>      It can be seen we haven't talked in a long time. :-)
>>      I don't know how double buffering at DD level could work. In fact, 
>>I'd really like you to explain 
>>us, cause' you're making me very curious.
>>
>>      My opinion:
>>      I think you are wrong. DisplayDriver is a drawing framework. How it 
>>gets things done it's its 
>>business, it can directly use hardware acceleration or use CPU to 
>>draw in buffers.
> 
> 
> -->I am assuming here that these buffers reside on the Graphicscard.

        In R1, no.

> If not, you can ignore this Email.

        Not going to do that as we're interested for R2. :-)

> I am assuming this because the option 
> of hardware acceleration seems to exist from the sentence above.

        2D acc. FillRect, InvertRect, FillSpan, DrawLine, HW cursor.

> The sentence also implies that both the source and destination of the 
> drawing actions are residing on the graphicscards RAM, or acc would not 
> be possible (ATM at least).

        HW cursor is possible. The rest, no. It's no problem, we'll use MMX, 
SSE. That is until you provide us with drivers that can use pixel 
shaders. :-))))

>>      You do not need to lock it to use its methods. Instead, those 
>>methods should get a buffer and a 
>>drawing context. Based on those arguments, it draws within specified 
>>clipping region inside buffer. 
>>This way you need not to lock DD, and in a multiprocessor environment 
>>is could be a very good thing 
>>as another CPU could safely draw onscreen the contents of other 
>>windows.
> 
> OK, here's my 'warning':
> While you are correct in saying you can draw 'parallel' in those 
> regions inside the buffer, there may be important performance penalties 
> if you don't serialize the access after all. The 'burst mode' of 
> writing across the PCI/AGP bus depends on serialized access (at least 
> beyond those say 32bytes blocks, within these blocks it doesn't 
> matter). Burst mode (fully automatically generated by the system's 
> hardware) works in PCI mode, and in AGP mode. In AGP mode bursts are 
> the ones being accelerated with the 'fastwrites' feature.

        How do we serialize access?

        If we're doing a blit(copy line by line) from main mem to on-screen 
video mem, won't the HW generated burst step into action?

> If indeed both the source and destination of the drawing action reside 
> in graphicsRAM, this performance issue only exists if you use non-
> accelerated drawing actions, because the CPU would need to read the 
> data across the PCI/AGP bus, and then write it back, while the 
> acceleration engine keeps it local on the graphicscard RAM.

        I don't think we'll be using videoMem that way, and I'm speaking about 
R2 here. R3, who knows, if we can use those pixel shader units... :-) 
After the talks we've had, I thought good and wanted to ask your opinion 
on this:
        Do you think it's good to draw(with the CPU) in vidMem off-screen 
surfaces(I mean double buffering in videoMem)? I say no because of the 
PCI bus; writing _and_ reading is expensive. I think, a better solution 
is to do triple buffering. Have an off-screen surface in mainMem into 
which a window will draw. When drawing it's done, blit this in an 
_off-screen surface in video memory_, validate a flag it's OK to use 
that surface, and when a portion of that window is needed we use the 
2D(/3D) engine to blit on-screen.
        What do you think?


Bye,
Adi.