Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / типы данных в нутри OpenGL? || Зачем заниматься потоко безопасность и допускать такие ляпы?

типы данных в нутри OpenGL? || Зачем заниматься потоко безопасность и допускать такие ляпы?

Поделиться
cNoNimУчастникwww28 июня 201012:19#0
Вообще претензий к разработчикам дров пока нет,
меня просто удивили ляп в Mesa 3D...
глядел я тут их исходники, захотелось мне узнать как у них хранятся сущности доступ к которым осуществляется через индексы
* Used for display lists, texture objects, vertex/fragment programs,
* buffer objects, etc.  The hash functions are thread-safe.

написано у них в исходниках hash таблиц которые они юзают для подобных вещей...
и смотрю я тут значит реализацию
_mesa_create_shader
static GLuint
_mesa_create_shader(GLcontext *ctx, GLenum type)
{
   struct gl_shader *sh;
   GLuint name;

   name = _mesa_HashFindFreeKeyBlock(ctx->Shared->ShaderObjects, 1); // <--- потоко безопасно

/* ЛОЛ */
   switch (type) {
   case GL_FRAGMENT_SHADER:
   case GL_VERTEX_SHADER:
      sh = _mesa_new_shader(ctx, name, type);
      break;
   default:
      _mesa_error(ctx, GL_INVALID_ENUM, "CreateShader(type)");
      return 0;
   }
/* /ЛОЛ */

   _mesa_HashInsert(ctx->Shared->ShaderObjects, name, sh); // <--- потоко безопасно


   return name;
}
лола бы не было еслиб
_mesa_HashFindFreeKeyBlock
как то регистрировала, блок ключей который у нее запросили, она же просто возвращает следующий свободный
и если в двух потоках вызвать CreateShader, то оно могут записаться под одним индексом...

так вот впопрос собственно даже не в этом... а в том как сделано в нормальных дровах OpenGL?
какой АТД хотябы используется?

Ghost2Постоялецwww28 июня 201013:37#1
cNoNim

> и если в двух потоках вызвать CreateShader
Как вызвать CreateShader в двух потоках для одного контекста?

cNoNimУчастникwww28 июня 201013:41#2
1) зачем тогда вообще париться многопоточностью в этом месте?
вопрос то именно в этом...
2) может как то и можно... я точно не знаю
shared context или как там
GalantПостоялецwww28 июня 201013:56#3
щас позырю исходники
Ghost2Постоялецwww28 июня 201014:23#4
cNoNim

Вообще это все, наверное, про thread-safe vs reentrant.

cNoNimУчастникwww28 июня 201014:29#5
Ghost2
какая разница... можно было сделать нормально...
реализовать не блолокирующий findfreeblock и внешние функции блокировки hash таблицы,
либо реализовать вменяемую функцию push которая объединяла бы всю эту процедуру в одну функцию и блокировала все что нужно...
AndreyПостоялецwww28 июня 201015:32#6
cNoNim
так так исследуй дальше, очень интересно. Да и тему бы в раздел графики переложил бы.
cNoNimУчастникwww28 июня 201018:28#7
а чего исследовать то?
меня интересует какой тип данных лучше использовать в данном случае?
а все остальное так баловство
cNoNimУчастникwww28 июня 201019:36#8
спрошу более прямо,
пиплз забудьте про потоко безопасность...
какой тип данных (абстрактный тип данных)
лучше использовать если не обходимо хранить некоторое (не обязаьтельно ограниченное)
число элементов и получать доступ к ним с помощью целочисленных индексов?

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

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

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

и для списка и для вектора можно хранить индексы в самих элементах (KeyedCollection из C#), но тут мы получим долгий доступ к элементам по индексу...

дальше идут всякие мапы/деревья и подобные хрени в общем случае мне кажется они тут тоже особо не подойдут, хотя может на оборот они и будут самым лучшим выбором, доступ по индексу думаю можно с оптимизировать единственно будут траблы с добавлением удалением элементов...

поэтому сейчас еще хотелось бы коснуться hash таблиц... я до не давнего времени слабо представлял их устройство возможно и сейчас что то не так понимаю,
грубо говоря hash таблица представляется собой фиксированного размера массив указателей на односвязанные списки элементов...
при этом есть hash функция, которая приводит значение ключа к позиции в массиве указателей
(простейший пример: если у нас ключ целочисленный, допустим мы ищем элемент 1025, простейшая хеш функция это остаток от деления ключа на размер таблицы, т.е. если у нас размер таблицы 1024, то будет 1025 % 1024 = 1)...
дальше мы берем односвязный список из полученной позиции в таблице,
и пробегаем его сравнивая значение ключа хранящееся в списке и то которое мы ищем, тем самым находим нужный нам элемент...
так вот все в принципе круто, только подобная реализация хеш таблицы имеет тот же недостаток, что и обычные списки, а именно частые аллокации.
именно такой способ хранения индексируемых данных используется в mesa 3d...

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

PS: требуется именно название абстрактного типа данных и краткое его описание...

еще как мне кажется приемлемый вариант список массивов + битовая маска элементов массива...

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

/ Форум / Программирование игр / Общее

Тема в архиве.

2001—2017 © GameDev.ru — Разработка игр