Warp3d synchro/double-triply bufferging

[Karlos]

Getting back to the WaitBVOP() issue...

I ran some simple tests (via executive/top) using the code I sent to kas1e and I think Piru is right about the busy waiting - the task uses a lot of CPU when just switching the screenbuffers and waiting for synch with WaitBVOP().

I have never experienced problems as a result of this, but then any single threaded application likely spends only a part of its time waiting for the synch.

I'll try the proper way and see what that does for it.

[kas1e]

Want to up, this old thread. What about this kinds of double-bufferings over WarpOS ? Will be here some kind of slowdowns in fact of context switching ? If yes, how it possible to avoid them ?

[Karlos]

There's always a slowdown with context switching.

The best way to minimise this is to handle them yourself. Identify all the system calls you need to make at least once per frame and put them into a single 68K function which you call manually using Run68K().

For example, you'll want to flip the buffer. You'll also possibly want to read the messages from your window's IDCMP port. I used to use PPC native callbacks for input under WOS. To do this, each frame I captured all (well up to a limit) the IDCMP messages on the 68K with a typical while loop and decoded them into an array that formed part of my display "context".

When control passes back to the PPC, the array of data was then traversed and the PPC native handlers called for each event.

Towards the end, I had at least three jobs that were 68K native - flipping the buffers, capturing the IDCMP message content (which included mapping raw printable keycodes to characters etc) and updating an AHI buffer for the sound.

Everything else was PPC native - handling the callbacks, mixing the sound and so on. This led to about 2 full context switches per frame including the one caused by W3D_LockHardware() and the manual one I did. It's only a pity they couldn't have been merged somehow.

[kas1e]

Hey Karlos, you still alive ? I tryed to write you some time ago, but looks like you cnahge email ..

Well, W3D_LockHardware based on Warp3dPPCBase will also have context switching you mean ? (why? i think it will be, if i will use warp3d.library (not ppc ones) from wos application, but with warp3dppc.library, here is must be no context switching, right ?)

Also context swtitching in fact of idcmp, will be have big slowdown or not so ? At this moment, i see really slowndowns if compare it with 68k version - in SwitchBuffer function. I dunno why, in fact of only WaitTOF(); or in fact all of this 68k fuctnions like ChangeScreenBuffer and WaitTOF.

As i understand, i just need to create fucntion like this:

void SwithDisplay_WarpOS(W3D_Context *context, struct Screen *screen)
{
  Run68k(here is an old 68k fucntions)
}

?

[Piru]

As Karlos already pointed out you must group as many m68k calls as possible to single m68k code section which you then  Run68k. The reason is that each single m68k call from WOS context results in full cache flush for both m68k and PPC CPUs. All OS calls generate such a context switch.

In my code I had input processing, screenbuffer switching, optional palette changing and AHI audio I/O in single m68k function. This was PUP code though, but the principle was the same.

[Karlos]

@kas1e

Yeah still alive, but so busy I probably forgot to reply.

You do get a context switch with the PPC native W3D_LockHardware() call because it in turn has to call some 68K functions when it locks the various resources. That's pretty unaviodable. What you don't want is to make things worse by adding a dozen more of your own, hence the solution of gathering the OS calls together.

[kas1e]

Karlos, question for you If i remember correctly, you know Bvision driver very well ? So, maybe you can give me a hint/point about what i can do with it: i have a w3d request, with 15/16/24 bit modes on bvision. If i choice 15/16 modes - gfx looks ok. If i choice 24bit modes, i have strange corruption.

here is 15-16 bit example:

here is 24bit example:

sources are the same, and works fine on a1/peg/winuae/a1200/a4000(voodoo/radeon/cybervision). Only on bvision this kind of corruption.

Modes for texture is: RGB565, ARGB1555.
States: Gouraud only.

Have any idea maybe ?
It's not so matter of course, but i am just in interest what is it and how i can avoid it

[Karlos]

Hmm. Exactly which version of the bvision driver is that? I don't recall getting that kind of problem with 16-bit textures on screens with greater depth than the textures.

[kas1e]

Karlos, latest public version with latest patchs. I tryed it on 3 different setup. (ppc/040-33/bvision , ppc/040-25/bvision and my ppc/060/bvision). In all case result with 24bits are the same.

[MastaTabs]

for me it looks like pixel are swapped. Is it really a 24bit mode and not 32bit ?
If ti 24bit and its handled as a texture I'd say there is a word swap when transfering the texture to graphics memory.

[Karlos]

It's been quite a while, but I don't recall that the Permedia2 supports hardware 3D acceleration in 24-bit packed pixel mode - I'm guessing it's really 32-bit :-?

@Mastatabs

Yeah. Notice that the colours of the rotated pixels aren't affected; that suggests it isn't the 16-bit texels getting swapped, whatever the corruption is, it's happening in the framebuffer itself.

If I get a chance, I'll have to look to see if I can reproduce the effect.

@kas1e

Is this fullscreen or windowed (guessing fullscreen) ?

[kas1e]

Karlos, it's fullscreen mode, i just open 640x480 screen and open 640x480 window on it. For W3D_RequestModeTags: aslsm_minDepth:15, aslsm_maxdepth:32. For openscreen:
SA_Depth: 32. Why is here 32: becouse if i will setup 16, double-buffering just do not works for voodoo3. (but on voodoo3 only 16bit modes can be choiced, stange a bit).

[lionstorm]

funny to see that I am getting the same kind of corruption on my amigaone with radeon 7500 when launching QW... :crazy:

[kas1e]

I was test on one machine a 'wipeout' game. And in window, with 24bit of depth, with W3D_Permedia2_PPC.library 4.2, the same corruptions, look at this:

With 16bit depth of screen:


With 24bit depth of screen:


If change W3D_Permedia2_PPC.ibrary back to the 4.0, all os ok. With 4.2 this kind of corruption. And the same with W3D_Permedia.library.

I think if the same problem can be happened on A1, maybe it's problem with some kind of setup settings ?

ps. also i checked on 2 bvision configs, some ppc demos (from encore) and, if you use 24bit screen, and run these demos in window mode, you can see this kind of corruption while text rendering is happenen! looks like as Karlos pointed, bvision 4.2 driver have buggy handler of textures which depth is lower, then mode which was choice. (expectally problem with 16<->24bit)

[kas1e]

have someone any idea, how works with warp3d in windowed mode ? i mean for example, how do smooth scrolling or fade effect, if there no double-buffering possible ?

[kas1e]

Let's up this pretty old thread about warp3d.
Right now i tryed to write somethink warp3d based for AROS, and there is an interesting point: Aros not have ScrollVPort() or ChangeScreenBuffer() (ie. aros not have system friendly double-buffering, at moment only on at all - dunno). But i still in interest to avoid flikiring here and so on.

So, main idea which i talk about was by Alan (wazp3d author), it's make a 'window double-buffer' (about someone asked in this thread before). Ie, you create a window on screen (public, on your own), and after make a new buffer with copy of bitmap. Like this:

Code: [Select]


    InitRastPort( &bufferrastport );        
    ScreenBits  = GetBitMapAttr( window->WScreen->RastPort.BitMap, BMA_DEPTH );        
    flags = BMF_DISPLAYABLE|BMF_MINPLANES;        
    bufferrastport.BitMap = AllocBitMap(large,high,ScreenBits, flags, window->RPort->BitMap);        
    if(bufferrastport.BitMap==NULL)        
        {printf("No Bitmap\n");goto panic;    }        


After create a context, which pointed to copy of our bitmap (i.e. our buffer to which we will draw for first).

Code: [Select]


    context = W3D_CreateContextTags(&Error,        
        W3D_CC_BITMAP,(ULONG)bufferrastport.BitMap,        
        W3D_CC_YOFFSET,0,        
        W3D_CC_DRIVERTYPE,W3D_DRIVER_BEST,        
        W3D_CC_INDIRECT,TRUE,        
        W3D_CC_DOUBLEHEIGHT,FALSE, //DoubleHeightON,        
        W3D_CC_FAST,TRUE,        
    TAG_DONE);        



And next just draw somethink by warp3d, and after it's done, you just copy this bitmap-buffer content to the your window, like by this way:

Code: [Select]


BltBitMapRastPort(bufferrastport.BitMap,0,0,window->RPort,0,0,large,high,0xC0);            

So.. it works, but it's not so fast of course if compire it with screen double-buffering.

Maybe someone have any other idea of how can be done double-buffering by fast way ?