Great work, Hans.

Really interesting.

I would like to learn graphics driver development.

_________________
retired

Great work Hans!

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

It's nice to see the different stages of the development chronicled.

Nice

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

cool :)

_________________
nox's in the house!

Great work Hans!

Thanks for all you effort

Some excellent progress. Good work.

The graphics cards that are in use are real beasts of cards and can crunch through data much faster than AmigaOSand the drivers currently allow.

How much room for improvement do you foresee? Is the aged Warp3D an insurmountable bottleneck?

Thanks!

@Hans,
Interesting thanks.
To my knowledge Amiga devices drives development is not well documented, what information is needed to development such software? is there any relevant information out there or do you need internal information taken from the OS to write such things?

Kamelito

@Xmas87

Quote:

How much room for improvement do you foresee? Is the aged Warp3D an insurmountable bottleneck?

Warp3D is a rasterizer only solutuion, i.e it converts vectors into pixels and does none of the actual 3D calculations.

Even the R100 and R200 GPU based cards are seriously under-utilised by Warp3D, the addition of T&L support would greatly benefit users of these older cards as well as the Southern Islands cards. Lets hope that A-EON have serious plans to expand the API since they are no co-owners.

@Xmas87
Quote:

How much room for improvement do you foresee? Is the aged Warp3D an insurmountable bottleneck?

As Warp3D is right now, it's a major bottleneck. Probably the biggest bottleneck is that CPU does the Transformation, Clipping & Lighting (TCL) rather than the GPU. Apart from being slower, this also prevents us from storing the vertices in VRAM as Vertex Buffer Objects (VBOs). So, every single rendered polygon must be TCL'd by the CPU, and then sent across the PCI(e) bus to the GPU. Imagine the GPU yawning and twiddling its thumbs between operations while it waits for the CPU to send it the next batch of rendering operations to do...

So the short answer is: without updating the Warp3D API to be more modern, it will always be a major bottleneck. On the bright side, it works and is available today.

@kamelit0
Quote:

To my knowledge Amiga devices drives development is not well documented, what information is needed to development such software? is there any relevant information out there or do you need internal information taken from the OS to write such things?

It depends on what the driver is for. For example:
- For audio drivers check out the "ahidev" files here
- IIRC, the SDK has some info about USB drivers, and there's a useful doc on os4depot: here
- The latest SANA-II specification for network drivers is on the Amiga is here
- AFAIK disk controllers are reasonably documented in the SDK and the old AmigaDev CD. You should look at the SCSI.device here. The "New Style Device" NSD standard is here, the trackdisk64 details are here (not sure which one you're supposed to use)
- In fact, the SDK and this wiki are good sources for various device drivers: see here
- Graphics drivers is a different story. You'll need to ask for access to the necessary documentation and files. Having said that, the RadeonHD driver started as a test program (with another graphics card being the primary display). So, you can get started working on the hardware first, and then get access to the necessary docs to turn it into a real driver later

Finally, there are a few drivers which are open-source, and such source code is a great extra reference next to the documentation.

This ended up being longer than intended, but hopefully it'll be useful for anyone interested in writing a driver.

Hans

Last edited by Hans on 12-Aug-2015 at 02:15 AM.
Last edited by Hans on 12-Aug-2015 at 02:14 AM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

Thanks.
Can you please explain why is Amiga graphics drivers documentation and examples different, why not just put everything on the Wiki?

Kamelito

@kamelit0

maybe it's because it's closed source, payed by A-Eon?

_________________
nox's in the house!

Quote:

As Warp3D is right now, it's a major bottleneck. Probably the biggest bottleneck is that CPU does the Transformation, Clipping & Lighting (TCL) rather than the GPU. Apart from being slower, this also prevents us from storing the vertices in VRAM as Vertex Buffer Objects (VBOs). So, every single rendered polygon must be TCL'd by the CPU, and then sent across the PCI(e) bus to the GPU. Imagine the GPU yawning and twiddling its thumbs between operations while it waits for the CPU to send it the next batch of rendering operations to do...

There's hope for TCL's implementation on the current Warp 3D?

Would be difficult to implement these features?

_________________
retired

I'm not talking about the Drivers he wrote for A-EON but the CBM/Hypérion documentation and sample codes for developers who want to develop Amiga Graphics device drivers.
Kamelito

Last edited by kamelit0 on 12-Aug-2015 at 12:07 PM.

We need TLC

Last edited by tommysammy on 12-Aug-2015 at 02:48 PM.

_________________
Amiga600/Vampire2/PrismaMegaMix

@AmigaBlitter
Quote:

There's hope for TCL's implementation on the current Warp 3D? Would be difficult to implement these features?

Adding TCL could be done. MiniGL would probably need a major overhaul to use it though; it really is designed for software TCL and, at a bare minimum, the TCL code would have to be bypassed. How much work it is would depend on whether you want Warp3D to provide software TCL backup for drivers that don't support it, or if you want to leave it up to games/apps to detect and adapt to new/old drivers. Providing a software TCL backup in an updated Warp3D would be the equivalent of embedding MiniGL's TCL core into Warp3D.


@kamelit0
Quote:

Can you please explain why is Amiga graphics drivers documentation and examples different, why not just put everything on the Wiki?

It probably starts with the fact that Picasso96 (the RTG system used as base) was developed by a third-party, and not Commodore. Neither Picasso96 nor Cybergraphics had public driver development kits. Had Commodore developed it, then it would probably have been open from the start.

Why is the documentation still not open? You'll have to ask Hyperion.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

I'd do my best to update MiniGL if that happens. We could take a clue from how Mesa handled this. It can do the transformations using it's built in sw TnL (used with 3Dfx drivers, etc.), or the driver's one.

_________________
This is just like television, only you can see much further.

I realize that updating MiniGL or other drivers could take a lot of time. We don't have any news about the current work on OpenGL. Last time we've heard about it (if i recall well) is when a screenshot was provided showing OpenGL working in software mode. I think that more than two years passed since this last info. If the OpenGL port will coming soon, perhaps continue to on the minigl can be a waste of time.

Maybe you can join the OS4 OpenGL team?

:)

_________________
retired

I bet it's coming soon, just two more weeks! :D Mesa has been announced 5 years ago, and we haven't heard much about it since 2013, when that screenshot was published. MiniGL has the unbeatable advantage of being available today, and working. I consider waiting for vaporware a waste of time. This is the first time I heard of the OS4 OpenGL team.

_________________
This is just like television, only you can see much further.