# media-libs/mesa con ati-drivers ¿se utiliza?

## papu

hola

se que x11-drivers/ati-drivers(VIDEO_CARDS="fglrx") activa el opengl y el opencl,  pero tengo la duda de si las  características del paquete media-libs/mesa funcionan aunque se activen  sólo cuando se instala  x11-drivers/xf86-video-ati (VIDEO_CARDS="radeon").

¿Tendría que configurar VIDEO_CARDS="fglrx radeon" para ello? ¿es esta configuración posible sin activar soporte radeon en el nucleo? 

¿de no ser necesario activar radeon en el nucleo, estaría usando mesa via software(cpu) junto con  ati-drivers?

no se si me he explicado  :Smile: 

```

# eselect mesa list

64bit i915 (Intel 915, 945)

64bit i965 (Intel 965, G/Q3x, G/Q4x)

64bit r300 (Radeon R300-R500)

64bit r600 (Radeon R600-R700, Evergreen, Northern Islands)

64bit sw (Software renderer)

  [1]   classic

  [2]   gallium *

32bit i915 (Intel 915, 945)

  [1]   classic

  [2]   gallium *

32bit i965 (Intel 965, G/Q3x, G/Q4x)

  [1]   classic *

32bit r300 (Radeon R300-R500)

  [1]   gallium *

32bit r600 (Radeon R600-R700, Evergreen, Northern Islands)

  [1]   gallium *

32bit sw (Software renderer)

  [1]   classic

  [2]   gallium *
```

```
# cat /etc/make.conf 

CFLAGS="-march=native -O2 -pipe"

CXXFLAGS="${CFLAGS}"

CHOST="x86_64-pc-linux-gnu"

MAKEOPS="-j5"

ALSA_CARDS="hda-intel"

ACCEPT_LICENSE="*"

ACCEPT_KEYWORDS="~amd64"

EMERGE_DEFAULT_OPTS="--autounmask-write=y --complete-graph=y --keep-going -v --with-bdeps=y"

FEATURES="${FEATURES} parallel-fetch nodoc noinfo candy"

PORTAGE_ELOG_CLASSES="warn log error"

PORTAGE_ELOG_SYSTEM="echo save"

INPUT_DEVICES="evdev"

LINGUAS="ca ca_ES"

USE="X avx c++0x cairo cdda cups dbus dvd icu jpeg jpeg2k kde lcms libnotify lzma nsplugin opengl policykit png pulseaudio qt3support

     qt4 sdl smp sqlite sse4_1 sse4_2 ssse3 svg truetype udev v4l -gnome -gtk -gtk3 -handbook -oss -semantic-desktop"

VIDEO_CARDS="fglrx"

source /var/lib/layman/make.conf
```

saludos, adéu.

----------

## i92guboj

Ni fglrx puede funcionar con la pila opengl de mesa, ni el driver libre radeon puede funcionar con el opengl de fglrx. Nada te impide tener los dos instalados, pero tendrar que andar cambiando tu xorg.conf, usando eselect para cambiar el opengl, y cargando y descargando módulos de kernel para que no haya conflictos.

Qué es exáctamente lo que intentas hacer?

----------

## papu

solo quiero saber si utilizando fglrx puedo usar las características de los USE de mesa a mismo tiempo de alguna forma.

lo decia por ejemplco: por las opciones egl, openvg...pero supongo que solo so accesibles  mediante drivers xf86-video-ati , con fglrx solo tengo soporte opengl y opencl y ya esta ¿no?

¿para aprovechar las USE de mesa es imprescindible compilar con  VIDEO_CARDS="fglrx radeon" y dar soporte radeon en el nucleo  y luego ir cambiando con eselect de uno a otro reiniciando cada vez?

¿porque  el sistema  necesita compilar soporte mesa si no vas a usar drivers binarios?

ad1

----------

## i92guboj

 *papu wrote:*   

> solo quiero saber si utilizando fglrx puedo usar las características de los USE de mesa a mismo tiempo de alguna forma.
> 
> lo decia por ejemplco: por las opciones egl, openvg...pero supongo que solo so accesibles  mediante drivers xf86-video-ati , con fglrx solo tengo soporte opengl y opencl y ya esta ¿no?
> 
> 

 

 Bueno, repito, las librerías opengl de fglrx no tienen que ver nada con las de mesa. No tienen las capacidades de las de mesa, ni viceversa, y lo que compiles en mesa deja de estar en funcionamiento desde el mismo momento que hayas usado "eselect opengl set <fglrx>". De la misma forna que cambiarle el motor a tu Porsche no hace que tu bicicleta corra más.

----------

## i92guboj

Precisamente porque no vas a usar binarios necesitas mesa. Los driver fglrx y nvidia tienen su propio opengl. Mesa es el opengl de los drivers de código abierto de xorg.

----------

## papu

 *i92guboj wrote:*   

> Precisamente porque no vas a usar binarios necesitas mesa. Los driver fglrx y nvidia tienen su propio opengl. Mesa es el opengl de los drivers de código abierto de xorg.

 

queda claro que no se pueden usar a la vez  y son diferntes , pero usando fglrx,  el cual tiene su propio opengl y opencl,  ¿incluye también soporte para  tecnologicas derivadas como son : openvg, egl, opengl es...?

yo uso actualmente sólo los binarios VIDEO_CARDS="fglrx" entonces ¿porque el sistema me pide compilar también los mesa? , eso es lo que no entiendo jejeje

Es decir ¿por el simple hecho que un paquete pida mesa se ha compilar aunque no se tenga soporte activo en tu sistema?

equery depends mesa 

```

 * These packages depend on mesa:

app-emulation/emul-linux-x86-opengl-20130224 (media-libs/mesa)

app-emulation/wine-1.5.28 (osmesa ? media-libs/mesa[osmesa])

dev-qt/qtgui-4.8.4-r1 (egl ? media-libs/mesa[egl])

kde-base/kwin-4.10.2 (opengl ? >=media-libs/mesa-7.10)

                     (gles ? >=media-libs/mesa-7.10[egl(+),gles])

                     (gles ? <media-libs/mesa-7.12[egl(+),gles])

                     (>=media-libs/mesa-7.12[egl(+),gles2])

virtual/glu-9.0 (<media-libs/mesa-9)

virtual/opengl-7.0 (media-libs/mesa)

www-client/firefox-20.0.1 (>=media-libs/mesa-7.10)

x11-base/xorg-server-1.13.3 (!minimal ? >=media-libs/mesa-8[nptl=])

x11-libs/cairo-1.12.14 (opengl ? media-libs/mesa[egl])

                       (openvg ? media-libs/mesa[openvg])

                       (gallium ? media-libs/mesa[gallium])

x11-libs/gtk+-3.6.3-r2 (wayland ? media-libs/mesa[egl?,wayland])
```

equery uses mesa

```

[ Legend : U - final flag setting for installation]

[        : I - package is installed with flag     ]

[ Colors : set, unset                             ]

 * Found these USE flags for media-libs/mesa-9.1:

 U I

 - - bindist             : Disable patent-encumbered ARB_texture_float, EXT_texture_shared_exponent, and

                           EXT_packed_float extensions.

 + + classic             : Build drivers based on the classic architecture.

 - - debug               : Enable extra debug codepaths, like asserts and extra output. If you want to

                           get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml

 + + egl                 : Enable EGL support.

 + + gallium             : Build drivers based on Gallium3D, the new architecture for 3D graphics

                           drivers.

 - - gbm                 : Enable the Graphics Buffer Manager for EGL on KMS.

 - - gles1               : Enable GLESv1 support.

 - - gles2               : Enable GLESv2 support.

 + + llvm                : Enable LLVM backend for Gallium3D.

 + + nptl                : Enable support for Native POSIX Threads Library, the new threading module

                           (requires linux-2.6 or better usually)

 - - openvg              : Enable the OpenVG 2D acceleration API for Gallium3D.

 - - osmesa              : Build the Mesa library for off-screen rendering.

 - - pax_kernel          : Enable if the user plans to run the package under a pax enabled hardened

                           kernel

 - - pic                 : disable optimized assembly code that is not PIC friendly

 + + shared-glapi        : Enable sharing of common code for the OpenGL API.

 - - vdpau               : Enable the VDPAU acceleration interface for the Gallium3D Video Layer.

 - - video_cards_i915    : VIDEO_CARDS setting to build driver for Intel i915 video cards

 - - video_cards_i965    : VIDEO_CARDS setting to build driver for Intel i965 video cards

 - - video_cards_intel   : VIDEO_CARDS setting to build driver for Intel video cards

 - - video_cards_nouveau : VIDEO_CARDS setting to build reverse-engineered driver for nvidia cards

 - - video_cards_r100    : VIDEO_CARDS setting to build only r100 based chips code for radeon

 - - video_cards_r200    : VIDEO_CARDS setting to build only r200 based chips code for radeon

 - - video_cards_r300    : VIDEO_CARDS setting to build only r300, r400 and r500 based chips code for

                           radeon

 - - video_cards_r600    : VIDEO_CARDS setting to build only r600, r700, Evergreen and Northern Islands

                           based chips code for radeon

 - - video_cards_radeon  : VIDEO_CARDS setting to build driver for ATI radeon video cards

 - - video_cards_vmware  : VIDEO_CARDS setting to build driver for vmware video cards

 - - wayland             : Enable support for dev-libs/wayland

 - - xa                  : Enable the XA (X Acceleration) API for Gallium3D.

 - - xorg                : Enable the Xorg state tracker for Gallium3D. This is not required for OpenGL

                           acceleration in X.

 - - xvmc                : Enable the XvMC acceleration interface for the Gallium3D Video Layer.
```

saludos, ad1

----------

## i92guboj

 *papu wrote:*   

>  *i92guboj wrote:*   Precisamente porque no vas a usar binarios necesitas mesa. Los driver fglrx y nvidia tienen su propio opengl. Mesa es el opengl de los drivers de código abierto de xorg. 
> 
> queda claro que no se pueden usar a la vez  y son diferntes , pero usando fglrx,  el cual tiene su propio opengl y opencl,  ¿incluye también soporte para  tecnologicas derivadas como son : openvg, egl, opengl es...?

 

La mejor fuente para encontrar esas respuestas son seguramente los readme del mismo paquete de fglrx, o quizás el sitio de ati/amd. Los drivers cerrados normalmente tardan bastante en implementar las últimas tecnologías en linux.

 *Quote:*   

> yo uso actualmente sólo los binarios VIDEO_CARDS="fglrx" entonces ¿porque el sistema me pide compilar también los mesa? , eso es lo que no entiendo jejeje
> 
> Es decir ¿por el simple hecho que un paquete pida mesa se ha compilar aunque no se tenga soporte activo en tu sistema?

 

OpenGL es una especificación, y, como tal, provee una interfaz estándar con una serie de comandos y funcionalidades que están bien definidos, y que son siempre los mismos. Seguramente los drivers propietarios usan las mismas cabeceras de mesa, por más que los detalles internos de implementación varíen de los drivers abiertos. No es mi campo de acción y no te lo puedo confirmar al 100% (habría que mirar el código fuente para eso) pero seguramente sea así.

----------

## papu

si tu no lo sabes bien imagina yo, amd da soporte opengl, (webgl), opencl( no se en que aplicaciones...) pero a partir  ahí ya me pierdo, buscar información sobre eso, es para mi pasar horas consultando sin saber que buscar exactamente y acabar mas liado aun, no me merece la pena, por eso pregunto aquí por si alguien tiene claro ese asunto y lo comparte de forma entendible.

supongo es porque confundo las tecnologias del kronos group y acabo metiendolas en el mismo saco que el opengl, son temas realmente demasiado tecnicos para mi, aunque intente entender lo justo para sentirme satisfecho. Cada vez salen mas nombrecitos OPENxx...

saludos, ad1

----------

## i92guboj

Yo tampoco llevo eso muy al día, ni siquiera sé cual es el estado actual de los aceleradores de decodificación de video como vdpau, xbmc y toda esa pesca.

Mis requisitos gráficos no son muy elevados y es un campo que no me interesa demasiado. Tuve que aprender opengl en la uni, pero quitando eso y algún trabajillo ocasional con el mismo, no es un campo del que me mantenga muy al día. Siento no poder proporcionar más info. Lo que sí que sé es que si quieres usar todas las capacidades del driver propietario necesitas también la pila opengl propietaria que viene con dicho driver (sea el que sea).

Las capacidades del driver homólogo mesa en cada caso no son usables en forma alguna con otro driver que no sea el abiero, ni viceversa. La situación de los driver gráficos en linux nunca fue óptima, pero hoy día, comparando con tiempos anteriores, gozamos de una relativa buena salud.   :Rolling Eyes: 

----------

## papu

los requisitos no es lo importante la cosa es que funcione bien el hardware que compras pero las "empresas" siguen discriminando según les conviene. De todas formas el soporte binario opengl de ATI actualmente esta años luz de lo que era y es incluso mejor que en windows(como también sería lógico esperar) , a ver si pasa lo mismo con el audio en el futuro, ya que es sin duda alguna desde mi punto de vista, la mayor limitación que "arrastra" linux/gnu a dia de hoy, para así poder disfrutar de un soporte multimedia óptimo, algo particularmente importante para mi.

En el caso que mencionas xbmc sin duda el caballo de batalla es ése mismo: el audio y también la mala implementación de soporte multimonitor, seguramente por temas inerentes al hdmi.

Yo con mi  arranque dual estoy contento  :Smile: 

Dejando de banda que una sea privada y otra libre, opengl y directx estan a la par en calidad ( aunque no tengo ni idea cual escogería un programador en igualdad de condiciones), microsoft no lo hace todo mal afortuandamente aunque a saber de quien es realmente el código de la api de directx...

saludos, ad1

----------

## Arctic

Desde hace años tienes soporte para aceleración de video por hardware con el driver propietario através de VAAPI, y desde hace meses lo tienes de UVD atraves de VDPAU y el opensource (necesitas kernel 3.9 o parchear el 3. :Cool:  también necesitas el ultimo firmware oficial modificado. El driver propietario de AMD en 3D es muy bueno ,donde no va tambien es en 2D  claramente lo supera el opensource .

Salu2

----------

## papu

he puesto los ati-drivers y los dejaré el 2d no es tan bueno como el opernsource pero lo prefiero asi, el 3d ha mejorado muchísimo desde lo que yo lo recordaba en los drivers binarios, ahora falta por ponerse a su altura el 2d, el vídeo y el sonido vía hdmi. Si eso ocurre solo usaré windows8 como videoconsola y cada vez juego menos.

saludos, ad1

----------

