Страниц: 1 ... 7 8 [9] 10
  Печать  
Автор Тема: Вышло обновление для графических драйверов devg-i830, devg-intelhd, devg-matroxp  (Прочитано 48206 раз)
qnxloder
Sr. Member
****
Offline Offline

Сообщений: 292


Просмотр профиля
« Ответ #120 : Мая 16, 2014, 11:58:44 am »

Восстановил в проекте отрисовку через gf_draw_line/polyfill теперь результат по скорости нормальный, но возникают всякие проблемы, типа утечек памяти при отрисовке закрашеных полигонов:(. Я считал что soft3d в результате использует те-же функции, что и gf_draw_line/polyfill, теперь очень сомневаюсь... Может я как-то не так использую gles?
Делаю так:
eglGetDisplay
eglInitialize
eglChooseConfig
eglCreateContext
gf_surface_create
eglCreatePixmapSurface
ну и далее ф-ции отрисовки opengl

Благодарю.
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #121 : Мая 16, 2014, 12:29:22 pm »

К сожалению soft3d использует всё софтварное, никакой акселерации, кроме glClear() нет.
Записан

qnxloder
Sr. Member
****
Offline Offline

Сообщений: 292


Просмотр профиля
« Ответ #122 : Мая 16, 2014, 12:58:27 pm »

К сожалению soft3d использует всё софтварное, никакой акселерации, кроме glClear() нет.
Почему-же тогда на других платформах(extreme /  gma) gles работает заметно! быстрее чем на ecs с intelhd хотя по частоте процессора почти одинаковые?
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #123 : Мая 16, 2014, 02:44:53 pm »

Потому что extreme и gma9xx используют аппаратную акселерацию OpenGL ES, но не используют аппаратную отрисовку линий через 2D интерфейс. В intelhd я просто использую 3D акселератор практически для половины примитивов, но только для 2D интерфейса. Я делал экспериментальный драйвер intelhd с поддержкой OpenGL ES, где закончено было процентов 60%, но так как GF интерфейс в новых версиях QNX отсутствует, то эту поддержку пришлось дропнуть.

В QNX 6.6 для IntelHD используется Linux KMS, DRM + Mesa3D для Screen Smiley В какой-то мере это правильно, ибо уходило немеряно сил для поддержки драйвера, а тут Intel сам исправляет ошибки в своих драйверах под Linux, остаётся только перекомпилить их под QNX.
Записан

qnxloder
Sr. Member
****
Offline Offline

Сообщений: 292


Просмотр профиля
« Ответ #124 : Мая 16, 2014, 03:36:00 pm »

Восстановил в проекте отрисовку через gf_draw_line/polyfill
Тут я ошибся: gf_draw_line/polyfill тормозит так-же как gles, а вот PgDrawPolygonCx нормально, собственно то что и с linebench.
Разве PgDrawPolygonCx использует чтот-то другое? Раньше думал, что все работает через GF, но сейчас вижу, что никакой иерархии нет? Помогите понять.
Спасибо.
Записан
qnxloder
Sr. Member
****
Offline Offline

Сообщений: 292


Просмотр профиля
« Ответ #125 : Мая 16, 2014, 05:02:49 pm »

Опять не то: PgDrawPolygonCx отлично заработал, когда ф-я отрисовки с использованием PgDrawPolygonCx вызвалась 1 раз во 2-м потоке без PtEnter/PtLeave, Phab-овский интерфейс заморозился, но в окне отрисовки скорость стала хорошей(раз в 10 по внутреним ощущениям при навигации кнопками(на радеоне тоже быстрее но насколько не могу сказать, т.к. разница не очень заметна(там и так нормально))). Ничего не понимаю. Буду думать...
« Последнее редактирование: Мая 16, 2014, 05:18:08 pm от qnxloder » Записан
qnxloder
Sr. Member
****
Offline Offline

Сообщений: 292


Просмотр профиля
« Ответ #126 : Мая 17, 2014, 09:51:28 am »

Подумал и вынес old=PhDCSetCurrent(dc)/PhDCSetCurrent(old) за общий цикл теперь это делается один раз для всех полигонов вместо для каждого, а их ~20000 - скорость стала просто отличной 0.14 сек (было 5! сек)(intelhd) в то время, как на радеоне 0.11 (было 0.14).
С gf_draw_begin/gf_draw_end такое не прошло(на скорость практически не повлияло ~5cсек) Sad. Но главное результат достигнут:).
На первый взгляд медленное переключение контекста отрисовки, но почему с gf_draw_begin/gf_draw_end результат практически одинаков?...
Lestat, можете объяснить полученный результат?
Записан
Dark
Sr. Member
****
Offline Offline

Сообщений: 343


Просмотр профиля
« Ответ #127 : Мая 19, 2014, 11:11:26 am »

Нет, проседания в производительности наблюдаются и по другим примитивам также. Порой даже в сравнении со штатным для Q650 драйвером и первым поколением iHD.
Этот драйвер и есть штатный.

Ну, если забыть о том, что QNX 6.5.0 вышел в 2010 году, а экспериментальный драйвер в 2012, тогда да.

В intelhd я просто использую 3D акселератор практически для половины примитивов, но только для 2D интерфейса.

С чем связано решение взводить 3D конвейер для 2D операций? Blitting движок у iHD всех поколений есть, если верить спецухам. При этом в наших проектах на новом драйвере производительность значительно падает, на драйвере 2010 года производительность при большой нагрузке на BLT движок остается приемлемой. И исходя из сообщения о способе реализации 2D операций теперь можно предположить, что всему виной он.
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #128 : Мая 19, 2014, 02:06:23 pm »

Нет, проседания в производительности наблюдаются и по другим примитивам также. Порой даже в сравнении со штатным для Q650 драйвером и первым поколением iHD.
Этот драйвер и есть штатный.
Ну, если забыть о том, что QNX 6.5.0 вышел в 2010 году, а экспериментальный драйвер в 2012, тогда да.
Тот, что вышел в 2010 имел поддержку только Ironlake чипсетов, в этом и всё разница.

В intelhd я просто использую 3D акселератор практически для половины примитивов, но только для 2D интерфейса.

С чем связано решение взводить 3D конвейер для 2D операций? Blitting движок у iHD всех поколений есть, если верить спецухам. При этом в наших проектах на новом драйвере производительность значительно падает, на драйвере 2010 года производительность при большой нагрузке на BLT движок остается приемлемой. И исходя из сообщения о способе реализации 2D операций теперь можно предположить, что всему виной он.

3D движок используется для аппаратного масштабирования картинки во время блитинга (используют очень много заказчиков), альфа блендинга (тоже используют часто) и для акселлерации отрисовки anti-aliased линий (пару заказчиков). А также аппаратная конверсия из ARGB8888 в RGB565 и наоборот.

2D блиттинг движок есть у всей линейки, он и используется в devg-intelhd. Переход на 3D выполняется только  том случае, если заданные параметры не могут быть обработаны 2D движком.

Единственное замедление в новом драйвере - это сброс буферов PgFlush(), gf_draw_begin/gf_draw_end, etc. Нужно за раз отрисовать как можно больше графики и только затем флушить вывод графики на экран. В таком случае даже наблюдается существенный прирост производительности. Старый драйвер использовал только 2D операции и, соответственно, аппаратный сброс буферов происходил быстрее.

Скорей всего вина лежит на неправильной архитектуре графического приложения.
Записан

lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #129 : Мая 19, 2014, 02:09:15 pm »

Подумал и вынес old=PhDCSetCurrent(dc)/PhDCSetCurrent(old) за общий цикл теперь это делается один раз для всех полигонов вместо для каждого, а их ~20000 - скорость стала просто отличной 0.14 сек (было 5! сек)(intelhd) в то время, как на радеоне 0.11 (было 0.14).
С gf_draw_begin/gf_draw_end такое не прошло(на скорость практически не повлияло ~5cсек) Sad. Но главное результат достигнут:).
На первый взгляд медленное переключение контекста отрисовки, но почему с gf_draw_begin/gf_draw_end результат практически одинаков?...
Lestat, можете объяснить полученный результат?
Немного непонятно, что лежит внутри gf_draw_begin/gf_draw_end. Если можно то нарисуйте хотя бы схемотично, что там происходит.
Записан

Dark
Sr. Member
****
Offline Offline

Сообщений: 343


Просмотр профиля
« Ответ #130 : Мая 19, 2014, 02:55:16 pm »

Тот, что вышел в 2010 имел поддержку только Ironlake чипсетов, в этом и всё разница.

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

3D движок используется для аппаратного масштабирования картинки во время блитинга (используют очень много заказчиков), альфа блендинга (тоже используют часто) и для акселлерации отрисовки anti-aliased линий (пару заказчиков). А также аппаратная конверсия из ARGB8888 в RGB565 и наоборот.

2D блиттинг движок есть у всей линейки, он и используется в devg-intelhd. Переход на 3D выполняется только  том случае, если заданные параметры не могут быть обработаны 2D движком.

Единственное замедление в новом драйвере - это сброс буферов PgFlush(), gf_draw_begin/gf_draw_end, etc. Нужно за раз отрисовать как можно больше графики и только затем флушить вывод графики на экран. В таком случае даже наблюдается существенный прирост производительности. Старый драйвер использовал только 2D операции и, соответственно, аппаратный сброс буферов происходил быстрее.

Скорей всего вина лежит на неправильной архитектуре графического приложения.

Так и делали, для подтверждения ставили простейший тест (1 процессор, минимальный образ - всё лишнее выключено):
Замер времени -> вывод нескольких тысяч наклонных линий на экране -> PgFlush() -> замер времени.

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

И старый драйвер и даже vesa время выдают меньшее. Куда уж проще тест - 1 примитив и 1 flush. Пробовали и другие примитивы, там результаты есть и в положительную и в отрицательную сторону в зависимости от конфигурации выводимых данных.
« Последнее редактирование: Мая 19, 2014, 02:58:57 pm от Dark » Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #131 : Мая 19, 2014, 04:00:15 pm »

И старый драйвер и даже vesa время выдают меньшее. Куда уж проще тест - 1 примитив и 1 flush. Пробовали и другие примитивы, там результаты есть и в положительную и в отрицательную сторону в зависимости от конфигурации выводимых данных.
1 примитив и 1 flush() - это плохой тест, он не загружает конвеер и на 1%. Дайте 20000 линий или 20000 прямоугольников, 20000 блитов - вот тогда новый драйвер будет быстрее. А так можно дойти и до того, что поставить 10000 точек с помощью vesabios драйвера, конечно же, будет быстрее чем такое количество точек на intelhd драйвере, ибо сетап железа будет самым большим оверхедом.

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

qnxloder
Sr. Member
****
Offline Offline

Сообщений: 292


Просмотр профиля
« Ответ #132 : Мая 19, 2014, 04:03:32 pm »

Немного непонятно, что лежит внутри gf_draw_begin/gf_draw_end. Если можно то нарисуйте хотя бы схемотично, что там происходит.
draw_begin->gf_draw_polyline->draw_end и так 20000 раз.
olddc = phdcsetcurent->PgDrawPolygonCx->phdcsetcurent(olddc)  и так 20000 раз.
на радеоне скорость практически одинаковая(gf_* процентов на 30 медленее)
а на intelhd в десяток раз медленее.
draw_begin->gf_draw_polyline и так 20000 раз->draw_end.
olddc = phdcsetcurent->PgDrawPolygonCx так 20000 раз->phdcsetcurent(olddc).
на радеоне скорость практически одинаковая.
а на intelhd gf* в десяток раз медленее, а Pg* раза в ~2 медленее чем на радеоне(на платформе с радеоном процессор в 2 раза быстрее).
Записан
Dark
Sr. Member
****
Offline Offline

Сообщений: 343


Просмотр профиля
« Ответ #133 : Мая 19, 2014, 04:17:20 pm »

1 примитив и 1 flush() - это плохой тест, он не загружает конвеер и на 1%. Дайте 20000 линий или 20000 прямоугольников, 20000 блитов - вот тогда новый драйвер будет быстрее. А так можно дойти и до того, что поставить 10000 точек с помощью vesabios драйвера, конечно же, будет быстрее чем такое количество точек на intelhd драйвере, ибо сетап железа будет самым большим оверхедом.

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


Михаил, я писал буквально следующее:

Цитировать
Замер времени -> вывод нескольких тысяч наклонных линий на экране -> PgFlush() -> замер времени.

Под "1 примитив" понималась однородность выводимой информации. Конкретно тест делали так - рисовали в цикле линии (0 + i, 0), (xres - 1 - i, yres - 1) и прогоняли в цикле i = [0; xres - 1]. Таких циклов выполняли 15 штук, а затем делали постфактум 1 flush.

С самим тестом сложно - делали для разбора полетов где-то в июне-июле 2013го. За ненадобностью и наличием подтверждений проблемы по прошествии существенного времени сорцы будет найти сложно.

Да и лично для нас на данный момент проблемы нет - старый драйвер 2010 года задачу интенсивного вывода информации решает, новый нет. Эта информация скорее "обратная связь" вам, как разработчику.
« Последнее редактирование: Мая 19, 2014, 04:19:12 pm от Dark » Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #134 : Мая 19, 2014, 11:52:21 pm »

draw_begin->gf_draw_polyline->draw_end и так 20000 раз.
olddc = phdcsetcurent->PgDrawPolygonCx->phdcsetcurent(olddc)  и так 20000 раз.
на радеоне скорость практически одинаковая(gf_* процентов на 30 медленее)
а на intelhd в десяток раз медленее.
draw_begin->gf_draw_polyline и так 20000 раз->draw_end.
olddc = phdcsetcurent->PgDrawPolygonCx так 20000 раз->phdcsetcurent(olddc).
на радеоне скорость практически одинаковая.
а на intelhd gf* в десяток раз медленее, а Pg* раза в ~2 медленее чем на радеоне(на платформе с радеоном процессор в 2 раза быстрее).
Ок, я посмотрю в чём дело.
Записан

Страниц: 1 ... 7 8 [9] 10
  Печать  
 
Перейти в: