Warp3D SI : The fastest card

@Hans

the only one who can make better drivers and mini gl than you is AMD - ATI

@kas1e
As Chain|Q said, TinyGL doesn't support VBOs and even if it did, Quake3 has no VBO support. It has a new API, you have to add code to support it. (See tgl.h in the MoprhOS SDK.)
There is no GART support either, but it has been discussed as a possible future improvement for low VRAM situations, i.e. to reduce expensive texture swapping.

in any way a quad core atom 1.33 ghz with 1.66 turbo bost and intel hd ... do 1280x1024 68fps in ioquake 3 . If we think the drivers was made by intel and windows 8 drivers are more better than other architecture ... i can say for sure Hans did a good job

@Hans
Is there anything an imbecile like me could fix? :P

@tlosm

Quote:
I'm sure that there are others who could do a great job too. You don't have to be the absolute best in order to make a difference. When I started on the 2D Radeon HD driver, I'd never written a driver before... I simply believed that I could do it.

So, anyone who really wants to try improve MiniGL should give it a shot. The latest code is in the following branch (which really should be merged back into the trunk at some point):
http://www.hyperion-entertainment.biz ... iniGL/branches/updates-kc


@BSzili
Quote:
I'm sure you could. Finding small things in MiniGL to improve may be difficult, though. If you use a version of MiniGL with the debug symbols still in the binary (by compiling it yourself), then hieronymus might give you an idea of which functions it's spending the most time in. Hieronymus is a statistical profiler.**

What I think really needs to happen is to rework the internal pipeline to output large vertex arrays. MiniGL's clipping code currently cuts vertex arrays into fragments, and even sends new clipped triangles to Warp3D one at a time. This is particularly bad for modern GPUs, and the W3D_SI driver has to work around this.

I also think that the input and output vertex data should be put into separate arrays. Right now both the input vertex data and the transformed output that gets sent to Warp3D are in the same structure. It would be much easier to accumulate vertices into larger arrays if the output data was in its own array.

As you can imagine, this would be a lot of work (necessary only because we don't have hardware TCL). This is why I'm not sure it's worth the effort, despite how long kas1e thinks Gallium will take.

It would be interesting to hear from those who have used Warp3D directly (e.g., crisot, Daytona675x). They might have other bright ideas. Perhaps there's a faster clipping algorithm that could be retrofitted without too much effort.

Hans



** Yes, MiniGL has its own profiling code, but Hieronymus + debug symbols should give you more detail.

@Hans
"Hieronymus is a statistical profiler"
Yes but, Hieronymus doesn't support Pegasos 2.

IIRC, Bszili OS4 system is a Pegasos2... Corto, if you are around... :)

@kas1e

Quote:

Matt told me that he wants to further develop Warp3D and add more features. I'd rather see it become an alternative to Gallium (when it finally arrives) since Warp3D will probably be faster.

@Rob

Quote:
Can you elaborate?

Why would one take on the huge effort of porting a complete 3D driver/framework/subsystem(?) if it's going to be slower than the alternative already usable (despite the limitations and obvious drawbacks)?

I thought once Gallium will be ready all the bits and pieces in AmigaOS4 (gxf subsystem etc.) will get optimised for the use with it?

I also thought Warp3D will be "obsolete" (still usable probably) by then (at least in AmigaOS4)?

@Raziel
Quote:

No one know how fast gallium will be on os4 of course (when and if it done), but seeing speed of it on AROS, i can see : it is not very fast. From another side, as it will be with all that TCL and stuff, probably can be not _that_ slow than warp3d. But that to be seen if ever. Implementation and integration can be done with way which gain more speed, or in other way, loose speed. TCL, Gart, VBO and whatever can be in Gallium, but by any of reasons can be disabled in os4 port "for better times" or "because blabla not support trata" whatever else. In other words:

Better to not hold our hopes for it. If it will be done : good. If it will fast enough: good. But currently all we have its minigl and warp3d, and after years of waiting of gallium, all we can do, its to make warp3d/minigl better.

Quote:

If gallium will see light in 2020 (i doubt), then "optimized for use" will happen in 2025 :))

Quote:

Yes. In 2050 :))

What i trying to say, that all that gallium mantra need to be stop, and only worry when it will see light. If it not here already, that mean something going wrong.

We have warp3d and minigl, so, let's think about what we have and what we can improve. All that gallium ideas just stop all the devs to working on minigl and made even small progress.

@Rob

dont belive too much in gallium and better performances.
for sure thanks to it we will have on amigaos shaders and newer gl but ... performances are not the best in PPC architecture this because the catalyst are not ported to gallium ppc like is for the x86.
I had been tested it on Debian on my quad g5 and man ... compared to ati drivers on osx are about 60% more slower on the same card.

@Hans
Hieronymus can't be used on Pegasos II's I happened to be equipped with. Corto reported the bug, but no one fixed it yet :\
Since there is already a workaround for it in the driver, would making MiniGL output large vertex arrays bring a noticeale speed increase? If yes, then it's definitely worth the effort in my opinion. Kas1e is not eeyore, Gallium3D/Mesa was annouced eons ago, and do you think A-Eon would have commissioned you to do Warp3D drivers if it was "right around the corner"? Yes, MiniGL is slow, but it's the only OpenGL implementation currently available on OS4.

“Realize deeply that the present moment is all you have. Make the NOW the primary focus of your life.”
― Eckhart Tolle, The Power of Now: A Guide to Spiritual Enlightenment

(just something im reading at the moment)

@BSzili
Quote:

Hans point out on my skepticism about gallium, not in another way :) I mean i also think that better to work on minigl/warp3d, and not waiting for gallium.

@BSzili

Quote:
No guarantees, but I do expect a noticeable improvement. I just ran a quick experiment where I disabled MiniGL's clipping code.** The screen looked a mess, but OpenArena's fps did increase by ~10 fps when I tried it. It was only a rough test and I didn't have a timedemo handy to do a more scientific comparison, but I'm fairly confident that there was an increase. Disabling the clipping code stopped it from cutting up vertex arrays and emitting individual triangles at the edges.

There are probably other performance improvements that could be done, but rendering as much per render call as possible is one of the fundamentals. Plus, I do wonder if sending Warp3D a tightly packed vertex array would allow better cache usage than the current scheme with fat vertex structures (containing both the input and output data).


Quote:
Do you honestly think that I didn't take the above into account? If somebody wants to give it a shot, then great. Just realise that we're talking about a major overhaul that would take a while, and not some small tweaks here and there.

Hans


** In hclip.c hc_CodePoint() I disabled the "outcode" setting code at the top

@Hans
Since I'm often the receiving end of all the trash talk complaints due to the less than stellar performance of MiniGL, I'm more than motivated to improve it. I just don't really have the skills to tell which part could be improved and how, but your findings about the clipping code is something to start on.

@BSzili

You can also analyze MiniGL behaviour with Wazp3D as it can output (debug) all the Warp3D calls & parameters

Typically you can full-debug a single display frame (from says Quake) to a file then begin to analyze it

Some stuffs that may need improvements :
(dont have checked the sources myself yet....)

- Lighting optim
- Clipping optim
- Vertices format (size of the struct used) = bandwiths problems occurs when drawing 250 000 triangles secondes if vertices format is too big
- bufferize triangles from several drawing operations (including new triangles created with the clipper)
- "State tracker" = dont set again a Warp3D states when not truly modified since last drawing
Often things like that happen in 3D progs

setstate x to default
setstate x to value y
draw n tris
setstate x to default
setstate x to value y
draw m tris

But it should be like that

setstate x to value y
draw (n+m) tris

Alain Thellier - Wazp3D

Great to see developers falling in behind Hans and working to tweak our graphics drivers. This type of collaborative thread is what makes the Amiga community a pleasant place to be.

Please do call on us users if you want things beta tested and stress tested.

@thellier
While saying "optimize this" and "optimize that" is easy, how should I go about doing it? Any ideas are welcome, but unless you have something concrete I can't be any help I'm afraid.

@thellier

you seem to know alot about these things. Maybe you can help improve minigl? I'm guessing a bounty could be made to motivate aswell.

@Antique

Or a bounty to whoever wants to do it?