@thellier

Quote:

thellier wrote: @Hans >This is a bug in Wazp3D. If a Warp3D app (or MiniGL) requests direct mode, then it should get direct mode. >that should be fixed in Wazp3D then (for direct mode). I agree I will fix that in the next Wazp3D release (i mean the official v50) You can add this Wazp3D bug to my big bug-list But let resume 1) Os3 createcontext(....W3D_CC_INDIRECT...) so use indirect createcontext(....not precised ..) so use direct 2) Os4 createcontext(....W3D_CC_INDIRECT...) so use direct too createcontext(....not precised ..) so use direct

On OS4 createcontext(....W3D_CC_INDIRECT...) = fail (I tested this a while ago). This is why StormMESA won't work; it needs indirect mode and it's not available. However, seeing as Wazp3D supports indirect mode, it should use indirect mode when asked to.

Quote:

BTW well written apps that use W3D_Flush() when needed should not see the difference between direct/indirect mode.

My understanding is that software using indirect mode doesn't need to lock/unlock the context to render stuff. So, any software using indirect mode that relies on this won't work in direct mode (e.g., StormMESA).

For software using direct mode, unlocking the context implies flushing the queue because unlocking can't happen until rendering is done. You're correct that they should explicitly call W3D_Flush(). However, since unlocking also flushes the queue, it is guaranteed that some apps will rely on this.

Hans

Last edited by Hans on 13-Jul-2011 at 09:48 AM.
Last edited by Hans on 13-Jul-2011 at 09:47 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@broadblues

I tried again with the wazp3d version linked, and found I could start blender as long as I don;t request a seperate screen.

eg

bldyn -p 0 0 1023 1023

will work but

bldyn -M

which would open up a screenmode requester, will always fail to open the requested screen and fall back onto the workbench, which in my case is too high a resolution for wazp3d it seems.

It look to me that


IMiniGL->ScreenModeIsSupported(screenwidth,screenheight,screendepth)
always returns a failure no matter what is passed to it when running under wazp3d which in turn suggests an issue with


W3D_ScreenMode *Modes = IWarp3D->W3D_GetScreenmodeList();


Anyway once running under wazp3d I did a quick benchmark for ineterest sake.

A spinning cube running in game mode.

For WaRp3D I got 20 / 21 fps

For WaZp3D I got 9 / 10 fps

switching the blender patch on and off made little difference to frame rate, but I did see the partial corruption of the menus described earlier.

Last edited by broadblues on 14-Jul-2011 at 06:18 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Error is certainly in my W3D_RequestMode()
Do u know how to make a ScreenModeFilter hook on os4 ?

ULONG W3D_RequestMode(struct TagItem *taglist)
{
[..]
struct Hook filter;

#ifdef __amigaos4__
filter.h_Entry =(HOOKFUNC)ScreenModeFilterC;
#else
filter.h_Entry =(HOOKFUNC)ScreenModeFilterASM;
#endif

>switching the blender patch on and off made little difference to frame rate
a cube is not a good test as it got only 6 faces so the fragments buffering is only broken 6times per frame
Should better test a very small object with hundreds of very small faces maded from a single material
Also ppc-os4 wazp3d dont bufferize much
#ifdef __amigaos4__
#define FRAGBUFFERSIZE (64*64) /* Assume Amiga PPC got small cache */
#endif

#ifdef __AROS__
#define FRAGBUFFERSIZE (256*256) /* Assume AROS on PC got very big cache */
#endif


Alain

@thellier

Quote:

Error is certainly in my W3D_RequestMode() Do u know how to make a ScreenModeFilter hook on os4 ? ULONG W3D_RequestMode(struct TagItem *taglist) { [..] struct Hook filter; #ifdef __amigaos4__ filter.h_Entry =(HOOKFUNC)ScreenModeFilterC; #else filter.h_Entry =(HOOKFUNC)ScreenModeFilterASM; #endif

I'm not using the W3D_RequestMode() function rather I'm using an ASL mode requester and checking the result with IMiniGL->ScreenModeIsSupported, which in turn calls W3D_GetScreenmodeList() so the problem is more likely in that function.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
You are right my w3d_getscreenmodelist is bugged it return null
I will fix that in next release
Alain

Quote:

Hans wrote: @thellier Quote: thellier wrote: @Hans [quote]BTW well written apps that use W3D_Flush() when needed should not see the difference between direct/indirect mode.

I agree that the performance "should" be about the same and may be with Wazp3D. However, the 68k version of Warp3D.library added significant overhead to what should be a rather simple queuing and queue emptying of the Warp3D instructions. Performance problems include awful compiler generated code, using exec/CopyMem() for small static sized copies, only word alignment of Queued data, and excessive use of jump tables where data tables could be used. I rewrote the W3D QueueOp() and DoQueued() routines in assembler to be about 1/7 of the code size of the originals. That's a lot of fluff but, fortunately, the 68k is very forgiving of poor code as far as performance. I hope the PowerPC compiler is significantly better but I have my doubts. More than likely the performance contributed to the demise of indirect mode in W3D. Direct mode has no similar overhead as the W3D function is called right away (but the hardware has to be locked).

Quote:

My understanding is that software using indirect mode doesn't need to lock/unlock the context to render stuff. So, any software using indirect mode that relies on this won't work in direct mode (e.g., StormMESA).

That's right. For the instructions that support indirect mode queuing, the function is called without the hardware being locked. An attempt is made to add the instruction to the queue but if it is full, the hardware is locked, all the queued instructions are executed and then the hardware is unlocked. Of course certain instructions will automatically flush the queue including W3D_Flush(). It's a kind of auto hardware locking mode that is used in a significantly different way that direct mode.

Quote:

For software using direct mode, unlocking the context implies flushing the queue because unlocking can't happen until rendering is done. You're correct that they should explicitly call W3D_Flush(). However, since unlocking also flushes the queue, it is guaranteed that some apps will rely on this.

There is no queue used or allocated in direct mode so flushing is a nop...

W3D_Flush: ;input: a0= ->W3D_Context, result in d0
btst #3,($1f,a0) ;Context->state&W3D_INDIRECT
beq .direct
move.l a2,-(sp)
move.l a0,a2
bsr W3D_LockHardware
tst.l d0
bne .nolock
bsr DoQueued ;executes all the queued instructions
move.l a2,a0
bsr W3D_UnLockHardware
moveq #W3D_SUCCESS,d0
.nolock:
move.l (sp)+,a2
rts

.direct:
moveq #W3D_SUCCESS,d0
rts

That's my 68k version anyway. The docs for W3D_Flush() says "nothing happens" in direct mode also. Calling W3D_Flush() in direct mode is a waste. There is also no "indirect" queue to flush in direct mode when the hardware is unlocked unless you are getting confused with the queue of commands that can be sent to the gfx board (the rendering queue/buffer). In that case, W3D_UnLockHardware() calls the driver WaitIdle() function that waits (busy waits in the case of the Avenger driver) for the rendering buffer/queue to be exhausted before returning. Again, no need to call W3D_Flush() in direct mode.

Last edited by matthey on 18-Jul-2011 at 03:30 AM.
Last edited by matthey on 18-Jul-2011 at 03:27 AM.

@Karlos

Quote:

Yep, again I think the R200 driver for example has no support for these. A point to note is that one should never assume contents of the Z buffer are going to be valid during rendering unless you've explicitly invoked WaitIdle() first. Score 1 to the Permedia2 driver again ;)

Are you talking about Classic or OS4?
Any projects for a classic radeon warp3d driver out there?

@Ratte

I'm talking about the OS4 drivers, which may also run on Classic, providing it's runnning OS4.1 ;)

I suspect you mean 68K/WarpOS support for Radeon? As it stands, I can't say. Backporting the driver is possible but I'm not sure I have the remit to do that.

In other news, for those that are interested, I can confirm without shadow of a trout that W3D_Flush() does absolutely nothing in V5.

_________________
Doing stupid things for fun...

@Karlos

Do you think It's possible to add other developper, for warp3D development or just fix ? For example, Matthey, for the 68k part.

I haven't said that Matthey want to do that just if Warp3D developments is opened for others peoples (for 68k also and for the time between Gallium appeared)..

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@Mrodfr

No idea, it's not really up to me.

_________________
Doing stupid things for fun...

Quote:

Karlos wrote: @Ratte I suspect you mean 68K/WarpOS support for Radeon? As it stands, I can't say. Backporting the driver is possible but I'm not sure I have the remit to do that.

I don't think it would be much of a problem to add support for Warp3D V5 to the 68k Warp3D.library. The new V5 Warp3D.library functions look like they would just check the input for errors and jump to the driver library. I have a list of new function offsets but the registers for the function variables would probably have to be defined in 68k. I don't think it would be that much work too add V5 support if that is needed. I could do a patch for the original 68k Warp3D.library that adds the support. As far as the Radeon driver itself, I guess it would be P96 only (no GFXdrivers) but that would support the most popular Mediator which requires P96. I think the Radeon driver could be released without anyone from Hyperian having to compile or change any Warp3D code for 68k which they have made clear they don't want to do. They would have to be real ####s to block a 68k Radeon port that doesn't cost them any time. A 68k driver may be beneficial in finding bugs too. Of course, permission, willingness and time to make a 68k Radeon driver would be needed. There would have to be some 68k specific code added to find the PCI addresses. I'm probably forgetting a few things as I'm thinking out loud ;).

@Karlos

Quote:

No idea, it's not really up to me.

Is it possible to ask and have a statement ? Maybe matthey or thellier would like to do some things (fix problems mainly) for the 68k versions. This should finally help the AOS4 version and do a link for Gallium3D.

And As Matthey said, maybe a driver for radeon 68k also.

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

Hello
>I don't think it would be much of a problem to add support for Warp3D V5 to the 68k Warp3D.library.

Wazp3D contains the code for the 8 new v5 functions it only need a V5 Warp3D.h include file (ie one from OS4) to rebuild it for 68k
(Wazp3D for Os4 PPC is v5 compatible)
Also it will need to update Wazp3D_functions_glue.h to add the 8 new v5 functions
ASM(ULONG) LibW3D_SetTextureBlend(A0(W3D_Context * context),A1(struct TagItem * tagList)) {return W3D_SetTextureBlend(context,tagList); }
ASM(ULONG) LibW3D_SecondaryColorPointer(A0(A0(A0(W3D_Context * context),A1(void * pointer),D0(int stride),D1(ULONG format),D2(ULONG mode),D3(ULONG flags)) {return W3D_SecondaryColorPointer(context,pointer,stride,format,mode,flags); }
ASM(ULONG) LibW3D_FogCoordPointer(A0(W3D_Context * context),A1(void * pointer),D0(int stride),D1(ULONG mode),D2(ULONG flags)) {return W3D_FogCoordPointer(context,pointer,stride,mode,flags); }
ASM(ULONG) LibW3D_InterleavedArray(A0(W3D_Context * context),A1(void * pointer),D0(int stride),D1(ULONG format),D2(ULONG flags)) {return W3D_InterleavedArray(context,pointer,stride,format,flags); }
ASM(ULONG) LibW3D_ClearBuffers(A0(W3D_Context * context),A1(W3D_Color * color),A2(W3D_Double * depth),A3(ULONG * stencil)) {return W3D_ClearBuffers(context,color,depth,stencil); }
ASM(ULONG) LibW3D_SetParameter(A0(W3D_Context * context),D0(ULONG target),A1(void * pattern)) {return W3D_SetParameter(context,target,pattern); }
ASM(ULONG) LibW3D_PinTexture(A0(W3D_Context * context),A1(W3D_Texture * texture),D0(BOOL pinning)) {return W3D_PinTexture(context,texture,pinning); }
ASM(ULONG) LibW3D_SetDrawRegionTexture(A0(W3D_Context * context),A1(W3D_Texture * texture),A2(W3D_Scissor * scissor)) {return W3D_SetDrawRegionTexture(context,texture,scissor); }

Of course old-drivers will not do multi-texturing. But multi-texturing dont seems to be very used....

Anyway as there are no existing 68k programs that use Warp3D v5 :-/
But it can allow to retro-port latest MiniGL to Os3/68k

Alain Thellier

@thellier, mrodfr, matthey

ah common, guys, the horse has been beaten to the death long time ago. what for all that fuss, w3d5, minigl, its all dead end, and as there is neither any reliable statement or support, i hope you all remember how much time and effort it took us (mostly you) and where it led us.

@thellier
I see you assigned the 68k registers to the parameters for the new V5 functions. I'll use the same if I get around to updating to V5. Most of the new functions do most of their work in the driver library instead of the Warp3D.library itself. I'm currently working on another project but may play with it later. Thanks.

Quote:

wawa wrote: @thellier, mrodfr, matthey ah common, guys, the horse has been beaten to the death long time ago. what for all that fuss, w3d5, minigl, its all dead end, and as there is neither any reliable statement or support, i hope you all remember how much time and effort it took us (mostly you) and where it led us.

Warp3D may be dead end but it's not dead. It's still useful as a "thin" API that has most 3D needs available on all Amiga like operating systems. Programs written for CyberGFX and Warp3D should run on classic 68k, AmigaOS 4.x, MOS, AROS, and UAE with only minor changes. StormMesa and MiniGL work on top of this for most Amiga OS operating systems. Other solutions are not multi-Amiga platform, not finished, not well documented, and/or more buggy. Maybe when AROS replaces every Amiga OS will Warp3D become useful for only old programs.

@Mrodfr

Quote:

Do you think It's possible to add other developper, for warp3D development or just fix ?

I really doubt that. A couple of years ago, while I still was an OS4 betatester, I offered my help since W3D got next to no attention. Reported bugs wasn't fixed. New features promised since 2004 or something never emerged etc. But I was basically told by the Friedens that they didn't was to lose control of their project, and thus my offer was refused. It might just have been something personal though since Karlos was granted access to the sources...

@AmiDog

perhaps it is due to karlos only fixing the driver, except the policy is obviously to accept help but restrict improvements to os4 only so if oyu were proposing backporting it to 68k it might triggered mistrust.

@matt:
sure i know, while upgrading 68k w3d to v5 doesnt make much sense as alain said, no applications use that on 68k, a handfull on os4 and most likely there is nothing new going tom be compiled for w3d/68k. i personally im rather interested what happens on aros68k, chances are there will be some sort of current mesa some day, even if it could be too feature heavy to be a full port.

Last edited by wawa on 08-Sep-2011 at 10:55 AM.

@AmiDog
You aren't the only one to be brushed off by the AmigaOS 4.x team/Hyperion. Their attitude keeps people like me away. If they disenchant enough people and continue along their lonely path with a limited future, AROS PPC may end up replacing AmigaOS 4.x. AROS will likely gain support and developers as it adds support for classic 68k, fpga 68k, UAE and maybe ARM. That will give a standard API and future path for the majority of Amiga users. I could see AROS overtaking AmigaOS 4.x and MOS with PPC support because it's free, open source and would represent one standard and supported API at that point. If Hyperion was smart, they would partner with the fpga 68k and classic 68k guys to produce an AmigaOS 4.x for 68k as low end Amigas and PPC AmigaOS 4.x as high end Amigas. This would leverage their APIs like Reaction, P96, Warp3D. The low end 68k fpga Amigas aren't fast enough to be a threat to PPC and PPC isn't cheap enough to be a threat to fpga Amigas.

Quote:

wawa wrote: @matt: sure i know, while upgrading 68k w3d to v5 doesnt make much sense as alain said, no applications use that on 68k, a handful on os4 and most likely there is nothing new going tom be compiled for w3d/68k. i personally im rather interested what happens on aros68k, chances are there will be some sort of current mesa some day, even if it could be too feature heavy to be a full port.

Warp3D v5 68k has no support so no use and no use because of lack of support. It's the chicken and the egg problem of which came first? I don't see the new functions being used much besides W3D_ClearBuffers() which would be very handy. The main support would be in the drivers which shouldn't be too difficult. It would be nice to have Warp3D 68k V5 for cross platform support even if it was just Warp3D->Gallium. AROS has it's own implementation of Mesa 7.x which I believe Alain is trying to do Wazp3D->Mesa7.x. I would have thought Warp3D->Gallium would have made more sense but I haven't looked into it. Mesa 7.x and Gallium will likely be AROS only. Even though AmigaOS 4.x should get Gallium also, it may not be compatible because of implementation details and lack of cooperation. Warp3D should be fairly compatible on all Amigas despite it's limitations.

@matthey
Hello
In fact current Wazp3D for ppc got the v5 functions so latest minigl can works with it
I should have compiled the v5 functions in the 68k version too but i was too lazy to update all the Warp3D 68k "include" files (inline,fd,etc...) to make a clean & usable release ( I mean a 68k Warp3D v5 without updated "include" is useless for coders)
In fact it is not difficult but just boring :-/

>I believe Alain is trying to do Wazp3D->Mesa7.x.
It is already done in Aros version
I mean Wazp3Dv50 can use hardware Mesa on Aros (It will appear on latests Aros build ) It got small dsiplay problems (due to the fact that Mesa cant render in a bitmap) the "proof of concept" is here that an Amiga-like that got Mesa can have Warp3D too

As i said there are no 68k softwares that use the new v5 functions
But there is the latest MiniGL for OS4 that need the v5 functions
So having v5 support on AmigaOS 3 may allow to retro-port this up to date MiniGL
So allowing to retro port almost any Os4 game to Os3

>I don't see the new functions being used much
In fact latest MiniGL use a lot W3D_SetTextureBlendTags() this is the function for Texture/Color shader (yes Warp3d v5 got this kind of shader)
But mostly MiniGL use it only to set "classic" TexEnv functions (w3d_modulate,etc...) that exists also in Warp3D v4 (or Wazp3D)

Alain

@matthey:
chicken and egg, you say it. i just dont see anyone else except me trying to compile any even simple opengl application for 68k for the last two years. add to that what a noob i am. so i think there is really no demand.
@thellier:
even if v5 functions would be supported on 68k in hardware, which they arent, since it is wazp you have implemented them in, there is still minigl v2 to be ported to 68k before anyone can realicticly use it for something useful.
remember none of us has time *and* skills *and* motivation to do all that. and remember i have made some simple tests that have proven 68k minigl to be only marginally faster (if at all) than even our (non asm optimized) storm mesa compile.
in many cases it was just no problem to comment out unsupported gl functions from the source to get an application running. of course it can cause sh***y looks, bit hi quality gfx might be as well too much for an real 68k from the start.

so i stand back and see how aros is getting at it, anything else being waste of time under current circumstances, in my opinion.