Portada
mis comunidades
otras secciones
#9:
#8 Otro troll Windowsero sin tener ni putisima idea de lo que habla. Se ha implementado Direct 3D 10 de forma NATIVA gracias a la capa intermedia de los drivers con Gallium / DRI , es decir, algunos libres de ATI y el libre de NVIDIA, nouveau .
http://en.wikipedia.org/wiki/Gallium3D
· 1 Doom 3 está nativo en Linux y el rendimiento era muy superior que en Windows. ¿ Razones ? Kernel en tiempo real y asignación de proridades .
·2 Doom3, Quake4, Nexuiz con Bloom y luces dinámicas por partículas en tiempo real, FlightGear2 ...
Differences from Mesa 3D
Gallium3D provides a unified API exposing standard hardware functions, such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL 3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility layer) will need only a single front-end, called a state tracker, targeting the Gallium3D API. By contrast, Mesa 3D requires a different back-end for each hardware platform and several other APIs need translation to OpenGL at the expense of added overhead.[4][5][6]
Under Gallium3D, Direct Rendering Manager (DRM) kernel drivers will manage the memory and Direct Rendering Interface (DRI) drivers (now moving to DRI2) will be more GPU processing oriented. This will resolve memory management problems whose solutions are considered infeasible under Mesa 3D.[7]
LLVM usage
In addition, using the modular structure of Gallium3D, there are works underway to leverage the LLVM compiler suite and create a module to optimize shader code on the fly.[8] TOMA OWNED
The library represents each shader program using an extensible binary intermediate representation called Tungsten Graphics Shader Infrastructure (TGSI). When Gallium targets LLVM, the TGSI code is converted to the LLVM instruction set.
http://en.wikipedia.org/wiki/Gallium3D
· 1 Doom 3 está nativo en Linux y el rendimiento era muy superior que en Windows. ¿ Razones ? Kernel en tiempo real y asignación de proridades .
·2 Doom3, Quake4, Nexuiz con Bloom y luces dinámicas por partículas en tiempo real, FlightGear2 ...
Differences from Mesa 3D
Gallium3D provides a unified API exposing standard hardware functions, such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL 3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility layer) will need only a single front-end, called a state tracker, targeting the Gallium3D API. By contrast, Mesa 3D requires a different back-end for each hardware platform and several other APIs need translation to OpenGL at the expense of added overhead.[4][5][6]
Under Gallium3D, Direct Rendering Manager (DRM) kernel drivers will manage the memory and Direct Rendering Interface (DRI) drivers (now moving to DRI2) will be more GPU processing oriented. This will resolve memory management problems whose solutions are considered infeasible under Mesa 3D.[7]
LLVM usage
In addition, using the modular structure of Gallium3D, there are works underway to leverage the LLVM compiler suite and create a module to optimize shader code on the fly.[8] TOMA OWNED
The library represents each shader program using an extensible binary intermediate representation called Tungsten Graphics Shader Infrastructure (TGSI). When Gallium targets LLVM, the TGSI code is converted to the LLVM instruction set.
#7:
Primero Menéame y ahora... esto.
Gracias, Ricardo, eres nuestro ídolo
Gracias, Ricardo, eres nuestro ídolo
#3:
Se me olvidaba, esto con Wine los juegos irían la hostia de rápido, imaginaros juegos Direct 3D nativos en Linux , en 64 bits ( Linux está muchisimo mas asentado con 64 bits que Windows ) . Y sobre el sonido ... para algo está OpenAL y SDL .
#15:
#9 no es un troll windowsero, es el meme de la verdad a la milanesa de Barrapunto http://www.google.com/custom?query=aunque+me+gusta+mucho+linux&domains=barrapunto.com&sitesearch=barrapunto.com&client=pub-1936842256917240&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23000099%3BGL%3A1%3BDIV%3A%23FF6600%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AFFFFFF%3BALC%3A000099%3BLC%3A000099%3BT%3A000000%3BGFNT%3A6699CC%3BGIMP%3A6699CC%3BLH%3A50%3BLW%3A259%3BL%3Ahttp%3A%2F%2Fimages.barrapunto.com%2Flogo-bp.gif%3BS%3Ahttp%3A%2F%2Fbarrapunto.com%3BFORID%3A1%3B&hl=es
#10:
#8 La Fuerza me dice que te van a coser a negativos
Tienes razón en parte. Yo la verdad, hace años que no toco un juego en el ordenador (salvo el Age II, lo siento, es mi vicio ). Si sale DirectX 12, pues se actualiza la versión de linux y arreando que es gerundio
Quizás no se desarrolle para linux, pero imaginate las posibilidades de portar un juego sabiendo que el rendimiento va a ser el mismo y con un coste
de tiempo minimo.
Piensa que este grupo de trabajo ( que son cuatro amigos) estan portando y follandose vivos a toda la gente que está en nómina de microsoft, que son muuuchos.
Como apunta #9, el rendimiento puede dejar en bragas cualquier equipo Windows
Tienes razón en parte. Yo la verdad, hace años que no toco un juego en el ordenador (salvo el Age II, lo siento, es mi vicio ). Si sale DirectX 12, pues se actualiza la versión de linux y arreando que es gerundio
Quizás no se desarrolle para linux, pero imaginate las posibilidades de portar un juego sabiendo que el rendimiento va a ser el mismo y con un coste
de tiempo minimo.
Piensa que este grupo de trabajo ( que son cuatro amigos) estan portando y follandose vivos a toda la gente que está en nómina de microsoft, que son muuuchos.
Como apunta #9, el rendimiento puede dejar en bragas cualquier equipo Windows
#50:
#27 voy a ver si soy capaz de aclarar alguna de estas siglas; no soy ningún experto del tema pero algún conocimiento tengo. Eso sí, la última vez que hice algo de esto en Windows fue con DirectX 8 y ahora al parecer van por la 11... Así que si me equivoco las aclaraciones/correcciones serán bienvenidas.
En primer lugar, aclarar que hay dos posibles formas de utilización de las tarjetas gráficas: una es aceleración 2D y otra es aceleración 3D. Para que os hagáis una idea, los escritorios tradicionales utilizan aceleración 2D, que básicamente es aprovechar la imagen que ya está en memoria, y como mucho aplicar alguna transformación. La aceleración 3D además de trabajar con imágenes (texturas) trabaja con vértices y permite adaptar el punto de vista (lo que viene a ser Compiz, que te renderiza un cubo y en cada cara le aplica una imagen distinta). Los FPS en plan Quake, Doom (es que hace mucho que dejé el mundillo de los juegos :), tb utilizan 3D, y se nota en que adaptan la vista
en función de la posición del moñigote. Recientemente las tarjetas también tienen soporte para vídeo y para shaders; los shaders es simplemente una API para aprovechar la capacidad de cálculo paralelo de estas tarjetas para realizar aplicaciones de "propósito general". La decodificación de vídeo pues no es más que una mezcla entre la aceleración 2D y la ecodificación de diferentes códecs de vídeo (utilizando shaders u otras técnicas). Resumiendo, , e si te da la sensación de profundidad seguramente estén utilizando 3D y si te da la sensación de imagen plana pues sea 2D.
Como bien comentas en lo más bajo están los drivers de la tarjeta; en windows los drivers los da el propietario y ya; así tienes los drivers de Nvidia, Ati o Intel (no sé si hay alguna más). Encima de los drivers tienes DirectDraw para gráficos 2D y Direct3D para gŕaficos 3D. También tienes DirectShow para temas de vídeo. Todo esto está empaquetado en DirectX.
En Linux, sin embargo tienes los drivers propietarios y los libres. Intel y Ati creo que proporcionan drivers libres (de todas formas no conozco mucho). Nvidia porporciona drivers propietarios, y además hay dos implementaciones libres: nv y nouveau. Parece que el futuro va por nouveau, pero de momento no tiene soporte para 3D. DRI es una APi que proporciona acceso a la capacidad del driver de dar soporte 3D; DRI2 no lo había oído hasta tu comentario (ya te digo que hace mucho que no trabajo con esto). Aquí me tiro un poco (¿un poco más?); la API para trabajar con 2D es DirectFB (el framebuffer que mencionas).
Encima de DRI tienes OpenGL, que no es más que otra API estándar para trabajar con gráficos 3D. OpenGL sería el equivalente a Direct3D (aunque ambién hay OpenGL para Windows). Permite trabajar con vértices y texturas. Nunca he trabajado con DRI, pero supongo que será algo a más bajo nivel. La verdad es que OpenGL es también bastante bajo nivel, así que te recomiendo que después de hacer un par de turoriales te pases a un Scene Graph como Ogre, OpenSceneGraph u OpenSG. La implementación de OpenGL es dependiente de la tarjeta. Es decir, cuando instalas los drivers propietarios de Nvidia verás que ten instala las librerías de OpenGL pertinenetes. Si tu driver no proporciona aceleración 3D (eso es, la API DRI) puedes seguir haciendo aplicaciones 3D; sin embargo alguien tiene que hacer esos cáclulos. Pues esa capacidad la da Mesa3D, que no es más que una implementación de OpenGL pero integramente en software. Como te imaginarás bastante lenta.
OpenAL es una APi para reproducir sonidos de forma sencilla. La verdad es que aquí no me voy a meter, porque si el tema de los gráficos es complicado en Linux, el tema del sonido es algo descomunal. Simplemente decir que sería el equivalente a DirectSound (también parte de DirectX) y que funciona sobre el driver en Windows o sobre alsa o pulseaudio en Linux, y puede que sobre Jack, OSS, ESD, y si me dejo alguno espero que me perdonen los entendidos :P). esumiendo OpenAL te deja abrir un canal de audio y empezar a mandar muestras.
SDL es una API que pretende facilitar la creación de juegos. Para ello proporciona acceso a la funcionalidad de gráficos 2D (no sé si 3D directamente)
y del audio (creo que a través de OpenAl, directamente a través de Alsa y otros drivers, pero no sé como está ahora el soporte para pulseaudio).
XServer/X.org es una arquitectura cliente servidor que permite renderizar gráficos en una pantalla. Los drivers propietarios de Nvidia requieren un servidor de estos, pero por lo demás no deja de ser un servidor que proporciona acceso a la tarjeta gráfica de forma remota (o local).
Por último falta Wine y Gallium3D. Wine es una implementación de la APi de windows wn Linux. ¿Qué quiere decir esto? Iimagina que tienes un programa que abre un fichero, y par ello llama a la función OpenFile. El problema es que en la API de Linux, la función que hace lo mismo, no se llama OpenFile, sino open_file. Cuando ejecutas tu programa de Windows en Linux, va a intentar ejecutar un función OpenFile, pero que no encuentra en ninguna librería, y por lo tanto fallará. Wine crea una librería con una función OpenFile, de forma que tu programa de Windows la encuentra y puede seguir ejecutandose. Gallium3D viene a ser lo mismo pero para temas de 3D; es decir, si tu programa espera llamar a una función IDirect3D9::CreateDevice(), pues Gallium proporciona una implementación que hará las llamadas correspondientes a DRi o al Driver.
De todas formas, como ya te he dicho, si el tema de los gráficos te parece complicado/lioso en Linux, no empieces con el audio, que eso si es para cagarse.
Espero que esta chapa le sirva a alguien, y las correcciones serán bienvenidas, que como ya digo, no soy ningún experto del tema (aunque me ha tocado pegarme mucho con estas cosas)
En primer lugar, aclarar que hay dos posibles formas de utilización de las tarjetas gráficas: una es aceleración 2D y otra es aceleración 3D. Para que os hagáis una idea, los escritorios tradicionales utilizan aceleración 2D, que básicamente es aprovechar la imagen que ya está en memoria, y como mucho aplicar alguna transformación. La aceleración 3D además de trabajar con imágenes (texturas) trabaja con vértices y permite adaptar el punto de vista (lo que viene a ser Compiz, que te renderiza un cubo y en cada cara le aplica una imagen distinta). Los FPS en plan Quake, Doom (es que hace mucho que dejé el mundillo de los juegos :), tb utilizan 3D, y se nota en que adaptan la vista
en función de la posición del moñigote. Recientemente las tarjetas también tienen soporte para vídeo y para shaders; los shaders es simplemente una API para aprovechar la capacidad de cálculo paralelo de estas tarjetas para realizar aplicaciones de "propósito general". La decodificación de vídeo pues no es más que una mezcla entre la aceleración 2D y la ecodificación de diferentes códecs de vídeo (utilizando shaders u otras técnicas). Resumiendo, , e si te da la sensación de profundidad seguramente estén utilizando 3D y si te da la sensación de imagen plana pues sea 2D.
Como bien comentas en lo más bajo están los drivers de la tarjeta; en windows los drivers los da el propietario y ya; así tienes los drivers de Nvidia, Ati o Intel (no sé si hay alguna más). Encima de los drivers tienes DirectDraw para gráficos 2D y Direct3D para gŕaficos 3D. También tienes DirectShow para temas de vídeo. Todo esto está empaquetado en DirectX.
En Linux, sin embargo tienes los drivers propietarios y los libres. Intel y Ati creo que proporcionan drivers libres (de todas formas no conozco mucho). Nvidia porporciona drivers propietarios, y además hay dos implementaciones libres: nv y nouveau. Parece que el futuro va por nouveau, pero de momento no tiene soporte para 3D. DRI es una APi que proporciona acceso a la capacidad del driver de dar soporte 3D; DRI2 no lo había oído hasta tu comentario (ya te digo que hace mucho que no trabajo con esto). Aquí me tiro un poco (¿un poco más?); la API para trabajar con 2D es DirectFB (el framebuffer que mencionas).
Encima de DRI tienes OpenGL, que no es más que otra API estándar para trabajar con gráficos 3D. OpenGL sería el equivalente a Direct3D (aunque ambién hay OpenGL para Windows). Permite trabajar con vértices y texturas. Nunca he trabajado con DRI, pero supongo que será algo a más bajo nivel. La verdad es que OpenGL es también bastante bajo nivel, así que te recomiendo que después de hacer un par de turoriales te pases a un Scene Graph como Ogre, OpenSceneGraph u OpenSG. La implementación de OpenGL es dependiente de la tarjeta. Es decir, cuando instalas los drivers propietarios de Nvidia verás que ten instala las librerías de OpenGL pertinenetes. Si tu driver no proporciona aceleración 3D (eso es, la API DRI) puedes seguir haciendo aplicaciones 3D; sin embargo alguien tiene que hacer esos cáclulos. Pues esa capacidad la da Mesa3D, que no es más que una implementación de OpenGL pero integramente en software. Como te imaginarás bastante lenta.
OpenAL es una APi para reproducir sonidos de forma sencilla. La verdad es que aquí no me voy a meter, porque si el tema de los gráficos es complicado en Linux, el tema del sonido es algo descomunal. Simplemente decir que sería el equivalente a DirectSound (también parte de DirectX) y que funciona sobre el driver en Windows o sobre alsa o pulseaudio en Linux, y puede que sobre Jack, OSS, ESD, y si me dejo alguno espero que me perdonen los entendidos :P). esumiendo OpenAL te deja abrir un canal de audio y empezar a mandar muestras.
SDL es una API que pretende facilitar la creación de juegos. Para ello proporciona acceso a la funcionalidad de gráficos 2D (no sé si 3D directamente)
y del audio (creo que a través de OpenAl, directamente a través de Alsa y otros drivers, pero no sé como está ahora el soporte para pulseaudio).
XServer/X.org es una arquitectura cliente servidor que permite renderizar gráficos en una pantalla. Los drivers propietarios de Nvidia requieren un servidor de estos, pero por lo demás no deja de ser un servidor que proporciona acceso a la tarjeta gráfica de forma remota (o local).
Por último falta Wine y Gallium3D. Wine es una implementación de la APi de windows wn Linux. ¿Qué quiere decir esto? Iimagina que tienes un programa que abre un fichero, y par ello llama a la función OpenFile. El problema es que en la API de Linux, la función que hace lo mismo, no se llama OpenFile, sino open_file. Cuando ejecutas tu programa de Windows en Linux, va a intentar ejecutar un función OpenFile, pero que no encuentra en ninguna librería, y por lo tanto fallará. Wine crea una librería con una función OpenFile, de forma que tu programa de Windows la encuentra y puede seguir ejecutandose. Gallium3D viene a ser lo mismo pero para temas de 3D; es decir, si tu programa espera llamar a una función IDirect3D9::CreateDevice(), pues Gallium proporciona una implementación que hará las llamadas correspondientes a DRi o al Driver.
De todas formas, como ya te he dicho, si el tema de los gráficos te parece complicado/lioso en Linux, no empieces con el audio, que eso si es para cagarse.
Espero que esta chapa le sirva a alguien, y las correcciones serán bienvenidas, que como ya digo, no soy ningún experto del tema (aunque me ha tocado pegarme mucho con estas cosas)
Comentarios
Primero Menéame y ahora... esto.
Gracias, Ricardo, eres nuestro ídolo
#16 Sobre todo con el comentario #7
.
Se me olvidaba, esto con Wine los juegos irían la hostia de rápido, imaginaros juegos Direct 3D nativos en Linux , en 64 bits ( Linux está muchisimo mas asentado con 64 bits que Windows ) . Y sobre el sonido ... para algo está OpenAL y SDL .
#3 y #4 Me estoy poniendo tonto...
#3 si compilas WINE con soporte de 64bits este solo ejecuta binarios de 64bits. La mayoria de apps para Windows se compilan para 32
#23 No me refería a eso, Ahora que Linux puede usar en un futuro D3D 10, podrían portar un juego de 32 bits para Windows , y crear una versión nativa de 64 bits para Linux . Se lo comería en rendimiento totalmente. Mayores espacios de memoria, optimizaciones en todas partes , uso de LLVM ...
#0 MOLA. Pero no solo en Linux, Gallium está portado creo, a BSD, AROS y muchos SSOO libres más . NVIDIA, como esto siga asi sustituiré nouveau por nvidia en xorg.conf en el futuro .
#2 Esta principalmente desarrollado por VMware... asi que ya sabeis lo que esto puede significar también en temas de virtualización.
#2 La API para trabajar en 2D puede ser o bien SDL->OpenGL , o SDL/XVideo . El framebuffer se deja para el modo consola con más resolucion que unas 80x25 líneas a 640x400 , y para ver vídeos en MPlayer en consola pura , y otros programas con salida framebuffer . Se define en grub, en el arranque , en las opciones del kernel , el tamaño en píxeles de esta asignando un código numérico a lav variable vga .
#52 También puedes utilizar el framebuffer como driver de X cuando tu tarjeta no está soportada.
Moooola
perdón por el negativo #1 mo me he dado cuenta te lo recompensare en otros post
#36 sudo aptitude install linux-image-rt
#36 Como ha puesto #42 Linux tiene la posibilidad de compilar un kernel para funcionar en tiempo real, en la web de los que lo mantienen te explican en algunos sitios donde se usa, cámaras flotantes que retransmiten la superbowl, lásers, equipos de sonido, hasta IBM ganó un concurso para los sistemas de control de un destructor de la marina estadounidense utilizándolo. Así que sí, Linux se puede compilar con soporte para tiempo real, o usar los paquetes de tu distribución preferida, lo que te sea más fácil.
Y además esta: http://www.osnews.com/story/23821/Qt_Being_Ported_to_Wayland
Ojalá nos podamos quitar pronto de en medio el X Server (al menos en sistemas de escritorio), y usar algo más eficiente.
#12 No hace falta quitarlo , ¿ te suenan las otras siglas del DRM ? http://en.wikipedia.org/wiki/Direct_Rendering_Manager .
Por cierto ojala avance este driver y tenga soporte para mi GeForce 8200, ese driver con Gallium en mi tarjeta apoyado con LLVM compilado en mi Core2DUO haría verdaderas burradas . Bienvenidos al mundo del software libre .
#8 Lo que te decía, yo no engaño a nadie http://www.phoronix.com/scan.php?page=news_item&px=ODA1OA OperArena LLVM - Gallium por software, sin uso de la trjeta gráfica = 25 fps . Imagina con aceleración .
Pues yo me alegro....si entendiese algo de lo que se dice....
Entiendo que es bueno para Linux y que permitira la ejecución nativa en Linux de juegos echos solo para Windows.
Sin embargo el tema de los gráficos en Linux no me queda nada claro. Por lo que entiendo en Windows están:
En el nivel más bajo estan los drivers propietarios del fabricante que soportan ciertas APIs. Windows implementa su API, DIrect3D y los juegos para Windows se implementan para utilizan esta API y ahí se acabó todo.
Lo de Linux si alguien es tan amable de explicar que leches es todo esto del framebuffer, DRI, DRI2, DRM, XServer/X.org, Catalyst, nv, nouveau, MESA3D, OpenGL, Gallium3D, Wine, OpenAL, SDL y su tía la gorda.
Supongo que para el que lo conozca será muy sencillo, pero para el resto de mortales es un poco críptico.
Gracias de antemano.
Por cierto adjunto una comparativa de Catalyst (driver propietario AMD/ATI), varias versiones de MESA3D y Gallium3D, que he encontrado en Phoronix investigando el tema:
http://www.phoronix.com/scan.php?page=article&item=ati_r300_current&num=2
Saludos
#27 voy a ver si soy capaz de aclarar alguna de estas siglas; no soy ningún experto del tema pero algún conocimiento tengo. Eso sí, la última vez que hice algo de esto en Windows fue con DirectX 8 y ahora al parecer van por la 11... Así que si me equivoco las aclaraciones/correcciones serán bienvenidas.
En primer lugar, aclarar que hay dos posibles formas de utilización de las tarjetas gráficas: una es aceleración 2D y otra es aceleración 3D. Para que os hagáis una idea, los escritorios tradicionales utilizan aceleración 2D, que básicamente es aprovechar la imagen que ya está en memoria, y como mucho aplicar alguna transformación. La aceleración 3D además de trabajar con imágenes (texturas) trabaja con vértices y permite adaptar el punto de vista (lo que viene a ser Compiz, que te renderiza un cubo y en cada cara le aplica una imagen distinta). Los FPS en plan Quake, Doom (es que hace mucho que dejé el mundillo de los juegos :), tb utilizan 3D, y se nota en que adaptan la vista
en función de la posición del moñigote. Recientemente las tarjetas también tienen soporte para vídeo y para shaders; los shaders es simplemente una API para aprovechar la capacidad de cálculo paralelo de estas tarjetas para realizar aplicaciones de "propósito general". La decodificación de vídeo pues no es más que una mezcla entre la aceleración 2D y la ecodificación de diferentes códecs de vídeo (utilizando shaders u otras técnicas). Resumiendo, , e si te da la sensación de profundidad seguramente estén utilizando 3D y si te da la sensación de imagen plana pues sea 2D.
Como bien comentas en lo más bajo están los drivers de la tarjeta; en windows los drivers los da el propietario y ya; así tienes los drivers de Nvidia, Ati o Intel (no sé si hay alguna más). Encima de los drivers tienes DirectDraw para gráficos 2D y Direct3D para gŕaficos 3D. También tienes DirectShow para temas de vídeo. Todo esto está empaquetado en DirectX.
En Linux, sin embargo tienes los drivers propietarios y los libres. Intel y Ati creo que proporcionan drivers libres (de todas formas no conozco mucho). Nvidia porporciona drivers propietarios, y además hay dos implementaciones libres: nv y nouveau. Parece que el futuro va por nouveau, pero de momento no tiene soporte para 3D. DRI es una APi que proporciona acceso a la capacidad del driver de dar soporte 3D; DRI2 no lo había oído hasta tu comentario (ya te digo que hace mucho que no trabajo con esto). Aquí me tiro un poco (¿un poco más?); la API para trabajar con 2D es DirectFB (el framebuffer que mencionas).
Encima de DRI tienes OpenGL, que no es más que otra API estándar para trabajar con gráficos 3D. OpenGL sería el equivalente a Direct3D (aunque ambién hay OpenGL para Windows). Permite trabajar con vértices y texturas. Nunca he trabajado con DRI, pero supongo que será algo a más bajo nivel. La verdad es que OpenGL es también bastante bajo nivel, así que te recomiendo que después de hacer un par de turoriales te pases a un Scene Graph como Ogre, OpenSceneGraph u OpenSG. La implementación de OpenGL es dependiente de la tarjeta. Es decir, cuando instalas los drivers propietarios de Nvidia verás que ten instala las librerías de OpenGL pertinenetes. Si tu driver no proporciona aceleración 3D (eso es, la API DRI) puedes seguir haciendo aplicaciones 3D; sin embargo alguien tiene que hacer esos cáclulos. Pues esa capacidad la da Mesa3D, que no es más que una implementación de OpenGL pero integramente en software. Como te imaginarás bastante lenta.
OpenAL es una APi para reproducir sonidos de forma sencilla. La verdad es que aquí no me voy a meter, porque si el tema de los gráficos es complicado en Linux, el tema del sonido es algo descomunal. Simplemente decir que sería el equivalente a DirectSound (también parte de DirectX) y que funciona sobre el driver en Windows o sobre alsa o pulseaudio en Linux, y puede que sobre Jack, OSS, ESD, y si me dejo alguno espero que me perdonen los entendidos :P). esumiendo OpenAL te deja abrir un canal de audio y empezar a mandar muestras.
SDL es una API que pretende facilitar la creación de juegos. Para ello proporciona acceso a la funcionalidad de gráficos 2D (no sé si 3D directamente)
y del audio (creo que a través de OpenAl, directamente a través de Alsa y otros drivers, pero no sé como está ahora el soporte para pulseaudio).
XServer/X.org es una arquitectura cliente servidor que permite renderizar gráficos en una pantalla. Los drivers propietarios de Nvidia requieren un servidor de estos, pero por lo demás no deja de ser un servidor que proporciona acceso a la tarjeta gráfica de forma remota (o local).
Por último falta Wine y Gallium3D. Wine es una implementación de la APi de windows wn Linux. ¿Qué quiere decir esto? Iimagina que tienes un programa que abre un fichero, y par ello llama a la función OpenFile. El problema es que en la API de Linux, la función que hace lo mismo, no se llama OpenFile, sino open_file. Cuando ejecutas tu programa de Windows en Linux, va a intentar ejecutar un función OpenFile, pero que no encuentra en ninguna librería, y por lo tanto fallará. Wine crea una librería con una función OpenFile, de forma que tu programa de Windows la encuentra y puede seguir ejecutandose. Gallium3D viene a ser lo mismo pero para temas de 3D; es decir, si tu programa espera llamar a una función IDirect3D9::CreateDevice(), pues Gallium proporciona una implementación que hará las llamadas correspondientes a DRi o al Driver.
De todas formas, como ya te he dicho, si el tema de los gráficos te parece complicado/lioso en Linux, no empieces con el audio, que eso si es para cagarse.
Espero que esta chapa le sirva a alguien, y las correcciones serán bienvenidas, que como ya digo, no soy ningún experto del tema (aunque me ha tocado pegarme mucho con estas cosas)
En vuestro navegador a parte del artículo (por cierto, bastante curioso), aparecen tíos borrachos? es que cómo no decís nada...?¿
Esta noticia se puede resumir en una palabra:BRUTAL
Y como se ven en las fotos, los tios han salido cagando leches a emborracharse, porque es algo épico.
Aún recuerdo esas horas interminables intentando correr el wow con el cedega antes de que saliera definitivamente.
Conozco bastante gente que usa el ordenador para poco más que internet y juegos, y siempre me han dicho lo mismo desde hace años, el día que se pueda jugar en ñu, adios win!!!
#34 claro aja claro... y los coches volaran...
#28 El uso de DX sería directo en los binarios Linux , y Wine no necesitaría traducir los juegos con DX a llamadas a librerías OpenGL de Linux , usaria directamente las Direct X de Linux que el driver libre con Gallium y demás tecnología entendería .
#29 Gracias por la info!
Pocket Oxford Spanish Dictionary © 2005 Oxford University Press:
library /'laɪbreri / ||/'laɪbrəri/ sustantivo (pl -ries) biblioteca f
#39 http://es.wikipedia.org/wiki/Biblioteca_%28inform%C3%A1tica%29#Nota_terminol.C3.B3gica
#39 Es verdad, fíjate que Cervantes y Góngora ya usaban el término biblioteca para referirse a un conjunto de funciones programadas agrupadas en un fichero.
¡No me jodas, hombre! En sotfware, el termino librería se utiliza porque ha derivado del palabro inglés "library". Yo cuando hablo de "librería" en software no pienso en una tienda de libros o en un lugar donde me puedo llevar libros prestados. Pienso en un archivo ".dll" o ".so". ¿Que está mal traducido en su origen? Pues es posible, o puede que no. Library en inglés es un lugar donde se prestan libros, pero es que en este contexto no hay libros. Así que lo puedes traducir como como biblioteca o no. El que inventó el palabro "library" seguramente vislumbro una analogía con una biblioteca; el que lo tradujo a castellano no se comió la cabeza, y pensó que un conjunto de funciones de softare agrupadas en un archivo que en inglés se llamaba "library" se podía traducir perfectamente como "librería". Si lo hubieses inventado tu lo hubieses podido llamar album, pero lo inventó un inglés (o yanki o por lo menos lo bautizó en inglés) y lo llamó library. El primero o los primeros que lo tradujeron hicieron lo bautizaron adaptando el término inglés, no pensando en su etimología, que es bastante arbitraria también.
Ya ves, el idioma es algo vivo que se adapta. Igual que nosotros exportamos términos como siesta (en lugar de nap) o fiesta (en lugar de party/holiday) los ingleses exportan términos como librería en vez de "bibliotec", directorio en vez de guía, chatear en vez de charlar, comando en vez de orden o driver en vez de controlador. Me preocuparía más de por qué exportamos términos de fiesta y descanso e importamos términos tecnológicos.
#53 No se trata de que «el lenguaje sea algo vivo que se adapta» ni que nosotros hayamos exportado palabras al inglés. Se trata de que «librería» es una mala traducción de «library», que es claramente «biblioteca» y no «librería», que es «bookshop» o «bookstore». Sobre la etimología, no hay libros pero hay texto: es una colección de funciones de referencia, igual que alguien en su casa puede tener una biblioteca de libros sobre un determinado tema. Igual que uno puede usar una biblioteca de biología para escribir un libro, uno puede usar una biblioteca de funciones gráficas para escribir un programa.
Obviamente, no todos los extranjerismos de nuestro idioma han respetado la etimología original, pero teniendo en cuenta que esta palabra aún es reciente y que cualquiera puede buscar el significado de «library» en un diccionario ¿por qué persistir en el error?
#58 Porque no es un error. Porque de la misma forma que banco en castellano
Porque "library" en inglés tiene un montón de aceptciones. Y si las primeras acepciones están relacionadas con una colección de libros, hay una acepción adicional que la define como "una colección de programas y subrutinas almacenadas y disponibles para su uso inmediato" según wordreference o "una colección de programas y paquetes de software generalemente diponibles, que se cargan y almacenan en disco para su uso inmediato" según el diccionario de Oxford. Las primeras acepciones de library, las que tienen que ver con libros, tienen su contrapartida en biblioteca. Pero la acepción relacionada con el mundo del software no la contempla el DRAE. Así que como no hay una palabra que defina ese concepto hay que crear uno. Tu lo puedes llamar biblioteca, porque el conjunto de funciones te recuerda a una conjunto de libros, yo lo puedo llamar album porque no deja de ser una colección de subrutinas y otra gente lo llama librería porque adapta el término usado en inglés. Lo que no puedes decir es que hay que traducirlo como biblioteca porque la primera acepción de libary se traduce como biblioteca. Porque igual que banco se traduce como bank cuando se trata de un lugar donde guardas dinero, como bench cuando se trata de un siento o como shoal cuando se trata de un conjunto de peces, library se traduce como biblioteca cuando el contexto es de libros, y se traduce como librería. Porque lo que se traducen son los conceptos, no los términos. ¿O tú eres de los que para invitar a entrar a tu casa dice "between, between"?
#59 otra gente lo llama librería porque adapta el término usado en inglés
No, los que decimos «biblioteca» lo adaptamos del inglés, los otros lo intentan, pero como apenas tienen idea de inglés hacen una chapuza.
Porque lo que se traducen son los conceptos, no los términos.
¿Qué quieres decir con traducir los conceptos? ¿Y qué tiene que ver eso con traducir «library» como «librería»? Aquí no se ha usado ningún concepto, sólo se ha hecho una pseudotraducción fonética, sin tener en cuenta el significado de lo que se traduce.
Lo que no puedes decir es que hay que traducirlo como biblioteca porque la primera acepción de libary se traduce como biblioteca. Porque igual que banco se traduce como bank cuando se trata de un lugar donde guardas dinero, como bench cuando se trata de un siento o como shoal cuando se trata de un conjunto de peces, library se traduce como biblioteca cuando el contexto es de libros, y se traduce como librería.
Esta explicación no tiene ni pies ni cabeza. «Bank» se traduce como «banco» porque las dos palabras provienen del francés «banque» y tienen el mismo significado, entidad financiera. No es una palabra de origen inglés. En francés primero designó al sitio para sentarse (una especie de banca) y luego a las entidades financieras, ya que los primeros banqueros cerraban los tratos sobre una banca usada a modo de mesa en las ferias de los pueblos.
Y de hecho, el origen de la acepción informática proviene de los libros, como ponen en la Wikipedia inglesa:
A library is a collection of sources, resources, and services, and the structure in which it is housed; it is organized for use and maintained by a public body, an institution, or a private individual. In the more traditional sense, a library is a collection of books. It can mean the collection, the building or room that houses such a collection, or both. The term "library" has itself acquired a secondary meaning: "a collection of useful material for common use." This sense is used in fields such as computer science, mathematics, statistics, electronics and biology.
http://en.wikipedia.org/wiki/Library
#63 El problema aquí es que ha surgido un concepto nuevo: "archivo informático que contiene un conjunto de funciones disponibles para ser utilizadas por otros programas". Ni en castellano ni en inglés hay un término que defina esto, así que hay que inventarse uno nuevo.
En inglés vieron una similitud con el prestamo de libros, y entonces lo bautizaron como "library". De esta forma, "library" pasa a tener dos acepciones. La primera acepción se traduce en castellano como biblioteca, la segunda sigue sin tener traducción, y sigue haciendo falta acuñar una nueva palabra. Una opción es seguir el mismo razonamiento que se ha seguido en inglés, por su similitud con el tema de los libros llamarlo "biblioteca"; otra opción es hacer un calco del inglés, y llamarle "librería".
Lo que no puedes es decir que la segunda acepción de "library" se tiene que traducir igual que la primera acepción. Igual que la primera acepción de banco se traduce como bench y la sexta como bank. O sino dime cuál de las seis acepciones de "biblioteca" según la RAE se refiere a un ""archivo informático que contiene un conjunto de funciones disponibles para ser utilizadas por otros programas". Porque yo solo veo relaciones a libros.
PD: "Y de hecho, el origen de la acepción informática proviene de los libros, como ponen en la Wikipedia inglesa: " La wikipedia solo dice que el término library a adquirido un segundo significado. No que provenga de los libros. Por si no te ha quedado claro, la clave esta en lo de segundo significado.
#65 Lo que no puedes es decir que la segunda acepción de "library" se tiene que traducir igual que la primera acepción.
¿Por qué no? Si en inglés se creó por analogía con una colección de textos, no veo por qué no se pueda hacer lo mismo en español.
La wikipedia solo dice que el término library a adquirido un segundo significado. No que provenga de los libros.
Está claro que proviene de los libros. Si no, ¿de dónde va a venir? ¿Escogieron una palabra al azar? Además, la Wikipedia engloba los dos significados al decir que es una colección de recursos y luego añade que originalmente eran sólo libros pero luego se ha extendido a la informática, la biología, etc.
#66 ¿Por qué no? Si en inglés se creó por analogía con una colección de textos, no veo por qué no se pueda hacer lo mismo en español.
Pues eso, si vamos a dar un significado nuevo a una palabra, se la podemos dar al término "biblioteca" por la semejanza con las bibliotecas de libros (neologismo por metáfora) como se lo podemos añadir al término "librería" por préstamo léxico del inglés.
Yo no te digo que no le llames "biblioteca", sino que no digas que cuando yo digo librería es un "falso amigo", porque ese razonamiento se basa en que todas las acepciones del término "library" en inglés se corresponden con una acepción de "biblioteca" en castellano; y eso es falso en el caso que discutimos aquí.
Tanto si lo llamamos "librería" como si lo llamamos "biblioteca" estamos ante la acuñación de un neologismo (que bonito :)) que en ambos casos se convertirán en palabras polisémicas. Y ambos casos son igual de válidos (o igual de erróneos).
#59 #63 #65 #66 #67 http://buscon.rae.es/draeI/SrvltGUIBusUsual?LEMA=librer%EDa
pero si librería, en castellano, es sinónimo (y por dos veces) de biblioteca... que cosas...
y por extensión el famoso "false friend" library es, como su nombre indica, falso
por cierto, ninguna de las acepciones de biblioteca o de librería tiene que ver con la informática, así que llamarlo como os de la gana
PD: gran noticia el tener direct3d nativo en linux!! ya hay ganas de probarlo
#68 Supongo que será un uso antiguo, porque en mi vida lo he visto usado así.
#67 Ya, pero te equivocas en una cosa, los préstamos fonéticos normalmente se hacen cuando no existe una palabra con la misma fonética en nuestro idioma (hello -> hola), pero si ya existe lo normal es usar otro método para no crear ambigüedad y no complicar innecesariamente el idioma. Uno al ver por primera vez la expresión «biblioteca de funciones» puede adivinar el significado, sabiendo que «biblioteca» es una colección de textos, en cambio, si ve «librería de funciones» lo que le viene a la mente es una venta, que no tiene nada que ver con lo que se pretende significar.
#69 los préstamos fonéticos normalmente se hacen cuando no existe una palabra con la misma fonética en nuestro idioma (hello -> hola), pero si ya existe lo normal es usar otro método
¿Alguna referencia que corrobore esto? Porque según tengo entendido la evolución es algo espontáneo, no está planificada ni sujeta a normas. Aún así, si lo normal es lo que comentas, pues estamos claramente ante un caso anormal.
Uno al ver por primera vez la expresión «biblioteca de funciones» puede adivinar el significado, sabiendo que «biblioteca» es una colección de textos, en cambio, si ve «librería de funciones» lo que le viene a la mente es una venta, que no tiene nada que ver con lo que se pretende significar.
Yo cuando veo el término librería/biblioteca en el ámbito de la informática no pienso en nada relacionado con libros. Igual que cuando pienso en ir a sacar dinero al banco no pienso en cuatro patas con una tabla encima. No me causa ningún tipo de confusión ni complicación las otras acepciones del término. De hecho, cuando veo una extensión ".lib" en un fichero, me resulta más fácil asociarla con "librería" que con "biblioteca".
De todas formas me parece perfecto que defiendas la idoneidad de usar el término "biblioteca" sobre "librería" argumentando que se mantiene la metáfora utilizada en otros términos del área como compilar, archivo o fichero. De hecho me parece un buen argumento, y acepto que usar estas derivaciones/adaptaciones pueda ser mejor para el idioma que el uso de extranjerismos. Lo que no acepto es que me digas que la traducción por "librería" es errónea por ser un "falso amigo".
Nos leemos en la próxima noticia que anuncien una nueva versión de la librería "X" (si hablan de bibliotecas no habrá polémica :)), y si en algún momento he hecho algún comentario fuera de tono o que te haya faltado al respecto, pues no era mi intención y espero que me perdones.
#70 Referencia no tengo, ni tiempo para buscarla, sólo mi memoria En todo caso, no es verdad que no haya normas en la creación de extranjerismos. En todo caso, habría que distinguir entre la creación de palabras hasta hace un siglo y la creación actual. Antes los extranjerismos los solían introducir los traductores profesionales o los escritores, gente que tenía cierta idea del idioma. Ahora lo suelen hacer los periodistas y cada vez más la gente corriente. En el primer caso, solían pensar mínimamente antes de crear una palabra nueva. En el segundo caso, no mucho, al menos no la mayoría de la gente, de ahí casos como «librería». En todo caso, yo creo que «biblioteca de funciones» es al menos tan antigua como «librería de funciones», aunque no tengo tiempo de buscarlo. Obviamente a tí ya no te resulta rara «librería», ya dije que me refería a alguien que viera la palabra por primera vez.
En absoluto me he sentido ofendido Da gusto poder argumentar con alguien en vez de que te voten negativo y sólo digan «esto es así y punto», si es que se dignan a contestar.
#68 Coño, si teníamos público
#39 Si, creo que tengo que actualizar los conductores de mi tarjeta grafica, pero no sin antes configurar mi rueda de girar para el Need For Speed.
#31 mientras no vea un benchmark de doom3 dando mas fps en linux que en windows sobre la misma maquina, solo son palabras
de todos modos yo he estado jugando mucho tiempo a doom3 y quake3 sobre linux y el rendimiento era practicamente igual a las versiones de windows, pero siempre "algo" inferior.. aunque en esa epoca habia que olvidarse de usar una ati por ejemplo ya que solo nvidia daba un soporte decente a opengl
Nunca he visto un juego, basado en opengl (de direct3d con wine ya ni hablamos) que funcione mas rapido en linux que en windows
Incluso las comparativas mas actuales, como esta:
http://www.phoronix.com/scan.php?page=article&item=linux_windows_part3&num=2
Tienen un ganador claro
¿Que puede ser que los drivers de windows sigan siendo mas "maduros" que sus homonimos de linux? no te digo que no, pero es lo que hay
#33 Usan Ubuntu. Linux no es solo una distro, yo te digo que con una sola distro no puedes hacer un benchmark, por que haces ese test en Gentoo , Debian , o Arch y se come a ambos .
#35 estare encantado de darte la razón en cuanto me enseñes un benchmark comparativo de un juego opengl (para igualar condiciones) windows vs linux (Gentoo , Debian , o Arch) en el que el ganador sea una de estas últimas
Mientras tanto, lo que dices son solo palabras.. sin fundamento
Me imagino a Berto leyendo esta noticia y los comentarios.
Jojojojojo fliparía como estoy flipando yo sin tener ni idea de lo que estáis hablando.
#16 Juegos diseñado para Windows en Linux de forma mas facil .
#17 Gracias.
Ser consciente de la propia ignorancia constituye un gran paso hacia el saber (Disraeli)
#30 Eso no dice nada. No dice ni la arquitectura, (de 32 a 64 bits hay un mundo ) ni la versión del driver, ni de kernel, ni su usa un escritorio con composición (ralentiza) o no , el kernel usado , etc ...
Un comentario dice lo mismo que yo :
( ... ) If you are serious about comparing Linux vs Windows, use a distribution or system that supports your hardware 100% and don't stick with a non-optimized kernel.
If you were really serious, you would also talk about the various possible optimizations on an open source system (compiling code for your specific system will make it *a lot* faster), mention high performance distributions like Gentoo and use an optimized glibc2 which already gives you another 9-11% performance over the one provided with doom3 (which seems to be compiled without any optimization flags for whatever reason). (...)
(...)My own results are similar to poster #18 's results: On an AMD64 3200+, FX6800, Gentoo (-O3 march=athlonxp) it's 25% faster than on WinXP. About 30-35% after replacing the provived crappy glibc with a symlink to the one my Gentoo system normally uses.
Otro :
First, you're using the 2.6.8 kernel for this test, which is known to be buggy. The major problem: the scheduler. How does this affect game and graphics performance? Greatly. This is why I'm using the 2.6.7 kernel, compiled from source from www.kernel.org.
Third, why have a full desktop environment loaded up to play a fullscreen game (KDE)? You want overhead introduced into the testing?
Fourth, you always should test multiple distros. As is, this is not a Windows versus Linux comparison. It is a SUSE versus Windows comparison. At a minimum, try SUSE, Mandrake, Fedora, Gentoo, and possibly Slackware (my distro of choice). Each one has its own quirks. Slackware is truly linux, because the vendor does not modify any of the source. However, it is much more difficult to configure correctly. Gentoo is a great distrobution because it is designed for being compiled specifically for the machine it is installed on. Using the straight source packages rather than vendor modified packages also goes a long way towards creating a fair test.
Los windows XP (DX9) se pondrán celosos de Linux!
Y les ha salido genial, fijaros en las imágenes de la noticia. Renderizados perfectos.
Está muy bien, ahora veremos Direct3D 10/11 para Windows Vista, para Windows 7 y ahora ¡ también para Linux !.
Salu2
El día que se pueda jugar a los mismos juegos en Línux, será el principio del fin del reinado del Güindous
#46 eso es una falasia semejante a la que argumenta que bajando el precio del software eliminaria la pirateria o aquella que dice que las empresas para lograr su hegemonia permiten que sus productos sean pirateados, para mas adelante generar dependencia.
#48 Hace poco vi en un comentario de meneame una alusión al http://en.wikipedia.org/wiki/Network_effect">efecto red. Así que como puedes ver, tu último punto no es ninguna falacia.
Para #48. La mal llamada 'piratería' siempre ha existido y siempre existirá. No se trata de REDUCIR la 'piratería', se trata de hacer el software accesible, y es evidente que una bajada de precio en el software original aumentaría sus ventas.
La mal llamada 'piratería' es un bien necesario, pues sin ella muchas personas jamas tendrian acceso a muchísimo software, e inclúyo siempre a los paises catalogados como no desarrollados en ese grupo, que gracias a Internet tienen una puerta de entrada a la cultura y a las nuevas tecnologias.
#61 Puede usar libwine para DirectX , no haría falta crear y usar un binario hecho para Win32 .
http://wiki.jswindle.com/index.php/WineLib
B. Harrosh: Winelib can be both your DLL calling code, and your complete Linux application. No need for .EXE compiled or crosscompiled for windows, No need for IPC and no need for two parts at all.
It has been proven that any windows code can be compiled as Winelib. If you are using core Libraries like MFC or ATL than that might get difficult (not impossible)[...]. On the other hand Winelib applications are a Linux applications so they can link to any Linux library. Just that they have a funny Makefile and are built with Winegcc.
Siiiiiiiiiiiiiiiiiiii!
#32
¿me servirá para el osgrid? supongo que sí....
Relacionada: Por qué deberías usar OpenGL y no DirectX [ENG]
Por qué deberías usar OpenGL y no DirectX [ENG]
blog.wolfire.com#61 en resumen: juegos como el Need For Speed Shift podrían ser portados a Linux con poco esfuerzo...
Creo que sois un poco ingenuos.
Realmente pensáis que a una compañia de software le importa tres cojones si su juego funciona en Linux? Si va lento en Windows, pues que el usuario se compre la última nVidia/Ati o el último i7 y a correr. Si al final van todos de la mano.
Vale, con Linux podré jugar al FarCry con un 386 pero... y a mí qué más me da? Quién tiene un 386 en casa? (es un ejemplo exagerado, se puede extrapolar a un Ahtlon 3000+)
#38 Yo tengo 2 80386 y 2 sin montar.
1 8086, 1 80286, 1 80486, 1 pentium 100, 1 Pentium II, 1 k6-2
Aunque me gusta mucho Linux y el software libre, es hora de aceptar la aplastante realidad.
Da igual que salga Gallium3D Pro Edition o Wine Rioja Turbo. En un mundo en el que los videojuegos para Windows dominan el mercado en detrimento de otros sistemas como GNU/Linux y OSX, el que salga una API que implemente de forma nativa Direct3D es lo de menos. Se seguirá desarrollando para Windows y mientras los linuxeros se tendrán que conformar con el tux racer y supertux hasta que adapten su Wine XP Professional y Gallium3D Vista para los nuevos juegos que vayan saliendo.
No nos olvidemos de OpenGL, ése pobre hijo bastardo abandonado de la mano de Dios. Juegos como Doom 3 lo utilizan en Linux, pero ya sabemos cuál es el resultado: un pésimo rendimiento. Luego tenemos manadas de freetards enfurecidos ensuciando los foros de Internet dedicados a los usuarios de Windows diciendo que Doom3 es una mierda y Windoze sux.
Y lo que yo me pregunto amigos míos es: ¿qué sucederá cuando aparezca Direct3D 12? El software volverá estar en las mismas, atrapado en su afán de seguir al insuperable software privativo en vez de tratar de imponerse al Innombrable.
Y tú, ¿ya has jugado al Crysis en tu Ubuntu GNU/Linux?
#8 Otro troll Windowsero sin tener ni putisima idea de lo que habla. Se ha implementado Direct 3D 10 de forma NATIVA gracias a la capa intermedia de los drivers con Gallium / DRI , es decir, algunos libres de ATI y el libre de NVIDIA, nouveau .
http://en.wikipedia.org/wiki/Gallium3D
· 1 Doom 3 está nativo en Linux y el rendimiento era muy superior que en Windows. ¿ Razones ? Kernel en tiempo real y asignación de proridades .
·2 Doom3, Quake4, Nexuiz con Bloom y luces dinámicas por partículas en tiempo real, FlightGear2 ...
Differences from Mesa 3D
Gallium3D provides a unified API exposing standard hardware functions, such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL 3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility layer) will need only a single front-end, called a state tracker, targeting the Gallium3D API. By contrast, Mesa 3D requires a different back-end for each hardware platform and several other APIs need translation to OpenGL at the expense of added overhead.[4][5][6]
Under Gallium3D, Direct Rendering Manager (DRM) kernel drivers will manage the memory and Direct Rendering Interface (DRI) drivers (now moving to DRI2) will be more GPU processing oriented. This will resolve memory management problems whose solutions are considered infeasible under Mesa 3D.[7]
LLVM usage
In addition, using the modular structure of Gallium3D, there are works underway to leverage the LLVM compiler suite and create a module to optimize shader code on the fly.[8] TOMA OWNED
The library represents each shader program using an extensible binary intermediate representation called Tungsten Graphics Shader Infrastructure (TGSI). When Gallium targets LLVM, the TGSI code is converted to the LLVM instruction set.
#8 La Fuerza me dice que te van a coser a negativos
Tienes razón en parte. Yo la verdad, hace años que no toco un juego en el ordenador (salvo el Age II, lo siento, es mi vicio ). Si sale DirectX 12, pues se actualiza la versión de linux y arreando que es gerundio
Quizás no se desarrolle para linux, pero imaginate las posibilidades de portar un juego sabiendo que el rendimiento va a ser el mismo y con un coste
de tiempo minimo.
Piensa que este grupo de trabajo ( que son cuatro amigos) estan portando y follandose vivos a toda la gente que está en nómina de microsoft, que son muuuchos.
Como apunta #9, el rendimiento puede dejar en bragas cualquier equipo Windows
#9 no es un troll windowsero, es el meme de la verdad a la milanesa de Barrapunto http://www.google.com/custom?query=aunque+me+gusta+mucho+linux&domains=barrapunto.com&sitesearch=barrapunto.com&client=pub-1936842256917240&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23000099%3BGL%3A1%3BDIV%3A%23FF6600%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AFFFFFF%3BALC%3A000099%3BLC%3A000099%3BT%3A000000%3BGFNT%3A6699CC%3BGIMP%3A6699CC%3BLH%3A50%3BLW%3A259%3BL%3Ahttp%3A%2F%2Fimages.barrapunto.com%2Flogo-bp.gif%3BS%3Ahttp%3A%2F%2Fbarrapunto.com%3BFORID%3A1%3B&hl=es
Muy bien, pero para que podamos sacar provecho del DX10/11 necesitaremos Wine o se podran desarrollar juegos para Linux que usen las DX? Es que no tengo claro lo que dice #9
#28 Si el juego esta echo para windows y usa llamadas al sistema de windows seguirá necesitando wine para traducir, pero cuando haga llamadas a la gráfica mediante direct 3D , ya no hará falta traducirlas. El rendimiento que se pierde al traducir las llamadas a direct 3d es inmensamente mayor que las llamadas al sistema.
Ademas, si una compañía tiene un juego que usa direct 3d para windows y lo quiere sacar para linux, los cambios que tendrá que hacer serán muy pocos.
#9 aunque transcribes ciertas cosas interesantes, mientes cuando dices que doom3 era mas rapido en linux:
http://www.anandtech.com/show/1509/5
Obviamente hoy en dia las implementaciones de opengl en linux han mejorado bastante y probablemente estén a la par, como otros juegos que tiran de estas librerias pero lo que has dicho, es falso
Y a la gente solo le importa que el juego vaya bien cuando ha salido, o poco después, no 6 años mas tarde
#9 ¿Kernel en tiempo real? No será el de Linux. A no ser que tu concepto de "tiempo real" sea distinto al mío.
#8 Tu razonamiento es muy extraño, aunque he podido entender que lo que pides son más juegos para Linux. Lo secundo.
#8 Vaya tu comentario me suena de algo...
PD: Te informo que el de la milanesa hasta en BP se ha (¿han?) cansado de hacerlo.
#8 Si no sabes de que hablas... mejor no comentes...