Докуметация Cтарт Статьи Форум Лента Вход
Не официальное русскоязычное сообщество
Главная
    Статьи
        Переводы с других сайтов
            LWJGL Вики
                2.5. Устранение неполадок

2.5. Устранение неполадок

Опубликованно: 12.11.2018, 12:06
Последняя редакция, Andry: 12.11.2018 16:42

Общий

Нижеприведенные параметры обычно полезны, независимо от используемых привязок LWJGL.

Простые проверки

LWJGL выполняет несколько проверок во всех привязках и внутреннем коде. Эти проверки сосредоточены главным образом на обнаружении общих ошибок, которые могут привести к сбою процесса работы JVM. Примеры:

  • Если вызывается необязательная функция (например, функция расширения OpenGL), LWJGL проверяет и выдает исключение NullPointerException, если оно недоступно.
  • Если параметр указателя функции или член структуры никогда не должен быть равен NULL, LWJGL проверяет и выдает исключение NullPointerException, если оно есть.
  • Если параметр буфер функции или член структуры должен иметь определенный минимальный размер, LWJGL проверяет и выдает исключение IllegalArgumentException, если оно есть.

Эти проверки, как правило, оказывают низкую нагрузку на систему и потому не должны оказывать заметного влияния на производительность, поэтому они включены по умолчанию, и их отключение не рекомендуется, особенно во время разработки. Для обеспечения оптимальной производительности в конечных сборках их можно отключить с помощью -Dorg.lwjgl.util.NoChecks=true или Configuration.DISABLE_CHECKS.set(true).

Отключенные LWJGL проверки не оказывают нагрузку во время выполнения. Но, судя по Java утверждениям (assertion), они увеличивают размер байт-кода окружающих методов. В редких случаях это может повлиять на принятие решений JVM и в конечном итоге повлиять на производительность. Если такая проблема была обнаружена, то в этом случае LWJGL можно собрать с удалением всех проверок, задав binding.DISABLE_CHECKS в config/build-bindings.xml в true.

Режим отладки

LWJGL выполняет дополнительные, более дорогие проверки, когда режим отладки включен с -Dorg.lwjgl.util.Debug=true или Configuration.DEBUG.set(true). Это должен быть первый вариант, который можно использовать при столкновении с LWJGL. Режим отладки также создает дополнительный выход (по умолчанию stderr, может быть переопределен с Configuration.DEBUG_STREAM) и требуется некоторыми другими инструментами устранения неполадок.

Когда вы сообщаете о проблеме LWJGL, настоятельно рекомендуется включить режим отладки и включить её вывод с описанием проблемы.

Режим отладки загрузчика общей библиотеки

Одной из наиболее распространенных проблем, с которой сталкиваются новые пользователи LWJGL, является их проект, так что общие библиотеки загружаются правильно. Включение этого режима с помощью -Dorg.lwjgl.util.DebugLoader = true или Configuration.DEBUG_LOADER.set (true) создает дополнительный вывод в DEBUG_STREAM, что очень полезно при определении проблем с загрузкой библиотеки.

Также должен быть включен режим отладки.

Режим отладки распределителя памяти

Родные библиотеки означают неактивную память, что означает повышенный риск утечки памяти по сравнению со стандартным кодом Java. Включение этого режима с помощью -Dorg.lwjgl.util.DebugAllocator = true или Configuration.DEBUG_MEMORY_ALLOCATOR.set (true) делает LWJGL отслеживать все распределения вне кучи, выполняемые через org.lwjgl.system.MemoryUtil. Когда процесс JVM завершается, любые распределения, которые не были явно освобождены, будут сообщены в DEBUG_STREAM.

Этот режим может оказать очень негативное влияние на производительность.

Режим отладки в стеке памяти
Использование org.lwjgl.system.MemoryStack прост, но может быть источником сложной идентификации проблем. Включение этого режима с помощью -Dorg.lwjgl.util.DebugStack = true или Configuration.DEBUG_MEMORY_DEBUG_STACK.set (true) делает LWJGL сообщать о любом стеке pop без соответствующего нажатия в том же методе.

Этот режим может оказать очень негативное влияние на производительность.

Привязки

Некоторые привязки предлагают специальные инструменты, которые могут быть очень полезны для устранения неполадок.

EGL

EGL-реализации могут поддерживать расширение KHR_debug. См. OpenGL ниже для получения дополнительной информации.

GLFW

GLFW поддерживает регистрацию функции обратного вызова для уведомлений об ошибках, даже до инициализации самого GLFW, с помощью функции glfwSetErrorCallback. Пример кода:

// custom
glfwSetErrorCallback((error, description) -> {
	System.err.println("GLFW error [" + Integer.toHexString(error) + "]: " + GLFWErrorCallback.getDescription(description));
});
// or shortcut that prints to DEBUG_STREAM
GLFWErrorCallback.createPrint().set();
// or shortcut that throws an exception on error
GLFWErrorCallback.createThrow().set();

// easy clean-up
glfwSetErrorCallback(null).free();

OpenAL

OpenAL-Soft, реализация OpenAL в комплекте с LWJGL, может быть настроена с переменными окружения.

Переменная ALSOFT_LOGLEVEL определяет количество протоколирования. OpenAL Soft выписывает:

Эффективно отключает все протоколирование
Распечатывает только ошибки
Распечатывает предупреждения и ошибки
Распечатывает дополнительную информацию, а также предупреждения и ошибки
То же, что и 3, но и счетчик ссылок на устройство и контекст. Это позволит распечатать много информации и, как правило, не полезно, если вы не пытаетесь отслеживать утечку ссылок в библиотеке.

OpenCL

Когда создается контекст OpenCL, может быть зарегистрирована функция обратного вызова, которая будет использоваться реализацией OpenCL для отправки информации об ошибках при создании контекста, а также ошибок, возникающих во время выполнения в этом контексте. Пример кода:

CLContextCallback contextCB = CLContextCallback.create((errinfo, private_info, cb, user_data) -> {
    System.err.println("cl_context_callback info: " + memUTF8(errinfo));
});

long context = clCreateContext(ctxProps, device, contextCB), NULL, errcode_ret);

Функция обратного вызова может быть вызвана асинхронно с помощью реализации OpenCL. Обязанностью приложения является обеспечение того, чтобы функция обратного вызова была потокобезопасной.

OpenGL

Современные версии OpenGL поддерживают очень мощный режим отладки для сообщения об ошибках и предупреждениях. Этот режим стал стандартным в OpenGL 4.3, но есть расширения, которые обеспечивают такую же функциональность в более ранних версиях (KHR_debug, ARB_debug_output, AMD_debug_output). Пример кода:

// before context creation
glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, GLFW_TRUE);

// after context creation
glfwMakeContextCurrent(window);
GL.createCapabilities();
Callback debugProc = GLUtil.setupDebugMessageCallback(); // may return null if the debug mode is not available

// cleanup
if ( debugProc != null )
    debugProc.free();

Некоторые драйверы OpenGL предоставляют подробные информационные сообщения и предупреждения по умолчанию. Количество и тип выпускаемой продукции можно контролировать с помощью таких функций, как glDebugMessageControl.

OpenGL ES

Подобно OpenGL, OpenGL ES поддерживает режим отладки, начиная с OpenGL ES 3.2. Расширение KHR_debug также может быть доступно в более ранних версиях.

Vulkan

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

Как и в случае с Vulkan, код для такой проверки не является тривиальным. Не забудьте проверить LunarG Vulkan SDK и образец HelloVulkan LWJGL для примера.


Переведено для jmonkeyengine.ru, оригинал
Автор перевода: Andry

Добавить комментарий

jMonkeyEngine.ru © 2017. Все права сохранены.