×Закрыть

Проблема с java, matlab, opengl

Всем привет.

Вернулся я значит из отпуска, накатил обновления пакетов в линухе, что накопились и ... стал ловить следующую лажу в матлабе:

com.jogamp.opengl.GLException: X11GLXDrawableFactory - Could not initialize shared resources for X11GraphicsDevice[type .x11, connection :0.0, unitID 0, handle 0x0, owner false, ResourceToolkitLock[obj 0x7f8070c6, isOwner false, <496c188f, 57c079f1>[count 0, qsz 0, owner <NULL>]]]
	at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:326)
	at jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:297)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
	at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:688)
	at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:580)
	at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:297)
	... 2 more
>> opengl info
MATLAB has experienced a low-level graphics error, and may not have drawn correctly.
Read about what you can do to prevent this issue at Resolving Low-Level Graphics Issues then restart MATLAB.
To share details of this issue with MathWorks technical support,
please include this file with your service request.
                          Version: ''
                           Vendor: ''
                         Renderer: 'None'
            RendererDriverVersion: ''
        RendererDriverReleaseDate: ''
                   MaxTextureSize: 0
                           Visual: ''
                         Software: 1
             HardwareSupportLevel: 'none'
        SupportsGraphicsSmoothing: 0
    SupportsDepthPeelTransparency: 0
       SupportsAlignVertexCenters: 0
                       Extensions: {}
               MaxFrameBufferSize: 0

Месяц назад всё было нормально и работало.

И использую дрова для радеона отсюда ppa.launchpad.net/...​f/graphics-drivers/ubuntu xenial main.

Эта проблема и с open-jdk и с jdk, что тянет матлаб с собой.

Как починить?

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А в самій системі нормально з опенгл? glxinfo |grep profile
що каже?

viktor@VIK-MINT18 ~ $ glxinfo |grep profile
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
    GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
    GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.0-devel
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.0-devel

Серьёзно? Что это за дистрибутив зюзикса, который беты пихает в обновления? Поставил бы ты Ubuntu LTS и обновлял её раз в пол года, так ещё жить можно. Хотя эти петрушки умудрялись даже в LTS поломать NFS и SMB по разу в 2016 году, я решил вообще обновлять раз в год, под Новый Год, если что накосячат, то за праздники исправят и меня оно по работе никак не коснётся, что из-за обновления я не смогу свою работу делать.

И использую дрова для радеона отсюда ppa.launchpad.net/...​f/graphics-drivers/ubuntu xenial main.

спробуйте в скріпт запуску матлабу добавити
export LD_PRELOAD=/usr/lib/libstdc++.so
export LD_LIBRARY_PATH=/usr/lib/xorg/modules/dri/

щоб системні використовувало

Это не сработало.

а той матлаб тільки на комплектній з ним яві працює — чи можна системну оракловську чи опен встановити і на ній пускати?

Могу переключать на open-jdk и на то, что с ним в поставке. OpenGL и с тем и с дургим одинаково не работает.

завжди можна вернутись до стандартних драйверів
sudo ppa-purge ppa:oibaf/graphics-drivers

Попробовал, но что-то ничего не изменилось, только куча приложений снеслась.
И VLC не ставился, пока этот ppa не вернул и не обновил всё.

щось дивно.... ви не відключали вручну стандартних репок? Бо ця команда просто зносить репку oibaf і заміняє її пакети з стандартних реп.

Дивно не дивно, а эта комнада снесла кучу пакетов. Никаких стандартных не отключал вообще.

Поставь убунту лтс из коробки и не обновляй её. Либо для полного комплекта купи ещё гамак, лыжи и противогаз и глаза нужно закапывать лимонным соком до натуральной вампирской красноты. Делай выбор мудро :)

та обновляти можна — просто зовнішні ппа підключати то вже потрібне тестування і в випадках проблем відмова від ппа

до речі, ядро в системі ви під драйвера також піднімаєте? чи на 4.4* ? Просто нові можливості в драйверах зав’язані на нові ядра(4.10 і >) і нову версію LLVM (4 i >) Тоді і опегл 4* був б а не 3*

viktor@VIK-MINT18 ~ $ uname -r
4.10.0-26-generic
А вот с LLVM. Надо clang ставить?

сам llvm — на ньому шейдери компіляться кажись

в вас драйр відео ж r600
вот згідно mesamatrix.net мало б 4.1 опенгл бути мінімум

в вас драйр відео ж r600

radeonsi

viktor@VIK-MINT18 ~ $ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: AMD JUNIPER (DRM 2.49.0 / 4.10.0-26-generic, LLVM 4.0.1)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.0-devel
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.2.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Это с mesematrix
Enter the commercial name of your GPU (e.g. HD 6870):
Your GPU family is: Evergreen.
Your kernel driver is: radeon.
Your 3D driver is: r600g.

И как этот OpenCL 4.1 включить?

ну мав б доступ до системи — мож і найшов б причину
а так — як є час та натхнення — спробуйте ядро 4.12 і фірмваре для нього (наприклад з xanmod.org — тік воно схоче gcc6 — якщо збираєте нв системі якісь модулі додатково) або ж найти в розсилках розробників які вимоги (бо по виду ніб все оновлено в вас)... 4-й опенгл хіба для стіма тре б... в вас ж проблема з матлабом — то краще з нею і розібратись.

O! розробники пишуть цитую" OpenGL 4.1 is currently only supported on CYPRESS, CAYMAN and ARUBA. All other chips are currently limited to OpenGL 3.3″ то стосовно «evergreen» and «nothern islands» серій, тому це відхилення від теми неактуально.

ти ж недавно менi писав, що Матлаб на Лiнупсi iде....

Иде, только вот неделю назад отвалился opengl.

а якщо открутить взад апдейти, полiчить OpenGL та возбронить iх?

< оффтопик>
когда-то была проблема с конфой с дуал мониторами под свежим релизом убунты, просто не могла задетектить второй монитор, железо не понравилось, на форумах писали «да есть такая проблема с некоторыми карточками Нвидиа, Радеон и Интел»
у меня была истерика, а есть ещё какие-то дугие?!
<оффтопик>

Вероятно не было бы проблем на Matrox и S3, но кто же сейчас уже узнает 😂

Это первое, что в таких случаях нужно делать: искать кто до тебя напоролся на те же грабли. Стэктрейсы очень удобны тем, что легко позволяют дать проблеме фактически заголовок :)

Делай тыц

И ничего там...
А не, рекомендуют откатить драйвер нвидии на версию, подобрать с которой работает. Вот только у меня такого в системе не стоит — нвидии то бишь.

Не совсем. Проблема идентифицируется как несовместимость с GLVND-драйверами. NVidia просто раньше других выпустила такие дрова, вернее поставила их по дефолту. Но там есть способ поставить не-GLVND версию. А вот есть ли такое под твою видяху — копай. Вероятно есть.

devtalk.nvidia.com/...​cs-announcements-and-news

так с моей hd6770 работают нынче только опенсурсные. Т.е. баг в них?
Но других-то дров и нет, а вот ручками пересобирать опенсурсные с подбором ключей сборки — -это уже слишком для меня.

Баг НЕ в дровах, а в попытке работать с ними через проприетарную задницу вместо опенсорсного механизма.
Взять старую версию и попробовать собрать на новом ядрышке с дефолтными настройками. Вероятнее всего взлетит. А ещё надёжнее — порыться по тем самым исходникам (а лучше докам) в надежде выцепить ту самую строку GLVND. Ещё более правильно — просто ПОИСКАТЬ по имени дров тех самых опенсорсных и этой строке, а вдруг какой флажок в настройках просто подшаманить надо?

Ну и совсем уже решение в лоб — обновить видяшку. По деньгам может оказаться выгоднее — и сэкономить время, и получить более производительное счастье.

Э, таким путем я еще на винду вернусь. Но, может MS выпустит 11 винду не хуже 7.
Пока линух мне больше винды нравится для работы. Но, посмотрим дальше...

11 винды не будет, будут только обновления 10-ки.

Мне понравился официальный ответ поддержки:

matlab -softwareopengl

По-ходу проблема либо в java, либо в матлабе. Не так давно в Mesa3D пофиксили работу с pbuffer — просто стали возвращать ошибку вместо ОК, когда ошибка, так приложения еще год сыпались — столько кода некорректно работало, что аж волосы дыбом становятся.

Мне тоже.
Правда и без них я это заюзал. Причем эта лажа еще с 2003 года то всплывает, то проходит, то снова всплывает.
Причем у меня матлаб прекрасно несколько месяцев работал с hardware opengl и вот перестал.
Похоже, это таки с дровами, иксами и жабой проблема. Тем более, что в инете порыскав эта проблема и для других прог на жабе проявляется случайным образом периодически.

Это же трабл жабы при работе с иксами:

com.jogamp.opengl.GLException: X11GLXDrawableFactory — Could not initialize shared resources for X11GraphicsDevice[type .x11, connection :0.0, unitID 0, handle 0×0, owner false, ResourceToolkitLock[obj 0×7f8070c6, isOwner false, <496c188f, 57c079f1>[count 0, qsz 0, owner ]]]

И похоже даже не жабы, а иксов или дров.

Це скоріше проблема з драйверами.
Так, навскидку — схоже
github.com/...​11/X11GraphicsDevice.java
отримує мусор замість display.

Так обе ж жабы одинаково валятся. Так что похоже, что-то с дровами или каким-то вечным багом жабы.

Ну OpenGL уже умер, поэтому скоро пофиксят и будет стабильносць %)

Т.е. DirectX в линухе будет? Или Вулкан?
У меня такое впечатление, что Вулкан тот уже родился мертвым.

Vulkan. Буквально на днях пил пиво с одним из столпов современной графики, который стоял у истоков SGI и плакались друг другу в жилетку до какого состояния довели OpenGL. Если в двух словах передать 4-х часовую беседу без матов и пива, то изначально — это был инструмент инженерной визуализации (вспомним ту же GLU библиотеку), потом пришёл Кармак со своим ID Software и начался писец. Ему видите ли Direct3D не понравился. Он принёс дикую популярность OpenGL, но и сдвинул всё последующее развитие с инженерного применения в сторону игростроя. Как только убрали fixed pipeline и ввели шейдеры, OpenGL умер для инженерной визуализации, то что ты раньше мог написать за 10 минут теперь могло занимать дни и недели, особенно с тем, что предоставляла GLU библиотека, ведь инженеру абсолютно положить, что его хрень вращается на экране с 60 fps или 1000 fps. Его задача была проста — визуализировать быстро, а не красоты наводить. В конце концов разница между Direct3D и последними OpenGL была настолько мизерна, что рендеринг в игровых движках переписывали за недели туда и назад. Тут и появился Vulkan, который по сути является прямым интерфейсом к железу, только и всего. Но применять Vulkan для инженерной визуализации — это же полный П. Так что скорей всего навернут API а ля старый OpenGL поверх вулкана и сделают два точки — рей трейсинг и эмуляция fixed pipeline, всё остальное отсохнет и умрёт.

Вот тут чувак уже побежал впереди паровоза: github.com/g-truc/glo

За последние года все такие идеи с треском проваливались по итогу.
Например мне нахрен не нужен прямой интерфейс к железу, мне нужно просто рисовать и с минимальными задержками, а что внутри мне до задницы.
А сейчас я опять вернуть в те времена, когда мне надо в памяти ручками сформировать картинку и после ее уже выводить.
Так и софт еще для эти графических ускорителей вечно глючит.
Т.е. вперед в 90-е. Но тогда уже ATI Rage умела 4K, а сейчас radeon hd6770 не умеет. Да, 3D не было, но 2D летало. Но для вывода сформированной картинки мне и 2D достаточно.

А с вулканом, мне кажется произойдет аналогичное вайланду. Море шумихи и нулевой выхлоп. будет работать на единичном железе с единичным софтом.

Вот что мне нужно:
inshow да plot (для графиков, контуров и точек) и text. Всё.
А сейчас в том же матлабе эти инструменты все тормознее и тормознее с всё более навороченным железом. Уже всё вернулось к варианту, когда, чтобы получить приемлемый FPS (хотя бы 25-30) мне нужно рисовать в памяти и выводить просто картинку подготовленную.
Так еще и opengl глючит — юзайте softwareopengl. И получается, что эти карточки нужны для игр, да майнинга битков.
А возьмешь 1080. Так оттрахаешься. интернет полон той же проблемой с нвидией — там версии дров подбирают, чтобы заработало.

И всё скатывается к тому, что нужен 4 ядерный проц, но с частотами не 4, а под 20-100 ГГц. Многопоточность — это еще тот гемор, только с тяжелыми потоками смысл есть. От GPU чего добиться — тоже с кодом затрахаешься и заставлянием работать этот GPU.

А с вулканом, мне кажется произойдет аналогичное вайланду. Море шумихи и нулевой выхлоп. будет работать на единичном железе с единичным софтом.

В игрострое оно будет цвести и пахнуть. Ведь все современные видеокарты делают только для игр, тот несчастный процент для вычислений погоды не делает. По крайней мере в нашем автомобильном мире уже два крупных центра заявили о переходе на вулкан, потому что по сравнению с OpenGL ES они получили около 15% прироста производительности, а этого в современном мире достаточно, чтобы перевернуть все существующие вещи с ног на голову. Le Roi est mort, vive le Roi!

Ну, то есть остается ждать революции в CPU, нынешние технологии до потолка уже добрались. И много ядер ничего не решают, кроме маркетинговых задач. Да и напихать их в CPU оказалось сильно сложнее, чем в 2000-м предполагали. Интел, помню, грозилась 80 ядер в 2010 году сделать. Пока с трудом до 10 добрались и даже их заюзать толком не получается, только на узком кругу задач выходит.

Ну, то есть остается ждать революции в CPU

Пока предпосылок для этого нет.

И много ядер ничего не решают, кроме маркетинговых задач.

Ну как тебе сказать, решают, если эти задачи решать. Вот в реальной авто системе на четырёх ядрах закрузка в пики достигает 250% (если принять 400% за теор потолок).

Интел, помню, грозилась 80 ядер в 2010 году сделать.

Так они сделали, вопрос в коммерческой целесообразности. 88 ядер в Xeon, до 200 в Xeon Phi.

А на 10 ядрах получишь 150% при теорпотолке 1000%.
Я же и говорю, что 4 ядра оптимум на нынешней технологии и архитектуре.

вопрос № 1:а де можна почитати офiцiйний некролог?
вопрос № 2: всi вакансii з OpenLG посилать на юх до Кобола?

вопрос № 1:а де можна почитати офiцiйний некролог?

Next Generation OpenGL переименовали в Vulkan, потому то от OpenGL там осталось ровным счётом ничего. По сути объявление новой инициативы и было некрологом OpenGL’ю. Ты просто посмотри кто был в рабочей группе по созданию, если не все, то почти все игроки на рынке.

вопрос № 2: всi вакансii з OpenLG посилать на юх до Кобола?

Не, ну какое-то время он ещё будет трепыхаться. В embedded у многих Vulkan ещё сырой, как я уже говорил выше (или ниже) только два центра пока переходят на Vulkan, а их два десятка. Даже японцы пока наблюдают, а обычно они первыми на шаблю голыми пятками кидаются. Ну может ещё лет 5 потянет, но на таких вакансиях нужно параллельно учить Vulkan, чтобы потом на пенсию не отправили.

Месяц назад всё было нормально и работало.

Вся суть линукса в 1 предложении

Винда не лучше нынче, но в линухе хоть починить шанс есть, а винде жди, когда Великий Индусс соизволит пофиксить, не сломав другого.
Я и с винды свалил поэтому. В линухе сейчас траблов поменее будет.

Вот именно. И не окажется, что очередная дыра для Пети была сделана по заказу АНБ просто как закладка. Заведомо встроенный бекдор.

sudo apt install lib64stdc++6:i386

sudo apt install mesa-utils
cd your_matlab_location/sys/os/glnxa64/
sudo mv libstdc++.so.6 libstdc++.so.6.bak
sudo ln -s /usr/lib64/libstdc++.so.6 libstdc++.so.6

>> opengl info

Version: ’3.0 Mesa 17.0.3′
Vendor: ’Intel Open Source Technology Center’ ..............

HardwareSupportLevel: ’full’

У меня в матлабовской папке нет libstdc++.so.6. Линков тоже нет. Там только libstdc++.so.6.0.20.

И до отпуска всё работало.

sudo ln -s /usr/lib64/libstdc++.so.6 libstdc++.so.6

Этот линк добавил — не помогло.
И у меня радеон, а не интел. AMD — это известный вечный гемор.

И матлаб я в HOME ставил.

Понятно, softwareopengl работает.

А в матлабовской директории есть файл libgcc_s.so.1 ? Пишут, что надо его снести (переименуй) .

Они у меня в bak-ах. То есть уже снесены, переименованы.

viktor@VIK-MINT18 ~/MATLAB/R2017a/sys/os/glnxa64 $ ls
libgcc_s.so.1.bak  libgfortran.so.3.0.0  libifport.so.5  libintlc.so.5  libirc.so         libquadmath.so.0.0.0  libstdc++.so.6.bak  README.libstdc++
libgfortran.so.3   libifcore.so.5        libimf.so       libiomp5.so    libquadmath.so.0  libstdc++.so.6.0.20   libsvml.so
Это не влияет.

А ты можешь для каждой *.so в этой директории сделать ldd file.so и посмотреть все ли зависимости успешно разрешаются?

Да, корректно, все на эту /lib64/ld-linux-x86-64.so.2 ссылаются.

Было бы странно, если не ссылались :) Это динамический загрузчик.

viktor@VIK-MINT18 ~/MATLAB/R2017a/sys/os/glnxa64 $ ldd libifcore.so.5 
	linux-vdso.so.1 =>  (0x00007ffdb65ed000)
	libimf.so => not found
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc8f7e9b000)
	libintlc.so.5 => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc8f7acb000)
	/lib64/ld-linux-x86-64.so.2 (0x0000564126ee6000)
Вот такое — это нормально?
Но с другой стороны это же к opengl отношения не имеет и все кроме opengl работает хорошо.

Ну вообще-то нет, не нормально, при попытке подгрузить эту либу, будет ошибка. И ты никогда не знаешь, что реально произошло — ошибка в дровах или графическая либа, допустим, просто её погрузилась, а отсюда и ошибка.

И как пофиксить?

libintlc — это отрыжка от Intel C/C++ compiler, возможно она у тебя в другом месте лежит и матлаб знает где она и прописывает её в LD_LIBRARY_PATH при старте.

libimf — Intel Math Library — тоже самое, просто поищи её в директории матлаба, если они есть, то скорей всего матлаб настраивает пути при запуске.

viktor@VIK-MINT18 ~/MATLAB/R2017a/sys/os/glnxa64 $ ls
libgcc_s.so.1.bak  libgfortran.so.3.0.0  libifport.so.5  libintlc.so.5  libirc.so         libquadmath.so.0.0.0  libstdc++.so.6.bak  README.libstdc++
libgfortran.so.3   libifcore.so.5        libimf.so       libiomp5.so    libquadmath.so.0  libstdc++.so.6.0.20   libsvml.so
Они лежат в этой же папке.
И у матлаба нехилый скрипт для запуска, черт в нем ногу сломит.

Тогда отбой. Наслаждайся работой проприетарного графического драйвера и проприетарного матлаба на свободном линуксе — это песнь будет вечна %)

У меня опенсурсный драйвер. Проприетарного уже не существует под hd6770. А проприетарность инструмента, так удобнее матлаба и нет ничего. Уродство в стиле Питона не предлагать, там гемора на порядок больше, для R нет приемлевого IDE.
В таком случае проще вернуться в 90-е на С++ и закатывать солнце ручками.

Подписаться на комментарии