Je rejoins un peu tout les trucs en rapport avec BSD, le pkgsrc, l'IRC ou encore les forums
NetBSD va avoir pas mal d'ajouts en particulier sur le support des GPU (ne comptez pas sur nVidia...)

Bon bah c'est mort pour Minecraft sur RPi2, je suis arrivé au bout de mes capacités et maintenant c'est à Mojang de changer les choses s'ils en ont l'envie Je m'explique, en commençant par le cheminement que j'ai suivi:

• Le client Minecraft est écrit en Java. A priori ça devrait tourner partout comme écrit sur la boîte de Java, en pratique dès que le code repose sur une bibliothèque un tant soit peu sophistiquée, le mythe s'effondre et on a le droit de tout recompiler si on sort du cadre x86 / amd64. Ici, c'est le cas avec LWJGL et OpenAL.
• Pour OpenAL c'est pas bien compliqué... un git clone, un cmake puis make et on n'en parle plus.
• Pour LWJGL... bordel de merde. Il faut déjà savoir que le RPi2 est équipé d'un VideoCore qui n'expose que l'API OpenGL ES (Embedded System), et pas directement d'OpenGL desktop. Donc! Il faut disposer des headers et .so qui vont bien (placés dans /opt/vc si tout est bien installé comme il faut), d'un JDK complet, de l'outil ant et encore d'autres headers (listés par ici http://rogerallen.github.io/jetson/2014/07/31/minecraft-on-jetson-tk1/ ) pour que la princesse daigne compiler en entier.
• Une fois ce bazar enfin compilé, on a le choix entre utiliser la version traditionnelle de LWJGL en suivant plus ou moins les indications du lien précédent, et utiliser la version "ES", elle aussi compilée dans la foulée. Great. Sauf que:
  • La version OpenGL Desktop rame comme un goret. Prévisible.
  • La version OpenGL ES provoque un plantage dès le chargement car évidemment les signatures de fonctions ne sont pas les mêmes, et le client n'y trouve plus son compte.

Je suis un peu déçu par ce deuxième point, quand on sait que Mojang a utilisé OpenGL ES pour la Pocket Edition de Minecraft. Je n'ai pas la sensation que les différences entre les deux soient énormissimes, surtout dans le cas de Minecraft qui repose lui-même sur une bibliothèque intermédiaire. La logique aurait voulu que le changement d'API graphique soit amorti par la bibliothèque.

On verra dans le futur du coup... j'hésite à envoyer un mail à Mojang en leur expliquant jusqu'où je suis allé, mais ils risquent de répondre qu'ils n'ont pas l'intention de supporter une nouvelle archi pour leur version PC.

T'es au courant que Minecraft appartient à Microsoft maintenant ?

Je suis au courant oui, mais je confondais un peu les deux (dans ma tête Minecraft avait racheté Mojang... après tout c'est encore Dinnerbone qui fait la comm autour du projet sur Twitter donc ça prête à confusion)

Hyrrenzer : ça dépend de la taille, souvent dans de l'embarqué t'as pas de ressources physiques et t'as pas besoin d'avoir un noyau complet, donc tu développes un mini os embarqué sur mesure selon la chip qui tourne dans le système. (un truc qui te permet de gérer des interruptions et le matos électronique suffit), si c'est plus gros oui là tu peux sortir directement un linux que tu reconfigures.

G_B : la base
Attends de compiler un truc en C pour de l'ARM.

Bah certains morceaux de LWJGL sont écrits en C justement.

Mais l'erreur que j'obtiens me laisse perplexe:
[...] liblwjgl.so: /opt/vc/lib/libEGL.so: undefined symbol: glPointSizePointerOES
Sauf que le fameux symbole non-défini semble bien présent dans le .so en question (bon j'ai vérifié qu'avec un gros grep dégueulasse ceci dit)... moi pas comprendre, de ce fait.

T'as choppé un toolchain ARM du coup pour cross-compiler ?

Sinon soit c'pas linké, soit y a un conflit / bordel de dépendance.

Je compile directement depuis le RPi en fait, c'est pas si lent que ça avec la nouvelle archi.

Pour libEGL.so, j'ai pioché le package libraspberrypi0 en armhf sur les dépôts de Collabora dédiés au rpi2... là dans le doute je vais remplacer ce merdier par la version fournie sur le GitHub officiel de la fondation Raspberry-Pi contenant les firmwares pour le hardfloat &cie.

Mais bon j'ai bien vérifié avec file, les .so fournis par le paquet de Collabora étaient bien compilés pour mon archi ils sont peut être salement périmés... genre un type qui change dans la signature de la méthode concernée peut être?
C'est pas très explicite comme erreur de linking je trouve, d'autant que la compil avait réussie (ça c'est le comble) avec -lEGL une fois /opt/vc/lib ajouté dans les options de linking.

Bah c'est surtout qu'à mon avis t'as qu'une erreur de symbole affichée là, mais en général dans ces cas-là t'en as toute une floppée derrière si t'as des bouts de codes qui viennent d'un peu partout et qui sont pas à la même version...

Je ne sais pas si c'est intéressant pour certains mais il semblerait que NetBSD, dans sa future version 7, sera capable de faire tourner Nouveau et donc de supporter les cartes nVidia. Je ne sais pas ce qu'il en est chez OpenBSD mais c'était un gros point noir. Cette mise à jour va enfin me permettre d'utiliser NetBSD sur mon laptop en principal

EDIT : Je pense que je ferais un sujet quand NetBSD 7 sera stable

kernel j'imagine oui, mais là l'usine à gaz Java censée charger les libs s'arrête à la première erreur venue donc je n'ai que cette dernière comme référence.
Bref ça clone ça clone, ça met 100 ans et j'ai pas dépassé les 3MB/s depuis le début (sur les 11 dont je dispose en descente)... il a du mal avec les gros dépôts par contre ce RPi

Quand Nouveau sera stable aussi peut-être.*

G_B : bon courage pour résoudre un problème de linkage dans un cas pareil.

Mieux vaut Nouveau qu'aucun pilote du tout en fait
Ça fait trop longtemps que j'attends de pouvoir utiliser NetBSD sur du nVidia parce que je n'ai que ça chez moi (sauf une tour mais c'est trop chiant une tour)

Le 01 juillet 2015 à 02:25:45 kernel[] a écrit :
Quand Nouveau sera stable aussi peut-être.*

G_B : bon courage pour résoudre un problème de linkage dans un cas pareil.

Franchement ça m'énerve ce genre de situations: j'ai la forte impression que LWJGL est faite pour assurer la portabilité du code entre OpenGL et OpenGL ES, mais je dois foirer un truc dans la compil ou je ne sais quoi, ça compile, ça linke (a priori), mais ça ne tourne pas.

En parlant de Nouveau, j'ai déjà discuté et plus ou moins travaillé avec un type de nVidia, et en gros la politique s'ouvre vers le développement du driver open-source Nouveau.
En particulier avec Tegra nVidia commence à bosser avec la communauté de devs pour porter le driver sur le nouveau SoC.
Je vous mets un lien de quelques slides sur ça
https://fosdem.org/2015/schedule/event/tegra/attachments/slides/692/export/events/attachments/tegra/slides/692/FOSDEM_2015.pdf
C'est surtout quelques discussions techniques mais ça donne un aperçu.

Problème est qu'au niveau software c'est assez relou la différence entre OpenGL et OpenGL ES et c'est juste la translation du fait qu'au niveau architectural t'es très limité par les GPU mobiles, donc c'est bourré d'optimisation pour les archis mobiles, rien que le langage de shader c'est pas le même.

https://www.raspberrypi.org/forums/viewtopic.php?p=485855

Ya de l'espoir, je tente ce fix crade... heureusement que c'est un système jetable parce que là il ne ressemblera plus à rien à la fin

Merci de l'info au sujet d'nVidia, s'ils se mettaient réellement à bosser sur du driver libre, ça changerait les choses

kernel[] j'ai finalement tiré ma dernière cartouche aujourd'hui, en faisant du linking statique avec GLESv2, mais rien à faire, là c'est clairement Minecraft qui plantait en pleurant parce qu'il n'avait pas trouvé de contexte OpenGL (et je me suis renseigné auprès d'habitués de LWJGL, elle dispose bien de bindings avec OpenGL et OpenGL ES mais elle ne fournit en aucun cas une couche d'abstraction entre les deux... donc c'est normal que Minecraft tente de taper dans du desktop malgré tout ).

Là j'ai testé le serveur vanilla tout à l'heure... Avec OpenJDK c'est une catastrophe (impossible de se connecter dessus sans le faire planter), avec le JRE d'Oracle ça tourne mieux (déjà, on peut jouer) mais la génération de chunks consomme beaucoup trop pour une utilisation en situation réelle. Une solution serait de pré-générer la map, mais jusqu'à présent tous les hacks que j'ai trouvés pour faire ça ne me plaisent absolument pas

Aller aussi loin pour minecraft , tu as tout mon respect

+ vous pensez que si j'installe openBSD sur un vieux PC de 2009 ayant 2GB ram et surtout chauffant à 95°C sous une debian custom je peux redescendre vers les 65°C ? Sachant que je souhaite juste installer VLC , leafpad , un lecteur pdf ( je connais qu'evince ) , Lynx et un gestionnaire de fenêtre lèger ( genre fluxbox ) dessus. J'aimerais bien sauver ce PC si possible