Исправление
ckotinko,
(текущая версия)
:
«Для этого нам нужен промежуточный API, абстрагированный как от кишок реализации дисплея, так и от конкретного рисующего API»
вот поэтому я и пытался сделать свой DRI.
уровень 0: дрова видяхи. предельно тупые и не имеющие торчащего в userspace API.
уровень 1: в ядре модуль DRI, позволяющий получить все GPUхи, их типы, типы доступных ресурсов, реализующий базовые функции управления ресурсами: allocate, free, execute, send+getback(для прокидывания текстурок к WM и забору освободившихся буферов). ресурсы типа «память», «процессор(gpu, video, etc)», mapping(есть хитрая идея на сей счет), еще что нибудь(тип по FOURCC). Напр. для радеонов будет «VRAM»-просто видеопамять, «URAM»-память UVD, «GPU.», «UVD2» или «UVD3» - он вполне себе ресурс. все это можно выделять. например для opencl нужно уметь делить GPU.
сам драйвер(уровень 0) умеет только выполнять запросы - т.е. запустить шейдер/кернел/кодек, выделить/освободить память, копировать, управлять MMU. Он думать не должен, т.к. я насмотрелся, что проприетащики городят.
Уровень 2: libdrm+api для доступа к этим самым базовым функциям в ядре. На уровне 2 можно сделать затычку для проброса GPU по сети, но некоторые особо умные бро любят ниже лочить поверхности.
Уровень 3: userspace драйвер для компиляции шейдеров/кернелов и декодирования видео. Шейдеры и видео достаточно стандартны так что здесь можно обойтись довольно общим API. Здесь тоже можно сделать затычку для проброса по сети.
Уровень 4: vaapi, vdpau, opengl-переходник и opencl-переходник для уровня 3. Здесь тоже можно наделать backendов
Xlib будет в норме просто работать с X насчет ввода, а в случае работы по сети-втыкаться еще и на уровень 3 и тырить-тырить-тырить.
Исходная версия
ckotinko,
:
«Для этого нам нужен промежуточный API, абстрагированный как от кишок реализации дисплея, так и от конкретного рисующего API»
вот поэтому я и пытался сделать свой DRI.
уровень 0: дрова видяхи. предельно тупые и не имеющие торчащего в userspace API.
уровень 1: в ядре модуль DRI, позволяющий получить все GPUхи, их типы, типы доступных ресурсов, реализующий базовые функции управления ресурсами: allocate, free, execute, send+getback(для прокидывания текстурок к WM и забору освободившихся буферов). ресурсы типа «память», «процессор(gpu, video, etc)», mapping(есть хитрая идея на сей счет), еще что нибудь(тип по FOURCC). Напр. для радеонов будет «VRAM»-просто видеопамять, «URAM»-память UVD, «GPU.», «UVD2» или «UVD3» - он вполне себе ресурс. все это можно выделять. например для opencl нужно уметь делить GPU.
сам драйвер(уровень 0) умеет только выполнять запросы - т.е. запустить шейдер/кернел/кодек, выделить/освободить память, копировать, управлять MMU. Он думать не должен, т.к. я насмотрелся, что проприетащики городят.
Уровень 2: libdrm+api для доступа к этим самым базовым функциям в ядре. На уровне 2 можно сделать затычку для проброса GPU по сети, но некоторые особо умные бро любят ниже лочить поверхности.
Уровень 3: userspace драйвер для компиляции шейдеров/кернелов и декодирования видео. Шейдеры и видео достаточно стандартны так что здесь можно обойтись довольно общим API. Здесь тоже можно сделать затычку для проброса по сети.
Уровень 4: vaapi, vdpau, opengl-переходник и opencl-переходник для уровня 3. Здесь тоже можно
Xlib будет в норме просто работать с X насчет ввода, а в случае работы по сети-втыкаться еще и на уровень 3 и тырить-тырить-тырить.