AmigaOS4.1: Rilasciate le nuove WARP 3D

[cip060]

Finalmente SONO ARRIVATE le WARP 3D!!!

A-EON Technology Ltd is pleased to announce that a native 3D Shader-based API has been developed for OS4. Warp3D Nova has been the result of over nine months of hard work by graphics guru and AmigaDeveloper.com Team member, Hans De Ruiter. It offers significant opportunities for exciting advancements in 3D software running on the AmigaOS4 platform.



Why is Nova needed?

The original Warp3D API is over a decade old, and as a consequence, is not based around Shader technology and many related functions that modern graphics cards support. Modern 3D engines require Shaders and having this support on OS4 will remove more obstacles to porting games and applications from other platforms. To further ease porting from other systems, we have contracted Daniel Muessener (GoldenCode.eu) to develop an OpenGL ES 2.0 wrapper for the new Warp3D Nova.

In addition to the coding talents of Daniel, we have been in contact with other prominent 3D developers from across the Amiga community and provided them with early access to the software.


Warp3D Nova Features:

● A modern shader-based 3D graphics API for use by 3D software running on the AmigaOS 4 platform
● Supports vertex and fragment (pixel) shaders giving developers great freedom over lighting models, effects, vertex transformations, etc.
● Hardware accelerated Transformation, Clipping & Lighting (TCL) is implicitly supported (programmed via shaders)
● Uses the SPIR-V standard for shaders. A GLSL to SPIR-V compiler is included
● All rendering is done via Vertex Buffer Objects (VBOs) which can be stored in VRAM for high performance Render state stored in Render State Objects (RSOs). Having no global state avoids state thrashing, and allows multi-threaded rendering. Note: While there's no global state, a default RSO is allocated for convenience
● Includes an SDK with everything needed to start writing apps & games including examples ranging from querying hardware capabilities through to per-pixel lighting with normal mapping
● Can co-exist with the original Warp3D-SI & MiniGL

Fonte:

http://amigaworld.net/modules/news/article.php?storyid=7687

[Kyle]

Bella notizia
In termini di programmi e giochi cosa comporterà l'avvento di queste nuove Warp3D?

[scusscus]

Bravo Hans e congratulazioni a tutto il team!

Ora si potranno usare anche su Amiga gli shader...

Nuova versione del ambiente QT???
(vedi es: viewtopic.php?f=45&t=18531)

[luciodra]

Ehm...non mi ē molto chiaro se si tratterà di un update gratuito per chi ha già acquistato le "vecchie"

[andres]

Non ho capito se queste sostituiscono in via definitiva il porting di Gallium (che sarebbe abbandonato?) o meno.

[Seiya]

sembra solo l'aggiunta degli shader che prima non c'era anche per il fatto che potete usarle con il vecchio warp3d e miniGL.

[tlosm]

sembra solo l'aggiunta degli shader che prima non c'era anche per il fatto che potete usarle con il vecchio warp3d e miniGL.

Sono le OpenGLES 2.0 attualmente
e non sono compatibili con le vecchie warp3d .
per usare le warp3d biosogna avere sempre la warp3d.library installata sulla macchina.

[ilbarbax]

Direi che questa è una soluzione di ripiego constatato il fatto che hiperion non è in grado di sviluppare gallium in tempi ragionevoli
E purtroppo aggiungo che l.impressione sia che maco hanno iniziato visto che per aros ci hanno messo 8 mesi mentre hiperion sono anni che ne parla. Quindi è solo una questione di volontà

[Raffaele]

Bella notizia
In termini di programmi e giochi cosa comporterà l'avvento di queste nuove Warp3D?

Che si faranno giochi con gli shader, ma scordati i porting, a meno che non vengano fatti da programmatori coi cosiddetti che si mettano a tradurre riga per riga il codice engine 3D degli altri sistemi operativi per Warp3D Nova.

Non ho capito se queste sostituiscono in via definitiva il porting di Gallium (che sarebbe abbandonato?) o meno.

Bella domanda...

In ogni caso adesso che esiste Warp 3D Nova, si possono fare traduzioni da codice Gallium o, se qualcuno ci si mette d'impegno si può creare un wrapper che funzioni tramite libreria che si occupi al volo da e per la traduzione di codice che contiene chiamate a Gallium.

Intendiamoci... Non sarebbe mai il "vero" Gallium ma un sottoinsieme... Come le TinyGL e MiniGL sono un sottoinsieme di OpenGL...

Insomma andiamo avanti di sottoinsiemi, diventando se non più isolati, comunque sottosviluppati... I fratelli poveri dell'informatica mainstream.

sembra solo l'aggiunta degli shader che prima non c'era anche per il fatto che potete usarle con il vecchio warp3d e miniGL.

Sono le OpenGLES 2.0 attualmente
e non sono compatibili con le vecchie warp3d .
per usare le warp3d biosogna avere sempre la warp3d.library installata sulla macchina.

Dove ES in OpenGL ES sta per Embedded Systems, cioè i dispositivi minori integrati...
E non si puó fare altrimenti visto che le versioni principali hanno un codice talmente enorme che i pochi programmatori che abbiamo non ce la fanno a portarlo su Amiga data la mole di lavoro che sarebbe necessaria...

Direi che questa è una soluzione di ripiego constatato il fatto che hiperion non è in grado di sviluppare gallium in tempi ragionevoli
E purtroppo aggiungo che l.impressione sia che maco hanno iniziato visto che per aros ci hanno messo 8 mesi mentre hiperion sono anni che ne parla. Quindi è solo una questione di volontà

Diciamo che ogni ditta Amiga manda avanti i propri progetti di migliorie al sistema operativo per portare acqua solo al suo mulino, e fa in modo da rendere queste migliorie proprietarie per battere la concorrenza...

Ad esempio AmigaOS ha miniGL e MorphOS usa TinyGL... AmigaOS ha ReactOS e MorphOS ha MUI... Questo per dirne una o due...

Siccome abbiamo pochi programmatori e i sistemi Amiga sono in concorrenza fra loro cercando di sopraffarsi e conquistare utenti a scapito dell'altro, partono progetti mastodontici come il porting di Gallium e strada facendo ci si accorge che mancano mezzi e risorse (e le risorse umane in campo Amiga, cioè i programmatori buoni "coi cosiddetti" capaci di tali porting sono assai scarsi...)...

Si parte baldanzosamente, dunque e strada facendo si capisce che non si arriva da nessuna parte e ci si risolve a mettere le pezze...

Progetti che implichino il porting COMPLETO di Framework e Engine di grandi dimensioni, come OpenGL e Gallium3D in ambito Amiga li vedremo solo e solamente se le due opposte fazioni AmigaOS e MorphOS si mettessero d'accordo (campa cavallo) e ottenuto il comune accordo, in vista del raggiungimento dell'obbiettivo comune di portare queste risorse indispensabili in ambito Amiga, creassero un progetto di porting congiunto (ma soprattutto a codice aperto) su siti come Sourceforge dove chiunque può contribuire a programmare, mettendo a disposizione i propri migliori programmatori a tempo perso...
E così, con un po' di codice fatto da uno, un po' di codice fatto da un altro, e un po' di codice da programmatori indipendenti, mese dopo mese, feature dopo feature e dopo tante correzioni e patch incrociate fra più sviluppatori, in un anno o due avremmo OpenGL e Gallium3D belli che pronti...

Ma se ognuno degli schieramenti vuol cintinuare tenersi sempre il codice chiuso e proprietario, finendo poi col realizzare poco o nulla, resteremo sempre a fronteggiarci, AmigaOS e MorphOS, in questa assurda guerra dei poveri...

[tlosm]

Raffaele,
avere Gallium non e' una impresa facile sopratutto quando a differenza della controparte x86 il codice e' tutto c e zero asm, forse anche grazie questa piccola soluzione quei pochi porting possibili saranno almeno piu' ottimizzati rispetto a linux ppc dove gallium e mesa sono una bella zavorra ... pensa che muovere solo una finestra fa schizzare l'uso della cpu e la ventola della gpu comincia a ruotare a palla con glxgears. ti parlo per esperienza su linux ppc sia da quad g5 che su x5000 sia su radeon che nvidia ...
per intenderci prestazioni di gallium 30% rispetto a osx .

[Alblino]

Manco da un bel pezzo su questo lido, vedo che è tutto bello fermo da un pezzo tranne la rivista di Seiya.
Alla fine Gallium si è rivelato un bisonte quasi impossibile da portare su Os4..

[Raffaele]

Raffaele,
avere Gallium non e' una impresa facile sopratutto quando a differenza della controparte x86 il codice e' tutto c e zero asm, forse anche grazie questa piccola soluzione quei pochi porting possibili saranno almeno piu' ottimizzati rispetto a linux ppc dove gallium e mesa sono una bella zavorra ... pensa che muovere solo una finestra fa schizzare l'uso della cpu e la ventola della gpu comincia a ruotare a palla con glxgears. ti parlo per esperienza su linux ppc sia da quad g5 che su x5000 sia su radeon che nvidia ...
per intenderci prestazioni di gallium 30% rispetto a osx .

Anche su X5000 a 64 bit? Azz...

[marmotta]

Raffaele,
avere Gallium non e' una impresa facile sopratutto quando a differenza della controparte x86 il codice e' tutto c e zero asm, forse anche grazie questa piccola soluzione quei pochi porting possibili saranno almeno piu' ottimizzati rispetto a linux ppc dove gallium e mesa sono una bella zavorra ... pensa che muovere solo una finestra fa schizzare l'uso della cpu e la ventola della gpu comincia a ruotare a palla con glxgears. ti parlo per esperienza su linux ppc sia da quad g5 che su x5000 sia su radeon che nvidia ...
per intenderci prestazioni di gallium 30% rispetto a osx .

Anche su X5000 a 64 bit? Azz...

Finché nessuno minaccia la Amd e la Nvidia i driver son quelli... in realta la situazione è anche peggiore in quanto i driver ufficiali di osx leopard sono buoni ma non ottimi come i piu recenti per x86

Se solo Amd (una a caso) facesse dei driver per AmigaOs............... AmigaOs farebbe un balzo in avanti come neanche 10 anni di lavoro di hyperion potrebbero fare

Aggiungo: la cosa fa particolarmente rabbia sapendo che Amiga è sempre stato un perfetto connubio tra hw e sw! I chip li facevano loro e loro scrivevano il software, non si poteva desiderare di meglio! Ora invece prendiamo chip grafici di cui ignoriamo completamente il funzionamento (perche amd ed nvidia si tengono i loro segreti...) e pretendiamo di scrivere dei driver che siano decenti! Gia facciamo miracoli! I driver open di linux x86 sono più o meno nella stessa barca... Solo chi produce i chip può creare dei driver adatti che li sfruttino al 100%! Gli altri possono solo sperare di fare un reverse engineering discreto per quanto meno farli andare (non li sfrutteranno mai al 100%) e questo se parliamo di Amiga com'era e come è adesso fa un po' tristezza...

[tlosm]

Raffaele,
avere Gallium non e' una impresa facile sopratutto quando a differenza della controparte x86 il codice e' tutto c e zero asm, forse anche grazie questa piccola soluzione quei pochi porting possibili saranno almeno piu' ottimizzati rispetto a linux ppc dove gallium e mesa sono una bella zavorra ... pensa che muovere solo una finestra fa schizzare l'uso della cpu e la ventola della gpu comincia a ruotare a palla con glxgears. ti parlo per esperienza su linux ppc sia da quad g5 che su x5000 sia su radeon che nvidia ...
per intenderci prestazioni di gallium 30% rispetto a osx .

Anche su X5000 a 64 bit? Azz...

Anche il G5 Quad è 64 bit...
I bit sono relativi se i drivers fanno schifo :-P ...

[tlosm]

Aggiungo.
Glxgears su Quad G5
Linux PPC Radeonhd 4650 1400/1450 fps
Linux PPC RadeonHD 6570 1550/1600 fps
OSx Leopard PPC 10.5 9950/10.000 fps su una vecchia 7800gtx 512mb

AmigaOne X5000
Linux PPC RadeonHD 6570 1980/2010 fps (il pcie 2.0 aiuta)