Hace 9 años | Por Black_Diamond a news.softpedia.com
Publicado hace 9 años por Black_Diamond a news.softpedia.com

NVIDIA ha anunciado que el código fuente de su motor de simulación física PhysX está disponible de forma gratuita en Github. Tras una década de desarrollo cerrado, la compañía pondrá su código a disposición de los desarrolladores que previamente se hayan registrado en la plataforma nvidia.com y hayan aceptado los términos de uso. Instrucciones para acceder al código en: https://developer.nvidia.com/physx-source-github Noticia en español: http://libuntu.net/2015/03/07/nvidia-libera-el-codigo-fuente-de-physx-en-github/

Comentarios

G

#2 ¿y?

Es tecnología open que se puede implementar y se va implementar sin dependencia de que tengas una NVIDIA, o sea va a pasar de ser algo inútil solo para marketing a algo casi inútil a algo útil para el desarrollo y usuarios.


Es lo que más critico personalmente a NVIDIA, mientras AMD establece open standards, colabora con la comunidad ofreciendo sus tecnologías a quien quiera adaptarlas sea cual sea la arquitectura, NVIDIA las cerraba y las hacia dependientes de hardware, con solo la intención de vender tarjetas a miles de usuarios que no iban a aprovechar dichas tecnologías con sus gráficas (o apenas).

Que sea free no es irrelevante pero es más relevante este paso que a dado que ninguno.

Desde el punto de vista de desarrollo poder utilizar estas tecnologías sin temer que solo vayan en una parte de usuarios (yo no implementaría nada que fuese dependiente de hardware ) es una gran noticia.

G

#4 A ver que me la suda pesado que sea libre, lo han echo open (y no me refiero a open source solo si no open de uso) y lo van a implementar para DX11/DX12 o sea que rulara tengas AMD o NVIDIA, dejara de ser dependiente. Con eso me llega. Si fuera free mejor pero que no es lo más importante actualmente.

D

#5 "(y no me refiero a open source solo si no open de uso)"

No, no es open. Si fuera open tendríamos PhysX en nouveau, o incluso en Intel o AMD en Linux. O con GLnext de Valve. Y no, no lo tendremos.

O Nvidia espabila y colabora con Nouveau, o tendremos años oscuros.

AMD con GLNext llegará a una época de oro, idem con Intel la cual ya tiene un driver más optimizado y que según valve vuela.

G

#6 Mejor no hables de lo que no sabes. Estoy siguiendo el desarrollo de NVIDIA y Gameworks desde el principio (que cambiaron de política) y te estoy diciendo que tendremos PhysX y toda su gama de GameWorks corriendo con AMD mediante DirectX)

O sea como te dije desde el principio independiente de hardware. Aunque en principio solo via DX.

D

#7 ¿En radeon bajo Linux incluso con MESA + GalliumNine?

Sí, mejor no hablo de lo que no sé.

G

#8 ¿que parte de independiente de hardware no entiendes?

Y de software en principio NVIDIA va a portalo a que rule via DX.

D

#9 ¿Y tu qué parte de Gallium3D y código libre no entiendes?

Gallium3D también es independiente del hardware.

DXD9 es un state-tracker para enviar comandos DX a la GPU, Gallium es una capa intermedia.

Y por rendimiento, el GTA IV tira hasta con Nouveau+WineD3D9 más rápido que Wine con los cerrados de Nvidia.

G

#10

And starting this month, the PhysX SDK is available free with full source code for Windows, Linux, OSx and Android,"

D

#11 Eso no me dice nada, también es open source el módulo del kernel de Nvidia para sus drivers cerrados, y siguen siendo propietarios.

A ver cuando te das cuenta que open source no es igual a libre.

G

#12 a ver cuanto te das cuenta que se perfectamente la diferencia y que me la suda para lo que venia comentado que sea libre o no. Que lo que quería es que lo abrieran su uso y lo han hecho.

D

#13 Pues no se nota. Sí fuera libre podríamos meterlo en el Xonotic y crear efectos brutales para las partidas multijugador online que requieran físicas avanzadas. De momento, tal cosa es imposible.

G

#14 Puedes implementarlo donde te salga del nabo. Tienes el SDK abierto a su uso.

Claro que si lo implementas en eso que dices si es software libre perdería la denominación de "Free software" pero por poder puedes implementarlo.

D

#16 No, no puedo.

De momento solo puedo acceder si soy desarrollador del motor Unreal de Epic.

Segundo, tampoco puedo adaptarlo en proyectos libres, ni modificarlo para mis usos.

G

#17 No hace falta solo tienes que registrarte en el Game Developer Programa para pillar el SDK y empezar a implementarlo donde quieras.


Si quieres acceder a la implementación de UE4 con PhysX tienes que registrarte en UE4 (que es gratis)

D

#18 Pero no es libre, repito.

Si fuera bajo licencia Mit si sería una gran noticia.

G

#19 Pesadito con el libre, no no lo ES. Es una tecnología que a pasado de closed a open. Y si es una gran noticia.

D

#20 ¿Y qué que sea open source? Es tan relevante como si siguiera cerrada.

G

#22 No por que es open antes no se podia implementar ni utilizar en diferente Hardware NVIDIA ahora si.

#18 Por supuesto no es GPL ni puedes cambiar la EULA de ellos. Tampoco puedes hacer un proyecto UDK y convertirlo GPL por que te sale de los eggs, con PhysX o sin el. Si utilizas UDK estas condicionado a su EULA.

D

#23 " No por que es open antes no se podia implementar ni utilizar en diferente Hardware NVIDIA ahora si."

Sigue siendo incompatible con las licencias actuales de drivers libres. Nos quedamos como estamos.

G

#24 Te quedaras igual tu. Yo lo voy a utilizar para desarrollar cuando antes no se me pasaba por la cabeza utilizarlo para que solo funcionase a usuarios que tengan NVIDIA. Claro que no lo utilizare en nada que quiera que siga siendo "GPL" o similar.

Este noticia no esta pues en sub Linux te recuerdo.

D

#25 Si supieras la relevancia que traerá GLNext para los drivers libres y el propio PHYSX no dirías lo mismo.

G

#26 LLevo más de 15 años (seguramente 5 menos de la edad que tienes tu) utilizando y colaborando con "free software" pero mi mundo no se basa solo en "Free Software" ni todo gira alrededor de el. Y veo las buenas noticias aunque no tengan que ver con el "Free software".

D

#27 " pero mi mundo no se basa solo en "Free Software" ni todo gira alrededor de el. "

Pues cada vez más. Al menos en sistemas y drivers. Lo estamos viendo.

LaInsistencia

#23 espera, espera, espera... vamos a ver.

Suponte que pasado mañana, dentro de cinco años, aparece un bug brutal en ese código *de NVIDIA*, o se descubre que una función hace las cosas de una manera tan descaradamente mal que afecta al rendimiento no ya en porcentajes sino en ordenes de magnitud. ¿Su licencia me permitiría sacar un parche que resolviera el problema sin romper esa licencia?

Si la respuesta es "no" o "no se sabe", creo que deberías bajarte del burro y replantearte si de verdad es suficiente con lo que proponen. Nada mas.

D

#18 "The rights to develop and release a game for free are contained in the
end-user license agreement (EULA). The EULA is also the license that
governs the release of your game as it’s built on UDK. You can’t release
your UDK project under terms other than the UDK EULA (like GPL, LGPL). You don’t have the right to encumber the UDK with
terms that we have not already granted to you."

D

#13 Después de los palos que le están cayendo por la picia de las 970 el monte de mierda que a resultado la 960 y que esta esperando a que amd saque las 3xx para moverse como que esto es mas marketing de mierdas que otra cosa no baja las 970 3,5g ni las 960 las pone en su precio real o saca la 960ti con 3g-4g que es como debió de salir.
PD:Phiscs es una mierda que usa 4 juegos otro proyecto rana de nvidia.

D

#6 GLnext ahora se llama Vulkan: https://www.khronos.org/vulkan

G

#58 A ver que yo no estaba hablando de "open source" y en ningún lugar hable de "open source" es el nene que se emperro con el "open source". goto #5

G

#58 #61 Aparte añado, no tiene ni idea de diferenciar entre "open source" y tecnologia abierta/open que era de lo que hablaba yo desde el principio y va soltando clases aun por encima.

D

#65 "Aparte añado, no tiene ni idea de diferenciar entre "open source" y tecnologia abierta/open "

Las abiertas son una estafa como la licencia de unrar o los módulos con blobs del kernel de Linux.

El tiempo me dará la razón.

Bueno, solo tienes que ver la maravillosa compatiblidad de Catalyst, o los driver legacy de Nvidia donde hasta las RADEON antiguas tiran mejor.

Pero oye, seguid, seguid atados a tales componentes, como pasó con xfree86.

epsimac

#70 #65 Idos a un motel!

D

#1 #2 A efectos prácticos Open source es lo mismo en cuanto a código. En este caso tampoco cumple los requisitos el código tiene restricciones de distribución, y no se puede acceder legalmente a él sin aceptar un EULA.

To access the GitHub repository, simply join the NVIDIA GameWorks Developer Program and accept the click-through EULA for PhysX source code. Full details can be found here.

Proporcionan acceso al codigo en condiciones demasiado restrictivas para ser open source.

D

#40 "efectos prácticos Open source es lo mismo en cuanto a código."

No, ya te he dado ejemplos donde por ser opensource no te garantiza la libertad.

D

#41 Puedes la definición de esta organización http://opensource.org/

Este SDK no la cumple. Y soy otro usuario. Open Source, según esa definición, implica código fuente redistribuible y modificable en cuanto a copyright del mismo (Marcas registradas, trabajo gráfico y patentes no contemplados)

G

#40 Yo en ningún lugar hable de open source. De hecho me refería siempre y recalque lo de "open", lo que ha hecho NVIDIA es abrir su tecnologia y el código fuente a developers. Una tecnología que era cerrada.

Es el linuxero este pesado (típico de linuxero novato) que se cree hermano de stallman que sin venir a cuento empezó soltar estupideces y dar lecciones de "free software" y demás que no tienen nada que ver con la noticia. Además a alguien que lleva siendo linuxero posiblemente tantos años como edad tiene el. lol

D

#43 "Es el linuxero este pesado (típico de linuxero novato)"

Empecé con Debian Woody. A pastar.

Aunque no sé de qué me quejo, si total estoy a un paso de migrar a OpenBSD definitivamente.

G

#44 ¿te la descargaste el año pasado no? hay versiones más recientes.

D

#45 No, es la que aprendí en su día.

Es lo que tiene saber de lo que se habla.

Y de sufrir XFREE86 y sus cambios de licencia frente a X.org .

Pero sí, XFREE86 se usa bastante, no veas.

G

#46 que si que ya quedo demostrado que INTENTAS demostrar que sabes mucho de linux pero vete a una noticia sobre linux para esas cosas.

Yo lo pase mal vamos me duro la depresión 1 hora creo.

D

#48 No es sobre Linux. Este código nos afecta a todos

¿O es que Gallium3D solo existe en GNU/Linux? ¿Mesa? ¿DRM/KMS?

G

#49 Lo de Gallium3D que fue algo que aprendiste que era este ultimo mes? lo repites mucho.

D

#50 Lo de Gallium3D es algo que hace que te la sople si tienes que implementar DX u OpenGL:



ASÍ se hacen las cosas bien y portables.

"Note that in this video the graphics card ( a Geforce 670 GTX ) is running ( i think ) at almost 1.5/10 of it's max clock speed and the game is at highest settings !!"

Pues eso. Incluso con un tenue soporte con los drivers Nouveau se acercan al rendimiento nativo gracias al SL. En Radeon vuelan.

PHYSX no saldrá de su nicho + Unreal.

G

#51 Me hablas de hacer "las cosas bien y portables" poniendo un video del call of duty ejecutandose sobre wine? lol

PhysicX parcialmente ya se utilizan en en cualquier juego que te bajes de STEAM o con cualquier juego con soporte para linux hecho con el Unreal por ejemplo.

Por cierto el call of duty no es free software.

D

#52 Y glnext funcionará en cualquier parte y PHYSX no.

Desde tu movil hasta SteamOS/Cualqueir Linux/Cualquier BSD.

"o un video del call of duty ejecutandose sobre wine"

Wine con DXD9 nativo via DRIVERS , no traduce nada de DX a GL.

G

#53 No tienes ni puta idea, eres cómico. lol

Venga lo dejo que tengo que hacer algo más interesante, como sacar a mi perro a pasear.

D

#54 No, qué va. Por eso VALVE ha sacado drivers con soporte GLNEXT para Intel de forma libre.

D

#44 Aunque no sé de qué me quejo, si total estoy a un paso de migrar a OpenBSD definitivamente.


¿Creo que dijiste lo mismo hace un par de años? ¿O era FreeBSD?

D

#68 Open. Free tiene la locura xml del HAL y PolicyKit sin configurar y es un sindiós. OBSD va directo, metes XFCE y toadd y solo es tocar rc.conf

Señor_Mandarina

#69 Me lo he leído todo en profundidad, ¡crack! coñoya

sombra2eternity

#43 #44@GoDie Leo regularmente los comentarios de@Ander_ y no creo para nada que sea un novato, os habéis enzarzado en una discusión que no lleva a nada, por lo que voy a intentar explicartelo yo con un poco más de detalle.

Esto ya lo leí hace semanas en Phoronix, y realmente, aunque todavía el grueso de los jugadores está en windows, motores como UT y otros intentan no integran nada que no se pueda usar en otras plataformas. El tema de Gallium es muy importante a estas alturas.

Gallium es un contenedor de drivers, por explicarlo brevemente es a los sistemas de drivers los que LLVM es a los sistemas de compiladores, un contenedor con una serie de capas de sucesivas optimizaciones. Tanto es así que todos los drivers nuevos, como los de NVIDIA Tegra ya se hacen en este formato, el blob binario no es tan sencillo porque estará "patent-encumbered" hasta arriba (lo mismo que le pasa a Physx seguramente, por mucho que a partir de ahora puedas echar un vistazo a su código fuente), pero ATI e Intel (este excepto ILO aún va por classic MESA pero bueno) ya están ahí.

Entonces, para que esta tecnología llegue a otros sistemas (y esto es interesante por el tema de consolas, sobre todo por steambox) necesita ser integrada en los drivers/state trackers. "Gallium Nine" por ejemplo es un state-tracker que implementa DirectX9 para todos los drivers bajo el estándar Gallium, que como te ha comentado en muchas ocasiones es incluso más rápido que el nativo o sistemas de traducción como el de wine (directX->openGL). Dudo mucho que los desarrolladores de los drivers de Gallium, léase Nuevau, Radeon y otros tantos de android (qualcom,samsung) o los desarrolladores de drivers que están aún fuera de Gallium como el de Intel integren algo con tanta pinta de ser problemático a futuro, ya pasó con una cosa mucho más crítica y nímia como es la compresión de texturas (el tema de S3TC) que se resolvió relegandote a tí la responsabilidad de proveer una librería que implemente esa compresión, si es legal o no la posesión de una de estas librerías es cuestión de cada uno (y sobre todo de la legalidad de cada país, en Europa estamos a salvo de momento).

Y si NVIDIA no consigue que esto sea multiplataforma para mi tiene poca relevancia, supongo que para@Ander_ igual y de ahí viene vuestra discusión, más aún cuando Valve, ATI, Intel, UT y otros muchos importantes agentes están empujando por una nueva tecnología como Vulkan y que promete bastante. Creo más bien que este movimiento por parte de NVIDIA es fruto de la pérdida de interés por una tecnología que nadie ha querido hasta ahora y que va a seguir sin ser relevante, pero al menos se hacen una foto de cara a la galería. Dentro de 6 meses no leerás el titular "Muchos desarrolladores se han divertido usando Physx en sus ratos libres pero ninguna gran compañía ha mostrado interés real por implementarla" sin embargo apuesto a que ocurrirá, da lo mismo que micro$oft lo meta en DirectX nativo, si tengo que hacer un juego multiplataforma y algo solo funciona en una de las plataformas lo descarto en aras de la portabilidad, y esto hoy día pasa mucho más de lo que te imaginarías.

Un saludo.

G

#87 Ya es multiplataforma, lo que todavía sigue siendo hardware dependiente (necesitas NVIDIA), pero es algo que van a arreglar a lo largo del año como he dicho..

Evidentemente yo no voy a hacer uso de el mientras siga siendo dependiente de hardware. Por eso sigo atentamente el cambio de politica que esta llevando
a cabo nvidia al respecto, yo y muchos otros devs están interesados en Gameworks. (aunque lo anunciara en el GDC ya llevan unos meses, no es una noticia nueva para los que estamos interesados)


Efectivamente yo también creo que lo libero por cambio de política al que Gameworks a pesar de lo bonito que es se la sudaba a todo el mundo, cosa que es lógico si vas a dejar de lado a una buena parte de usuarios.

D

#87 ILO se está integrando poco a poco, y Gallium se usa en SSOO como BSD, Aros y Haiku.
De hecho en teoría se podría usar Gallium en Windows igualmente.

sombra2eternity

#92 Si, si no soy un desentendido, hace muchos años que sigo el desarrollo de mesa, de hecho lo que comentas de Gallium sobre Windows no es solo una teoría, se que se prueba regularmente, de la misma manera que igual a muchos le sorprenderá que hay gente que juega a juegos en windows a través de wine (por la compatibilidad con antiguas plataformas).

t

#44 no es que tenga demasiada relevancia ni que sea un concurso...pero la primera vez que probé linux fue con la red hat 1.0 y lo uso profesionalmente casi exclusivamente desde la versión 7.3 o asi. Soy defensor convencido de linux y de su filosofía. Y en estos años da gusto ver como se ha ido implantando poco a poco. Pero es realmente cansino escuchar a los padres espirituales de stallman que van surgiendo regularmente. Y digo padres porque algunos son todavía mas radicales que él.

te_digo_que_no

#15 Estais verdes de Nvidia

Claudio_7777

#15 épico!

D

#15 LOL

G

#15 lol no lo había visto.

sid

#15 Si hicieran todas las cosas como esta noticia Linus no les dedicaria tantos fuck you

D

#1 Hacerlas compatibles con DirectX significa hacerlas incompatible con cualquir SO que no sea Windows o XBox.

G

#33 No del todo, quiere decir que esa implementación que va a hacer nvidia de su Gameworks usando DX11 no sera compatible, pero bien puede cualquier hacer la implementación para opengl/glnext. El sdk esta open.

Por ejemplo ya que se menciono el UE4, y dado que este es un engine que presume de hardware independiente, si lo meten en el branch principal alguien portara todo eso a glnext, si no estar Gameworks en la rama principal, pues no hacen nada en el branch principal que sea hardware dependiente.

De hecho parte PhysX esta implementado en UE4 desde los inicios de forma multiplataforma, APEX, y los destructibles. Lo que es cpu-based. Sin aceleración gráfica vamos. Y funciona perfectamente bajo linux o windows.

D

#34 MESA con PHYSX sería un desastre.

Que manía con que el sdk esté abierto. Que no vale para una puta mierda fuera de su entorno cerrado, leñe.

Ese código "open source" vale lo mismo que unrar para crear un archivador con soporte V3 o los mods del kernel Nvidia para Nouveau : cero .

G

#36 Perfecto tio venga a tu rollo y a tomar el aire lol
que ya pase hace una decada del rollo de aguantar a fantasmones que aprendieron hace poco a utilizar el gcc y están subiditos.

D

#37 Sysadmin, pero gracias

Hala, majo, sigue con tu bazofia propietaria.

Ya ves el buen "camino" que cogió el driver "nv" y demás morralla.

O unar frente a unrar, que se lo come completamente.

EmuAGR

#37 #39 El compañero Ander_ tiene razón, que sea "open source" significa que puedes ver cómo han implementado la tecnología. Eso no significa que puedas usarla sin su permiso o modificarla a gusto.

Es más, se te puede caer el pelo si, sin su permiso, haces algo un poco diferente de mirar el código y te pillan sus abogados. (Estoy hablando sin haber leído el EULA y no sé qué condiciones ponen, no obstante).

Golan_Trevize

Mi frigorífico no enfría, pero es "open source" y "libre", que a fin de cuentas es lo que importa.

Zeioth

#38 Si es open source siempre podras hacer tu mismo que enfrie si algo falla

M

#59 Siempre se suelta eso de "siempre puedes hacerlo tú porque es libre" cuando la inmensa mayoría no tiene ni idea de hacerlo y lo único que quiere es que funcione.

Zeioth

#71 Quien se beneficia de la filosofia open source es la comunidad de desarrolladores. Si eres usuario en vezde desarrollador, pues ya implementará alguien por ti la funcionalidad que necesites, si es que mas gente la pide.

M

#74 Yo por contra usaré aquello que cubra lo que necesite, ya sea este libre o cerrado. No por ser libre lo voy a usar antes que uno privado si el libre funciona peor, solo por el hecho de ser libre. De ahí lo de que mi frigorífico no enfría pero es libre, que es lo que importa. Pues no, lo que importa es que enfríe, si es libre o cerrado es a mayores.

sdar

#75 No es por nada... pero creo que valve recomienda Nvidia si quieres usar Steam en linux, ademas de que la hazaña de que Left 4 Dead 2 corriera mas rápido en linux que en windows (y llevan toda la vida optimizandolo en windows) se hizo con una tarjeta nvidia, ademas de juegos como Stalker que solo funcionaban correctamente en nvidia cuando salio (en linux)... y que aún a día de hoy sigue funcionando mucho mejor en nvidia que en AMD.

El driver propietario de AMD es muchísimo peor que el de Nvidia, el driver libre de amd en cambio si es mucho mejor que el libre de Nvidia pero los drivers libres no soportan opengl 4.x todavía.

Se esperan grandes cambios con Vulkan (OpenglNext) puede que incluso los motores de físicas corran en SPIR-V y ya no haya que preocuparse de que marca de gráfica uses, pero actualmente a nivel Opengl 4.x y anteriores el driver de Nvidia es el mas robusto con diferencia.

Señor_Mandarina

@Ander_ gracias por el curro en explicar la sutil diferencia de "libre" y "open source" Stallman y J.locke te apoyan.

PD: empecé con sarge

pd: ascazo de emoticonos nuevosgallirgallir

D

#73 Me enerva esta discusión.

Valve. Los juegos bajo los drivers libres de Intel no van tan bien como deseamos. Los cogemos, los mejoramos y devolvemos los cambios a sus creadores originales. Idem con MESA y ahora con el bombazo de GLNext.

Resultado: Más FPS bajo Linux que con Windows, un avance enorme para MESA y como he dicho, GLNext revolucionando el mercado. Y los juegos por supuesto más optimizados que nunca. Ni en consolas excepto la era de "8 y 16 bits". Nada.

AMD: Algo mejor con Radeon, pesadillas con Catalyst. Con suerte la dependencia de firmware no-libre no será necesaria en un futuro.

Con Nvidia, te jodes, simple y llanamente. Desarrollas en plan caja negra y con suerte te funciona mejor.

Pero claro, qué más dará que liberen algo de forma libre que el que no.

Qué sabrán los de valve.

Gaiden

No se si se ha dicho ya, pero es el código fuente para physx por cpu y NO por gpu. Esto y nada es lo mismo.

G

#47 Actualmente si, pero lo van a a portar para que utilice aceleración gráfica.

Y de nada tampoco, por que actualmente hay bastantes juegos utilizando PhysicX por CPU con sus limitaciones pero que funciona perfectamente.

Sheldon_Cooper

#85 compatibles.. en el sentido de que funcionarán, sí, pero a base de hacer por software todas las funciones nuevas salvo que el fabricante ya hubiera tenido en cuenta la especificación futura y solo sea decirle al driver como acceder a ello en cuanto dx12 esté en el mercado (siempre que la especificación no cambie, que lo mas probable es que lo haga).

Zeioth

A quien mas va a beneficiar es a los drivers abiertos de Nvidia para Linux. Desde la reprimenda que les echó Torvalds se han puesto las pilas bastante, ahora son quienes dan mejor soporte.

D

#57 Para nada.

Zeioth

#60 Te creo, pero podrias desarrollar un poco tu respuesta? Ten en cuenta que me refiero principalmente a sus drivers privativos, que estan dando en torno a un 30% mas de rendimiento que los de AMD.

D

#63 Este codigo de Physx no es libre. No es usable con nouveau. Ni aceptable.

#62 Segun comentan hasta Havok tira mejor encima.

D

El código actual de PhysX para CPU no vale un mojón.
PhysX en CPU está hecho adrede para que vaya lento. No utiliza ningún tipo de unidad vectorial. Sólo x87.

PhysX 3.0 añadió soporte para algunas funciones vectoriales de los procesadores, pero sigue siendo un chiste en comparación con lo que hay.

De la Whiskeypedia:

In response to the Real World Technologies analysis, Mike Skolones, product manager of PhysX, said[19] that SSE support had been left behind because most games are developed for consoles first and then ported to the PC. As a result, modern computers run these games faster and better than the consoles even with little or no optimization. Senior PR manager of Nvidia, Bryan Del Rizzo, explained that multi-threading had already been available with CPU PhysX 2.x and that it had been up to the developer to make use of it. He also stated that automatic multithreading and SSE would be introduced with version 3 of the PhysX SDK.[20]

PhysX SDK 3.0 was released in May 2011 and represented a significant rewrite of the SDK, bringing improvements such as more efficient multithreading and a unified code base for all supported platforms.[2]


Si hablamos de coma flotante, ya los últimos procesadores tienen AVX2 y la última versión de SSE es la 3. Tanto la 4 como la 4.1 me parece que no añadían nada significativo para coma flotante.

G

#62 Aphex/Clothes y destructibles con sus limitaciones funcionan bien aun siendo cpu-based. Trabajo con ellos sin problemas y los resultados son buenos. Evidentemente podría ser mejor. Pero lo contrario seria nada.

Y muchos juegos hacen uso de ellos.

sdar

#62 Tu estas hablando de physx 2.x y anteriores que estaban basadas en el código antiguo (NovodeX) en el cual no se utilizo sse porque no pensaban que la mejora en rendimiento valiera la pena ademas de que sus creadores no sabían utilizarlo por aquel entonces, sopesaron utilizar no obstante SSE2 pero hubiera limitado su uso en ciertas maquinas en ese momento.

Con Physx 3.x es diferente el código es totalmente nuevo y SI utiliza sse y avx ademas de soportar multi-hilo... es mas las pruebas que he visto de momento dicen que es mas rápido en CPU que cualquier otra alternativa como havok o bullet physics, este ultimo espero que mejore ya que es abierto.

Lo mismo dicho por el creador de Physx: http://www.codercorner.com/blog/?p=1129

P.D. también tengo entendido que desde la versión 2.8.4 se usaba SSE pero que como no estaba escrito con SSE en mente no se notaba mucha mejoría.

Veelicus

para los que andan debatiendo sobre open source y demas...

http://www.informatica.us.es/~ramon/articulos/LicenciasSoftware.pdf

Veelicus

Recientemente lei que con DirectX 12 las tarjetas que mas se iban a beneficiar eran las ATI ( obviamente las nativas en DirectX 12 seran mejores), quizas eso haya influido en que NVidia comparta su codigo.

G

#77 Todas las tarjetas compatibles con DX11 seran compatibles al 100% con DX12

D

#83
No, no es así.

Eso es como decir que las tarjetas DX 11 son compatibles con DX 11.2.

Veelicus

#84 Creo que tienes razon, sin duda muchas se beneficiaran, pero si alguien esta pensando en pillar una grafica y puede esperar, mejor esperar a tener una grafica nativa.

D

Esto hará que haya drivers decentes en Linux. #NOPE

D

Ojo por que yo leí por otro lado que lo que piensan liberar es PhysX por CPU, vamos la versión que se ejecuta por software, y esta implementación la llevan muchos juegos y se ejecutan igual de bien con cualquier marca de tarjeta gráfica, el tema está en los que utilizan PhysX por GPU, de modo que si tu gráfica no es de nvidia no puedes ver los efectos de físicas, por lo que el juego realmente parece otro. Esto más bien parece un movimiento para darse algo de publicidad y de paso competir con Havok que es el mejor motor actual para físicas por software, y compatible con cualquier hardware.

http://www.noticias3d.com/noticia.asp?idnoticia=63994