Source: https://www.realovirtual.com/foro/topic/9167/rendimiento-drivers-htc-vive-oculus-rift-cv1
Timestamp: 2020-02-27 10:57:34+00:00

Document:
Foro: General > Rendimiento de drivers en HTC Vive y Oculus Rift CV1
Tema: Rendimiento de drivers en HTC Vive y Oculus Rift CV1
Neoskynet » 8 MAR 2016 13:28
He recordado una cosa que me dijo Lluis en la prueba que hice del HTC Vive en Barcelona, y es que en la demos de la ballena la probaron con una GTX970 y en algunos momento daba micro-saltos porque le faltaba potencia. Le pusieron una GTX980 y ya fue bien.
Despues de haber probado estos días el Elite Dangerous con SteamVR y tener que poner la calidad a LOW porque sino iba fatal, con muchísimo judder, me queda la duda de si el HTC Vive tendrá un rendimiento peor que Oculus Rift CV1.
Me refiero a que HTC Vive creo que sólo utiliza los drivers de SteamVR, y en cambio Oculus Rift CV1 puede utilizar los suyos propios y también los de SteamVR, pero estos últimos con peor rendimiento, al menos en Elite Dangerous.
¿HTC Vive tiene unos drivers independientes que se puedan utilizar sin SteamVR y que tengan mejor rendimiento, tal y como pasa con Oculus Rift?
¿Esta perdida de rendimiento con SteamVR es generalizada en todos los juegos o sólo pasa con el Elite Dangerous?
¿SteamVR soporta las ventajas de Nvidia para VR, como SLI y otras, de forma generalizada o cada juego lo tiene que soportar por separado?
Ahora mismo me surgen estas dudas, pero tengo claro que el tema de los drivers no hará otra cosa que mejorar. Lo malo es que va todo tan despacio que llega a ser desesperante los pocos avances que hay y encima me da la impresión de que parece que vamos a tardar 5 años en tener lo que nos gustaría en RV ahora mismo.
Si estoy equivocado en alguna cosa, por favor, corregidme.
Nota importante: Por favor, no convirtáis este hilo en la típica guerra HTC Vive vs Oculus Rift y sed constructivos. Aquí se trata de intentar conseguir más información para descubrir el estado actual y de donde pueden venir la mejoras futuras. Esto ayudará a que más compañeros, como yo mismo, podamos tomar mejores decisiones de compra.
breaker19 » 8 MAR 2016 13:43
No tengo ni idea sobre Élite Dangerous pero: SteamVR y Oculus no tienen "drivers".. Los drivers son de la tarjeta grafica, nvidia o amd.
SteamVR no es que soporte ni deje de soportar el VR Sli/Crossfire, esto es una característica que proporcionan ambos Fabricantes (amd y nvidia) y los desarrolladores son quienes tienen que dar un buen soporte multigpu a sus juegos, si no lo hacen no te vale de nada tener más de una gpu pero hoy en día cualquier triple A soporta configuraciones duales, otra cosa son los indies..
Neoskynet » 8 MAR 2016 14:00
breaker19 No tengo ni idea sobre Élite Dangerous pero: SteamVR y Oculus no tienen "drivers".. Los drivers son de la tarjeta grafica, nvidia o amd.
Sí, cuando lo estaba escribiendo también lo estaba pensando, pero ¿qué palabra podríamos utilizar en vez de "drivers"? ¿Tal vez middleware, librerías, SDK, Runtime o Service?
Es que la funcionalidad se asemeja a la de unos drivers porque necesitas instalarlos para que el dispositivo se comunique con el sistema operativo y además aparece reconocido en el listado de administrador de dispositivos de Windows, tal y como lo haría un joystick o cualquier otro componente que utilice drivers (ya sea proporcionados por el fabricante o reconocidos directamente por Windows).
De todas formas ni siquiera Oculus les llama drivers y se refiere a ellos como SDK y Runtime.
Esto lo preguntaba porque creo que he leido por algún sitio que SteamVR rompía la compatibilidad con SLI, pero que en algún momento de su desarrollo la permitirán. Pero te lo digo de memoria.
Lo anterior lo preguntaba porque da la sensación de que SteamVR cada vez irá más integrado/solapado con los drívers de lar tarjetas gráficas. Sin ir más lejos Los "drivers" de Oculus hacen cosas parecidas a las mejoras que están haciendo los drivers de Nvidia, como Timewarp y creo que alguna otra. O tal vez en algún momento se des-solapen y cada uno haga lo suyo, que es lo que más sentido tendría.
Pero vaya, lo pregunto para informarme y entenderlo, no porque lo sepa. A ver si alguien domina del tema y nos lo explica.
Fguillotine » 8 MAR 2016 14:26
en el caso concreto de Oculus sí que hay un Display driver que se instala con la runtime, al menos hasta la 0.8. No se si cambiará con la runtime 1.0.
En la diferencia de rendimiento coincido bastante con Neosky. En los casos de juegos más o menos exigentes como Elite Dangerous la diferencia de rendimiento es abismal con uno y otro SDK.
Otro ejemplo de lo mismo es World of Diving, que después de las últimas versiones se puede jugar perfectamente con casi todos los efectos al máximo con una 970 y en la versión de SteamVR a parte de tener un rendimiento más bajo, se puede ver claramente como se reduce el nivel de detalle del terreno a muy pocos metros de nuestra vista y de una forma muy fea utilizando los mismos settings que con el SDK de Oculus.
No se si puede ser también por alguna limitación del DK2. En cualquier caso espero que vaya mejorando el rendimiento.
omg » 8 MAR 2016 14:27
Y x curiosidad a q se referian con lo de "modo directo al driver" cuando pasamos de escritorio extendido a directo. Tengo un carajal ya......
SdReNe » 8 MAR 2016 14:48
El problema de SteamVR es la falta del Asynchronous Timewarp, que es un salvavidas sobre todo con una GTX 970. Me consta que Valve tiene un sistema en su motor source 2 que ajusta la calidad instantáneamente para que los frames se mantengan constantes. Se habló de que igual hacían que este sistema funcionase en Unity pero todavía no hay nada claro. Desde luego si solo va en source 2, a pesar de ser una buena solución tardará en haber juegos que la aprovechen, y mientras tanto el Async timewarp será la mejor opción
_C__ » 8 MAR 2016 15:28
Neoskynet, has planteado las mismas dudas que tengo yo al respecto y que por desgracia para los que vamos a adquirir las gafas ahora, hastan que no estén en la calle ambos visores y corriendo el mismo juego demo no saldremos de dudas.
Lo del rendimiento lo veo muy, muy importante.
Usuario eliminado (608) » 8 MAR 2016 15:32
Eso significa que los juegos que utilicen SteamVR van peor que las que utilicen los SDK de Oculus?, es decir, los juegos que sean compatibles con ambos visores rendirán peor en los Vive?.
omg » 8 MAR 2016 15:58
» Respuesta a Usuario eliminado (608)
Yo creo q de momento si pero es demasiado pronto. Estamos en beta aun, q se nos olvida. Aun asi creo q segun lleguen ambos visores tendra mejor rendimiento oculus con su sdk pero las tornas se pueden igualar o incluso cambiar en cualquier momento, a nivel hardware son calcos, y el sdk de ambos seguira vivo durante mucho tiempo.
Yo no me decantaria x uno u otro visor por el rendimiento de sus sdks actuales.
_C__ » 8 MAR 2016 16:04
Eso no significa nada, porque los que estamos hablando son suposiciones, ya que prácticamente no hay ejemplos. Repito, que hasta que no estén en la calle y se puedan usar ambos visores con un mismo juego o experiencia no se podrá hacer un juicio correcto del rendimiento.
Otro juego que tiene por ahora doble compatibilidad con VIVE y Rift es LIVE FOR SPEED, ¿alguien ha podido leer algo al respecto sobre él?
www.reddit.com/r/oculus/comments/3vshrm/live_for_speed_now_supports_htc_vive_as_well_as/
Aquí hablan de la compatibilidad con VIVE y no dicen nada sobre el rendimiento. Entiendo que para los que lo han probado y tenían los dos visores no habrá supuesto diferencia. También es verdad que este juego no es exigente al tener sus añitos.
SdReNe » 8 MAR 2016 17:32
El Live for Speed no sirve para esto, ese va a cientos de fps en cualquier PC de los ultimos 5 años
imho » 8 MAR 2016 18:04
Pues yo simplemente creo que SteamVR esta siendo creado totalmente pensando ya en los visores comerciales,y no para el dk2,aunque de momento se mantengan cojidas con alfileres algunas compatibilidades en dk2,y que al compararlas con software de Oculus,esa "mejora de rendimiento" no es mas que el Asynchronous Timewarp que esta trabajando este momento con el dk2.
La cosa está,en que yo no creo en absoluto que Valve sea idiota y no sepa eso ni mucho menos,sino que o bien tienen algo igual o mejor por implementar,o no me extrañaria ni lo mas mínimo,que los propios controladores de Nvidia y Amd comiencen a hacer estas funciones a corto plazo,tal y como algunos desarrolladores ya han comenzado a preveer.
De momento no sabemos nada oficial,y posiblemente no lo sepamos hasta que los visores y el software esten funcionando en la calle.
YenG » 8 MAR 2016 18:16
Como desarrollador no entiendo muy bien este post, aunque entiendo la pregunta y es muy buena para que lo podamos explicar mejor. Me explico.
Yo uso UE4 para diseñar las experiencias. Dicho motor es, como dice el nombre, el motor del videojuego.
El que consume gasolina es el motor, no el parabrisas.
El UE4 claramente consume más para visores HMD que para monitor, porque hay que renderizad a mucha mayor resolución y por mantener los 90hz. El timewarp a mí solo me salta con las caídas de frames. Pero yo ya me encargo de que no hayan caídas optimizando el juego.
Dicho de otro modo, los SDK no consumen GPU, consumen CPU para calcular el tracking. Pero por ahora el consumo es tan nimio que ni lo he notado.
Dicho de otro modo: Hay diferencia entre SteamVR y Oculus SDK? A nivel de CPU seguramente, aunque no podría decir ahora mismo cual consume más.
Afecta eso a la GPU? Para nada. Ni por asomo.
Los drivers de AMD o Nvidia sirven de algo? Pues si, y de una forma brutal pueden llegar hasta triplicar la tasa de frames. Pero eso tb es interno al motor del juego y los drivers gráficos, el SDK no le importa ni se mete. Es el gameworks por ejemplo quién corta el bacalao.
Notaré entonces cambio si uso un SDK u otro? Pues si el desarrollador es muy noob, y tiene cuello de botella entre la CPU y la GPU pues si, pero vais a notarlo ya sea por SDK o versión de CPU o porque habéis dejado abierto el antivirus de fondo.
Y para rizar el ejemplo del motor y la gasolina, tenemos que tener en cuenta que el motor es quien consume gasolina (tasa de frames) pero el parabrisas no consume gasolina (el HMD y su SDK). Peeeero, un coche con un parabrisas más aerodinámico sí que consumiría menos. Pero no es el caso aún. Ese sería el caso de la PSVR por ejemplo que renderiza a 1080p, mucho menos de lo que requiere el PC.
Concluyendo. El SDK no pincha ni corta en la tasa de frames en este momento para PC.
Fguillotine » 8 MAR 2016 18:29
en ninguno de los casos que se han comentado está activado el async timewarp. En el caso de Elite Dangerous si no recuerdo mal sigue funcionando con el SDK 0.5 de Oculus, en el que ni siquiera estaba implementado. En World of Diving no estoy seguro de la versión del SDK con que está compilado (funciona con la 0.8), pero tampoco está activado, que se nota bastante.
Vamos, las diferencias de rendimiento, sea por la razón que sea son bastante evidentes.
_C__ » 8 MAR 2016 18:33
Y desde mi ignorancia, ¿a que puede ser debido la pérdida de rendimiento en ELITE al usar un sdk u otro?
Neoskynet » 8 MAR 2016 18:44
Es muy interesante lo que explicas y tiene sentido. Aún así creo que hay algo que se nos escapa porque, si no recuerdo mal, las diferentes versiones del SDK de Oculus hacían que los juegos fueran mejor, y la CPU no hacía cuello de botella. Sin embargo donde nunca he notado mejoras ha sido al actualizar los drivers de Nvidia, que justamente son los que deberían proporcionar más rendimiento con todo lo que están añadiendo para RV.
Pero reconozco que tampoco he hecho pruebas sistemáticas y puede deberse a multitud de factores. Seguramente el que más peso tiene es cómo está desarrollado el propio juego/demo, y cualquier optimización hace que mejore un montón.
Al menos el Elite Dangerous la diferencia de rendimiento es muy grande entre el SDK 0.6.0 de Oculus y SteamVR. Es de ir casi todo en Ultra a tener que ir todo a Low. Ese es el principal motivo de este post.
Sin duda que todo esto lo mejorarán, por la cuenta que les trae, pero vaya, que en esta primera generación vamos a ser unos auténticos conejillos de indias y además pagando (y me incluyo).
YenG » 8 MAR 2016 18:48
Los SDK se comunican con el motor y activan características especiales en este. Generalmente uno de los trucos que tenemos los desarrolladores es jugar con el escalado de la resolución que luego se reescala para el visor. Es muy probable que se cambie ese valor entre un SDK y el siguiente, pero básicamente la culpa no es del SDK si no de la información que este pasa al motor.
Básicamente, para que nos entendamos, es como poner el juego en Alta calidad o en Media calidad. Son muchos factores a tener en cuenta, pero realmente el SDK por si solo no puede afectar al rendimiento del renderizado del juego. Aunque ciertamente puede afectar de forma indirecta como el ejemplo que he puesto del motor y el parabrisas.
Concluyendo, lo que nos importa a nosotros es... habrá diferencias entre un SDK y otro? No, porque el motor se adecuará a las cualidades óptimas de cada SDK para funcionar al 100%. Otra cosa muy distinta es el tema del timewarp, que realmente es un gran invento, pero que a fin de cuentas solo funciona en situaciones muy específicas para que no haya un "dropframe" una bajada de frames. Pero vaya, que no es un milagro, no significa que con 30 fps lo veamos a 120fps en el visor. Significa que si tenemos una tasa estable de 90, pero en algún punto esta tasa baja a 86, el sistema haga un timewarp creando 3 fotogramas más.
El hecho de que SteamVR no tenga un timewarp no lo entiendo la verdad, porque no es para nada la panacea. De por si es algo que tenemos todo el mundo en nuestros televisores, cuando nos pone el movimiento fluido de las películas. Llevamos años conviviendo con el timewarp. Pero tiene un fallo... generar timewarp consume CPU (claramente no es magia). Es decir, por decirlo de otra forma se compensa la caída de GPU generando una caída de CPU, pero si la caída de CPU fuera demasiado grande entonces la caída de GPU sería descomunal. Vaya... que es más limitado de lo que creemos.
Concluyendo: Timewarp mola, pero no es magia. Los SDK finales no van a cambiar el rendimiento de las aplicaciones. Si no tenemos timewarp no nos vamos a morir, solo que si el juego está mal hecho a veces nos dará un latigazo (aunque ni nos daremos cuenta de la bajada de frames, solamente notaremos algo raro). Pero vaya, que vuelvo a repetir que son los desarrolladores quien deberían de acostumbrarse a mantener una tasa de 90fps si o si... yo me tiro horas y horas dando vueltas por mis niveles, y si veo que baja 1 solo fotograma por debajo de 90 me vuelvo loco hasta encontrar que coño es... ya sea una luz mal puesta, o un clavo con demasiados polígonos xD.
Neoskynet » 8 MAR 2016 18:55
¿Las demos de Vive, como la ballena y el resto, que estarán disponibles en Steam, también funcionarán en el Oculus Rift CV1 y DK2?
Lo digo porque si funcionan por SteamVR, como da compatibilidad tambien a otros visores, pues también deberían funcionar, ¿no?
YenG » 8 MAR 2016 18:59
Sinceramente no he probado el Elite, pero por lo que me cuentas creo que podría ser lo que te comento. Nosotros en UE4 tenemos por ejemplo un comando que se llama HMD SP. Este cambia la resolución con la que se envía el juego al visor.
Si tenemos HMD SP a 100 pues manda 2100x1200 o 1080p al DK2. Si ponemos HMD SP 200 pues manda 2160p. Por lo que he visto por encima hay gente que dice que por defecto es 160 y otros dicen que por defecto es 135. Me hace pensar, aunque quizás no es el caso, que a lo mejor cada SDK establece la resolución de envío del render a diferente tamaño.
Yo suelo usar 120-130, el propio diseñador lo cambia. Otra opción es la programación. Yo tengo una programación que establece que si se juega en monitor la resolución sea X, y si se usa el SDK la resolución sea Y. A lo mejor el diseñador del juego estableció que si se usa el SDK 0.6 debe de ser 120... pero se le olvidó hacer que el juego leyera que se usa SteamVR, y entonces cuando se usa este pone que la señal se envíe a 160% de su resolución original.
Por todo lo que comentáis creo que es la opción más factible. Además que Elite Dangerous usa su propio motor, por lo que es más posible aún que tengan que especificar el funcionamiento del engine con cada SDK.
Daros cuenta que es un juego que funciona en monitor y el HMD. Por lo que he visto por encima en los foros el problema es lo que digo. Que el juego no reconoce estar usando bien el SteamVR y le pasa una resolución y hz incorrectos, provocando una caída de fotogramas brutal. Pero según parece tienen conciencia del problema y lo van a solucionar rápidamente.
imho » 8 MAR 2016 19:05
Si señor,cierto eso,y a mi se me ha pasado ese detalle.Si la comparacion es con versiones compiladas con runtimes donde no trabaje el Asynchronous,es imposible que sea eso.
altair28 Pedazo HenryCO VR_Guybrush hikoreko_d sellocpr meloncillo46 6 Anónimo
39 Facebook adquiere a la desarrolladora de Asgard’s Wrath	Hace 10 minutos
5 Welcome Home. Nuevo título de terror para Quest	Hace 16 minutos
1 Microsoft no se da por vencido con su Windows RV	Hace 31 minutos
0 El juego de RV Do Not Open es uno de los elegidos para PlayStation Games Camp
2 Desarrollo de software	Hace una hora
41 The Walking Dead: Saints & Sinners - The Walking Dead: Saints & Sinners - ANÁLISIS	Hace 15 horas
40 HTC anuncia nuevos modelos de Vive Cosmos: Elite, XR y Play	Hace 17 horas
20 Virtual Pixels Temporada 02 Capítulo 07. El estado de la VR	Hace 9 horas

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución