Web Analytics
Conecta con nosotros

Noticias

John Carmack habla de los errores de optimización en drivers de NVIDIA y AMD

Publicado el
John Carmack habla de los errores de optimización en drivers de NVIDIA y AMD 29

El co-fundador de id Software ha comentado en el evento Oculus Connect que los expertos que se ocupan del desarrollo de los drivers de NVIDIA y AMD a menudo cometen errores que afectan a la optimización de los juegos, un problema que evidentemente tiene consecuencias en la experiencia que disfruta el usuario.

John Carmack ha enfocado el tema desde una perspectiva bastante sencilla y sin buscar la polémica, aunque ha aprovechado para hacer «méritos» diciendo que el puede hacerlo mejor:

«A menudo cometen errores. Déjame hacer las cosas específicas de bajo nivel (en referencia a la optimización), sé lo que estoy haciendo, me encargaré de ello, tú vas a tomar decisiones que no van a ser óptimas para mí».

Está claro que la potencia de una tarjeta gráfica importa, pero al final la optimización acaba jugando un papel clave en le rendimiento real que un componente es capaz de ofrecer. Podríamos poner muchos ejemplos pero nos basta con señalar dos recientes para que se entienda la idea; DOOM y Forza 7.

En ambos la optimización para APIs avanzadas (Vulkan y DirectX 12 respectivamente) permitió a las soluciones gráficas Radeon de AMD ofrecer un rendimiento superior al de otras alternativas de NVIDIA, que en teoría tenían una mayor potencia bruta.

Actualmente los drivers de NVIDIA y AMD son un elemento clave para disfrutar de una buena experiencia en juegos de última generación. Ambas compañías son conscientes del peso que tienen, y por ello liberan actualizaciones periódicas adaptadas y optimizadas para mejorar el rendimiento en los juegos más actuales.

Está claro que no es un trabajo fácil y que en este sentido la llegada de Raja Koduri hizo mucho bien a AMD pero en el fondo creo que John Carmack no ha enfocado del todo bien el problema.

La optimización no sólo depende de los drivers sino también del trabajo que hagan los desarrolladores, y en este sentido nos encontramos en una etapa bastante complicada por las pobres adaptaciones de consola que acaban llegando a compatibles en un estado muy flojo.

Más información: PCGamer.

Editor de la publicación on-line líder en audiencia dentro de la información tecnológica para profesionales. Al día de todas las tecnologías que pueden marcar tendencia en la industria.

13 comentarios
  • st.UART

    Claro, es mentira que los desarrolladores no optimicen los juegos, es cosa de los controladores… dijo el creador de Daikatana.

  • Gregorio Ros

    Una cosa hay que reconocer, la cooperación entre desarrolladores de drivers y de los creadores de los motores gráficos sería muy interesante para nosotros, los usuarios. Me recuerda a un artículo que analizaba el caso del exito de Half Life, Valve introdujo en cada uno de sus equipos (programadores, diseñadores graficos, guionistas, etc.) a un componente de los otros equipos, así logro una optima comunicación entre ellos y evito el estar perdiendo el tiempo diseñando escenas que no era posible programar adecuadamente, perder el tiempo en efectos gráficos que no se usarían,etc. Una pena, pero no recuerdo que artículo fue.
    Saludos.

  • Eduardo Medina

    ¿Es un off topic? Daikatana es de John Romero.

  • st.UART

    Cierto, fallo mio.

  • iso9660

    Yo creo que no es lo mismo desarrollar un driver para un sistema operativo como osx, Windows o Linux, que para el sistema de una consola. Los sistemas operativos necesitan guardar el estado del sistema y acumular métricas y demás, cosas que son innecesarias en consolas.
    Estoy seguro de que Carmack es un crack programando, pero en este asunto se le ha llenado la boca, y si tan fácil es en lugar de abrir la bocaza bien podría optimizar drivers en Linux, que para eso son de código abierto, tanto los de Intel, como los de AMD.

  • Gregorio Ros

    Pues no se que decirte, recuerdo hace unos pocos años, cuando Steam decidio apostar por SteamOS, que, como los drivers de ciertas tarjetas eran una castaña pilonga, se programo unos propios dandole un zasca en todos los morros a los propietarios. Algo de programación de drivers sabran los desarrolladores de juegos cuando se estan peleando todos los días con ellos.
    Yo creo que es posible que los que programan los drivers no sepan que es lo que necesitan, o van a usar realmente, los desarrolladores de juegos. Igual estan perdiendo el tiempo en funciones que apenas se van a usar y dejan de lado las que realmente importan.
    Un saludo.

  • Cagarruto

    John Carmack, como programador de motores de juego que es (y muy bueno), entiende perfectamente el problema, y ha enfocado perfectamente el problema. Lo que es pasa es que el redactor no ha terminado de pillar del todo bien el mismo, ya que por como ha escrito el artículo me da que ha (mal)interpretado lo que ha dicho como una crítica a la labor de los desarrolladores de drivers y que él podría hacer unos drivers mejores.

    Lo que Carmack está diciendo no es eso, sino que la razón de los problemas de optimización de juegos en los drivers es que no tendría que existir esa optimización en los drivers en primer lugar: la optimización del software es cosa del software, no del hardware (ni de sus drivers, que no son -o deberían ser- más que la capa de acceso a este). Un desarrollador de software SIEMPRE va a poder tomar mejores decisiones de optimización para ese software que cualquier cosa que esté corriendo por debajo del mismo.

    Unos drivers necesitan, obviamente, una interfaz común, estandarizada, a través de la que acceder. Pero esta debería de modelar el hardware y el acceso de bajo nivel al mismo. Lo que hasta la fecha ha venido utilizándose para esto ha sido OpenGL y MS OpenGL (perdón, DX), cuyos orígenes preceden al hardware especializado de renderización 3D en tiempo real y que no es eso, sino una librería gráfica, que modela conceptos de programación gráfica (no el hardware).

    Esto deja un vacío entre hardware e implementación de los conceptos de representación gráfica que modelaban OpenGL/DX, donde se pierden buena parte de las posibilidades de optimización, y que queda a merced de los desarrolladores de los drivers, que tienen que elegir entre hacer ellos optimizaciones específicas para todos y cada uno de los programas DENTRO de los propios drivers (responsabilidad descomunal, y absurda, para un equipo de desarrollo de drivers por grande que sea, e imposible de completar al 100%), o simplemente, hacer una cosa común para todos y que no sea óptima para ninguno (cosa que no hacen por competencia con sus rivales).

    Afortunadamente, por fin y tras muchos años de lucha por parte de ciertas facciones, este sinsentido es lo que vienen a intentar reparar Vulkan y DX12, modeladas sobre el prototipo propuesto por AMD (Mantle), que SÍ ES una interfaz para hardware gráfico, y POR ESO (y no por un mejor trabajo de AMD en sus drivers para estas APIs) es por lo que con Vulkan y DX12 se están viendo mejoras en este sentido, particularmente en la parte de AMD, que es la que tenía menos dinero para, básicamente, reprogramar uno por uno todos los juegos a nivel de drivers, que es lo que tocaba hacer con OpenGL y los DX anteriores al 12…

  • Los de Intel si, los de AMD no, aunque existen libres no oficiales para AMD y NVIDIA.

    Y GNU / Linux en juegos, a pesar del esfuerzo de Steam sigue siendo irrelevante.

    Y yo uso GNU/Linux – ahora Manjaro – como sistema preferente e escritorio ya lustros

  • Eso lo soñaste, simplemente pidió poder colaborar con los propietarios, con acuerdos especiales de confidencialidad, y ambos NVIDIA y AMD salieron beneficiados en GNU/Linux y en MS WOS.

  • Cagarruto

    A Carmack no se le ha llenado la boca de nada, y no ha dicho nada revolucionario ni que no tengamos meridianamente claro todos los que nos dedicamos a esto: los drivers de dispositivos gráficos están plagados de deficiencias de optimización (eso es un hecho), y el motivo de que esto sea así es porque los drivers no tendrían que hacer esta optimización en primer lugar.

    Como dice Carmack, él, es decir, un desarrollador de SW, siempre va a poder hacer un mejor trabajo de optimización para ese SW que cualquier cosa que corra por debajo del mismo. Un driver tendría que ser una capa de acceso al hardware, que modelase el propio hardware y vías de interacción con el mismo, NADA MÁS. Y aquí no cabe optimización alguna para software específico, no tiene sentido…

    Por eso pide acceso a bajo nivel al hardware para los desarrolladores como una solución al problema. Y exactamente eso es lo que vienen a intentar cambiar Vulkan y DX12 (aunque aún no al 100%), esa es la razón de su existencia. Por eso se ha empezado a ver un progreso en este sentido con esas APIs, y por eso ese avance se ha visto sobre todo en AMD, que es la que menos recursos tenía para hacer la salvajada de hacer una versión del driver optimizada para cada juego/programa (cosa que insisto, un driver NUNCA tendría que hacer, deja la optimización de cada programa, para cada programa).

  • Cagarruto

    A modo de clarificación… cuando Carmack dice:

    “A menudo cometen errores. Déjame hacer las cosas específicas de bajo nivel (en referencia a la optimización), sé lo que estoy haciendo, me encargaré de ello, tú vas a tomar decisiones que no van a ser óptimas para mí”.

    No está diciendo que le deberían dejar a él hacer los drivers porque él los haría mejor que los responsables de Nvidia, AMD e Intel, que es lo que parece que mucha gente está interpretando.

    Está diciendo que los drivers deberían permitir el acceso al hardware de forma directa, a bajo nivel, dejando a los desarrolladores encargarse del manejo del mismo desde la base, su optimización, corrección de uso, etcétera, porque un desarrollador de un SW, siempre va a poder tomar decisiones mejores para ese SW específico que los que hacen los drivers…

    O sea, lo que pretenden ir acercando API’s como Vulkan y DX12…

  • javron

    todos sse quieren lavar las manos

  • alxSoft

    Fanfarrón..

Lo más leído