{"id":113225,"date":"2024-01-29T12:50:31","date_gmt":"2024-01-29T10:50:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-gtk-dobavleny-novye-dvizhki-otrisovki-dlya-opengl-i-vulkan"},"modified":"2024-01-29T12:50:31","modified_gmt":"2024-01-29T10:50:32","slug":"v-gtk-dobavleny-novye-dvizhki-otrisovki-dlya-opengl-i-vulkan","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/v-gtk-dobavleny-novye-dvizhki-otrisovki-dlya-opengl-i-vulkan","title":{"rendered":"In GTK sono stati aggiunti nuovi motori di rendering per OpenGL e Vulkan","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Gli sviluppatori della libreria GTK hanno annunciato la disponibilit\u00e0 di due nuovi motori di rendering \u2014 \u201cngl\u201d e \u201cvulkan\u201d, che utilizzano le API grafiche OpenGL (GL 3.3+ e GLES 3.0+) e Vulkan. I nuovi motori sono inclusi nella versione sperimentale GTK 4.13.6. Nella branca sperimentale di GTK, il motore ngl \u00e8 ora utilizzato di default, ma in caso di rilevamento di problemi significativi, nella prossima versione stabile 4.14 verr\u00e0 ripristinato il vecchio motore di rendering \u201cgl\u201d. <\/p>\n
I nuovi motori sono posizionati come unificati e costruiti da una singola base di codice. L'essenza dell'unificazione \u00e8 che viene utilizzata come base l'API Vulkan, sopra la quale \u00e8 stato creato un livello di astrazione separato per OpenGL che considera le differenze tra OpenGL e Vulkan. Questo approccio ha permesso di utilizzare in entrambi i motori un'infrastruttura comune per la gestione del grafo della scena, delle trasformazioni, della memorizzazione nella cache di texture e glifi. L'unificazione ha anche notevolmente semplificato la manutenzione della base di codice di entrambi i motori e il loro mantenimento in uno stato aggiornato e sincronizzato. <\/p>\n
A differenza del vecchio motore \u201cgl\u201d, in cui per ogni tipo di nodo di rendering (rendernode) veniva utilizzato uno shader semplice separato e si effettuava una periodica riordinazione dei dati durante il rendering off-screen, nei nuovi motori viene utilizzato uno shader complesso (ubershader), che interpreta i dati dal buffer invece del rendering off-screen. Nella sua attuale implementazione, la nuova versione \u00e8 ancora inferiore alla vecchia in termini di ottimizzazione, poich\u00e9 l'attenzione principale in questa fase \u00e8 rivolta alla correttezza del funzionamento e alla facilit\u00e0 di manutenzione. <\/p>\n
Nuove funzionalit\u00e0 non presenti nel vecchio motore \u201cgl\u201d: <\/p>\n
\n
Antialiasing \u2014 consente di mantenere piccoli dettagli e ottenere contorni pi\u00f9 uniformi.
<\/center>\n
Generazione di gradienti arbitrari, in cui \u00e8 possibile utilizzare qualsiasi numero di colori e antialiasing (nel motore \u201cgl\u201d erano supportati solo gradienti lineari, radiali e conici con 6 colori di stop).
<\/center>\n
Scalatura frazionaria (fractional scale), che consente di impostare valori di scala non interi, ad esempio, utilizzando una scala del 125% per una finestra 1200\u00d7800 verr\u00e0 allocato un buffer 1500\u00d71000, e non 2400\u00d71600 come nel vecchio motore.\n
Supporto della tecnologia DMA-BUF per l'utilizzo di pi\u00f9 GPU e lo spostamento di operazioni specifiche su un'altra GPU.\n
Molti nodi di rendering, con i quali c'erano problemi nella vecchia implementazione, vengono ora gestiti correttamente. <\/ul>\n
Tra i limiti dei nuovi motori si segnala l'assenza di supporto per il posizionamento di valori frazionari (fractional position) e nodi glshader, che erano molto legati alle peculiarit\u00e0 del vecchio motore, e che non sono pi\u00f9 necessari dopo l'aggiunta del supporto per nodi con maschere (mask) e texture con trasparenza. Si menziona anche la possibilit\u00e0 di problemi con i driver grafici, dovuti al cambiamento del metodo di interazione con i driver. <\/p>\n
In futuro, sulla base del nuovo modello unificato, non si esclude la creazione di motori di rendering che utilizzano Metal su macOS e DirectX su Windows, ma la creazione di tali motori \u00e8 complicata dall'uso di altri linguaggi per gli shader (nei motori \u201cngl\u201d e \u201cvulkan\u201d \u00e8 utilizzato il linguaggio GLSL, quindi per Metal e Direct si dovranno o duplicare gli shader o utilizzare un layer basato su SPIRV-Cross). <\/p>\n
Tra i piani futuri ci sono il supporto HDR e strumenti per una corretta gestione del colore, il supporto per il rendering su GPU, la capacit\u00e0 di eseguire il rendering di glifi, il rendering al di fuori del thread principale e l'ottimizzazione delle prestazioni per dispositivi pi\u00f9 vecchi e a bassa potenza. Attualmente, le prestazioni del motore \u201cvulkan\u201d sono vicine a quelle del vecchio motore \u201cgl\u201d. Il motore \u201cngl\u201d \u00e8 meno performante rispetto al vecchio motore \u201cgl\u201d, ma le prestazioni attuali sono sufficienti per il rendering a 60 o 144 FPS. Si prevede che la situazione migliorer\u00e0 dopo ottimizzazioni. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"In](\"\/wp-content\/uploads\/2024\/01\/dc690b87095af7bca8d2826ebb3a9584.png\")
<\/center>\n![\"In](\"\/wp-content\/uploads\/2024\/01\/331c81cddc35e00e08db425a38d90dca.png\")
<\/center>\n