EDICIóN GENERAL
PatatasTraigo

PatatasTraigo

Uso GNU con Linux (www.gnu.org). |softlibre, |GNU, |GNU_LInux. ieeexplore.ieee.org/document/4021370

En menéame desde marzo de 2017

12,87 Karma
292 Ranking
433 Enviadas
41 Publicadas
11K Comentarios
2.222 Notas
  1. @PatatasTraigo Ajá, así que es eso lo que te gusta, ¿eh? No te juzgo, cada uno con sus parafilias :hug:
  2. @PatatasTraigo
    No entiendo tu negativo en www.meneame.net/story/hiperactividad-infantil-perfil-nino-hiperactivo-.
    No te lo voy a devolver, por ilógico, y porque tengo buen concepto de ti.
    Si fueras tan amable, me gustaría saber las razones que te han llevado a ello.

    Realmente tengo curiosidad, asias! :-P
  3. @PatatasTraigo radeon.gartsize=128 y migration heuristic a greedy = mejora substancial, pero le queda un pelin de rendimiento.
  4. @PatatasTraigo Eh, olvidé una cosa. Wine con GalliumNine puede ser interesante en esta chatarra.
  5. @PatatasTraigo Si, bueno, pero el que se come un uso elevado de CPU soy yo, no el commiter. A ver si sale ya Slackware 15 y esto deja de ser noticia. Sí, puedo usar current, pero la stable me da mantenimiento casi cero.
  6. @PatatasTraigo Hay soporte pero hasta la versión 18 no hay capacidades reales e integración con radeonsi para un rendimiento aceptable.
    El soporte gl 2.1 en MESA 13 no sirve ni para el ioquake3, y si me tira el Flare (voy a probar ) sin ser una presentación de Impress puedo darme con un canto en los dientes.
    Se que GLAMOR en 2D es lento, pero ni con EXA parece ir rápido. Me queda por probar radeon.gartsize a 128, igual consigo un milagro.
  7. @PatatasTraigo me diste la turra bastante con desactivar KMS, sabia que los tiros no iban por ahi.
    Con llvm 8 (sin libs shared) y mesa 13 tengo una mejor aceleración, pero lejos de mesa 20 en -current.
  8. @PatatasTraigo nomodeset en LILO no hizo nada, el tema es intentar recompilar d/llvm en Slackware para que compile librerias compartidas y recompilar MESA, o bien probar con radeon.modeset=0.
  9. @H_is_back @PatatasTraigo @yomisma123 sí, trabajan con vidrios reciclados y terrazos. Son estos: huguetmallorca.com/products/
  10. @PatatasTraigo

    Cachis. Otro día será. :-P
  11. Yo pensaba que @PatatasTraigo era un clon de @anthk :-|
  12. @PatatasTraigo Oye, si quieres preguntamos en alt.os.linux.slackware y salimos de dudas. Posteo un arranque bajo slackwarw 14.2 con MESA 11 con su xorg.log y su dmesg en el post y que contesten. Y posteo aqui la respuesta, ok? Si quieres actualizo llvm de la 3.8 a la extra/llvm de 8.0 y recompilo x/mesa a la version 13.0.6 para mejor soporte.

    Porque solo, solo no estoy: www.google.com/search?q=rs690+llvmpipe+
  13. @PatatasTraigo En el link que me has dado solo han anyadido el ID PCI, y detalles basicos sobre como es el chipset que tiene que ver como "soporte" lo de anyadir el ID usb de cualquier chinocacharro en OpenBSD: 0. Sabra que ha sido detectado por hotplugd(4) y ya para anyadir eventos y para el dmesg, pero no para manejarlo.
    Por que vamos, se supone que teniendo el driver radeon y los permisos en OpenBSD activados (en OpenBSD no hay modulos, el modulo KMS se carga si o si siempre al detectarse), no deberia saltar el driver llvmpipe bajo MESA ni siendo especificado en radeon.conf segun la seccion del driver de X al detectarlo. Que vengo de tiempos de xfree86, que no me asusta ya nada. Asi que bueno, que digan lo que quieran del "soporte" que el mundo real es otro.
  14. @PatatasTraigo Yo no he tocado nada. Cuando le pasa lo mismo a los de OpenBSD y Slackware, igual el problema es de falta de soporte, no nuestro. Como digo, en Slackware 14.2 no tiraba con mi version de MESA. Con radeon.conf sin tocar, es decir, cargando Radeon bajo demanda. Para que me equivoque tendre que haber tocado algo :shit:

    PD: en el dmesg y xorg.log del Xenocara de OpenBSD tampoco tenia soporte, asi que hace falta bastante mas que el ID de MESA para mi chipset integrado. Un saludo.

    Ah, en OpenBSD probe hasta forzando el aperture, tras tocar los permisos rw a lo bestia para que accediese a /dev/dri* y /dev/drm* ya en caso extremo. Nada, ni a hostias se hablaba con radeon(4). Pues eso.
  15. @PatatasTraigo mira a ver si no se seca y la tienes que recoger mañana :-S
  16. @PatatasTraigo En xorg.conf los drivers de Radeon estan configurados y se cargan xorg.conf.d.
    Sin embargo no es el driver radeon el utilizado por MESA, si no llvmpipe, pese a que los dispositivos tenian sus pemisos de lectura y escritura correctamente, el usuario en el grupo video, y en Linux el modeset no solo ya activado, si no forzado en el arranque por si acaso.

    MESA puede soportar como ID lo que sea, pero que funcione con los drivers para la grafica es otra cosa.

    Tambien tengo IDs para segun que dispositivos segun el ID /USB en OpenBSD, pero son como identificativo; por ejemplo no asocia el driver u*(4) para ellos. Que se puede hacer, si, pero son un esqueleto.
  17. @PatatasTraigo Ya, si, claro, aprende a utilizar tus sistemas, por supueeeesto. Edito el SBo de Slack para que pille una version potable la menos intrusiva posible pero no se utilizar mis sistemas.
    Igual el que el soporte Radeon en integradas haya sido una mierda comparada con Intel con un equipo unos pocos anyos posterior no tiene nada que ver. Pues mira majo, hasta mesa 18 NO he tenido drivers para esa Radeon integrada. Y si dices que los hubo, mientes por que NO tuve aceleracion ni en Slackware ni en OpenBSD ni gaitas, puesto que tuve OpenBSD-current donde importaron MESA 17 (hablo de hace 2-3, 4 anyos a lo sumo) y aun asi NO tuve aceleracion 3D. Asi que eso de que tuve suporte en MESA 7, sera para reconocer que la tarjeta existe, se puede lanzar un servidor X y MESA bajo sw y muchas gracias, por que de 3D o soporte radeon(4) NADA.

    Ahora vas y le dices a los de OpenBSD -stable, la 6.7, que mi tarjeta esta soportada con esa -release sin actualizar a -current para que pille un nuevo kernel, Xenocara y drivers de X en el proceso. Venga, corre.
  18. @PatatasTraigo A mi tus enlaces me importan tres cojones y si quieres posteo un DMESG aqui msimo con un Slackware Live 14.2 con los drivers de base y vas a ver donde acaba el soporte no ya de MESA 7, si no de MESA 11.

    GL_RENDERER = ATI RS690

    Ese es mi chipset. Bajo MESA 20. 20. Con Slackware 14.2 y MESA 13.0.6 actualizado NO tuve aceleracion 3D. Que vas, a hacer milagros en mi propio portatil? Pues lo llevas claro.

    EDIT: tuve los permisos bien de /dev/drm* y /dev/dri*, por si acaso. Tanto en Linux como en OpenBSD, ambas con el firmware cerrado instalado. fw_update en OpenBSD, e incluso la version 6.7. Que no soy manco si lo piensas. Edite hasta /etc/fbtab en OpenBSD y ni a hostias lo reconocia.

    Me acuerdo hasta de la config que puse:

    /dev/ttyC5 0660 /dev/drm0:/dev/drm1:/dev/drm2/dev/drm3:/dev/dri128:/dev/dri129:/dev/dri130:/dev/dri131

    porque muchas veces siempre tocaba por tema de aperture en OpenBSD que no queria darle demasiadas concesiones al driver.
  19. @PatatasTraigo No son problemas de configuracion, no habia driver hasta MESA 17.x o 18, punto pelota. Superior al menos a la compilable en la Slackware 14.2. No saques versiones donde no las habia. Un Mobile 4 series de 2010-11 tenia mejor soporte que un chipset de tiempos de Windows Vista y con varias MESA lanzadas. Es de risa.

    Como digo Slackware 14.2 con MESA 13.0.6 hacia que volasen los drivers de la Mobile 4 Series. Piensa lo que quieras pero en el ese portatil con la iGPU de intel NO tengo -current, solo dicha version con MESA ligeramente actualizada. Tu mismo.
« anterior1234547

menéame