И не забывай вызывать ReleaseDC по окончанию, это так же на скорость влияет.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, Andrew S, Вы писали:

AS>>С отключенным кешированием (в биосе это именно кешированием называлось) — да.

GN>Да эти названия маркетологи похоже придумывают

Продолжайте, ребята, продолжайте... одно удовольствие вас читать

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

Wd — указатель окна
BMP:= TBitmap.Create;
Windows.GetClientRect(WD, ARect);
with BMP, ARect do
begin
Width := ARect.Right — ARect.Left;
Height := ARect.Bottom — ARect.Top;
WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства
BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY);
end;

Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
Или, может быть, есть другие функции.

Здравствуйте, Multy, Вы писали:

M>Вобщем нужно скопировать содержимое другого окна приложения в битмап.

M> Wd — указатель окна
M> BMP:= TBitmap.Create;
M> Windows.GetClientRect(WD, ARect);
M> with BMP, ARect do
M> begin
M> Width := ARect.Right — ARect.Left;
M> Height := ARect.Bottom — ARect.Top;
M> WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства
M> BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY);
M> end;

M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
M>Или, может быть, есть другие функции.

а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте, Multy, Вы писали:

M>>Вобщем нужно скопировать содержимое другого окна приложения в битмап.

M>> Wd — указатель окна
M>> BMP:= TBitmap.Create;
M>> Windows.GetClientRect(WD, ARect);
M>> with BMP, ARect do
M>> begin
M>> Width := ARect.Right — ARect.Left;
M>> Height := ARect.Bottom — ARect.Top;
M>> WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства
M>> BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY);
M>> end;

M>>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
M>>Или, может быть, есть другие функции.

K>а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный

Совпадет.

K>>а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный

M>Совпадет.

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

Здравствуйте, Andrew S, Вы писали:

K>>>а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный

M>>Совпадет.

AS>Каким образом измерялась производительность? Непонятно, почему был сделан вывод о медленности BitBlt.

Запомнили время до, сравнили после вот и измерели.

К стати если копировать прото bimap
BitBlt(BMP.Canvas.Handle, 0, 0, Width, Height,BMP.Canvas.Handle , 0, 0, SRCCOPY);
Получаетя в 15 раз быстрее, т.е. дело именно в том, что копируем из окна другого приложения.

K>>>>а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный

M>>>Совпадет.

AS>>Каким образом измерялась производительность? Непонятно, почему был сделан вывод о медленности BitBlt.

M>Запомнили время до, сравнили после вот и измерели.

M>К стати если копировать прото bimap
M>BitBlt(BMP.Canvas.Handle, 0, 0, Width, Height,BMP.Canvas.Handle , 0, 0, SRCCOPY);
M>Получаетя в 15 раз быстрее, т.е. дело именно в том, что копируем из окна другого приложения.

Не только в этом. Во-первых, вы копируете с экрана, а не просто перегоняете память\память, как в случае TBitmap->TBitmap (кажется, там по умолчанию DIB секции, хотя могу и ошибаться). Естественно, что для большинства видеоадаптеров это довольно медленно. Хотя с приходом PCI-E ситуация изменилась кардинально — теперь считывать из видеопамяти быстрее, чем копировать в нее (собственно, так и должно быть — чтение завсегда было быстрее записи при работе с системной памятью при прочих равных). Во-вторых, тот DC, с которого копируете вы, на самом деле обычный кусок экранного DC, с установленным клиппингом и регионом окна (если есть, конечно). Т.о., кроме просто копирования, в худшем случае gdi приходится еще и клиппинг делать. Это хотя и быстро, но время все-равно занимает.
Простейший способ проверить — копировать с экрана напрямую (GetDC(NULL), задавая прямоугольки == размерам окна. Если будет такая же производительность — тогда быстрее не получится, даже с использование DirectDraw. Да, еще у gdi весьма медленно реализована работа с палитрой при копировании _в_ палитризованный контекст\битмап. Думаю, вряд ли у вас это используется, но вдруг.

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

Здравствуйте, Multy, Вы писали:

M>Вобщем нужно скопировать содержимое другого окна приложения в битмап.

M> Wd — указатель окна
M> BMP:= TBitmap.Create;
M> Windows.GetClientRect(WD, ARect);
M> with BMP, ARect do
M> begin
M> Width := ARect.Right — ARect.Left;
M> Height := ARect.Bottom — ARect.Top;
M> WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства
M> BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY);
M> end;

M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
M>Или, может быть, есть другие функции.

— если структура приложения позволяет попробуй вызывать фукции типа GetDC, GetWindowDC, один раз (например при старте приложения). так ты получишь частичный выиграш в скорости.

— или попробуй использовать CreateCompatibleDC — тоже должно также помочь

Здравствуйте, Multy, Вы писали:

M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
M>Или, может быть, есть другие функции.


Для отдельных случаев — быстрее будет DrawDibDraw
я все свои приложения перевел с BitBlt на DrawDibDraw

M>>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
M>>Или, может быть, есть другие функции.

V>Для отдельных случаев — быстрее будет DrawDibDraw
V>я все свои приложения перевел с BitBlt на DrawDibDraw

И совершенно напрасно, судя по всему И то, и то использует одни и те же сервисы DDI. По-крайней мере, по тестам разница в производительности — доли процента. А bitblt куда как удобнее. DrawDib предназначен несколько для других целей — воспроизведение потока. Впрочем, и тут я в нем уже смысла не вижу.

Здравствуйте, Andrew S, Вы писали:


AS>И совершенно напрасно, судя по всему И то, и то использует одни и те же сервисы DDI. По-крайней мере, по тестам разница в производительности — доли процента. А bitblt куда как удобнее. DrawDib предназначен несколько для других целей — воспроизведение потока. Впрочем, и тут я в нем уже смысла не вижу.


The DrawDib functions provide high performance image-drawing capabilities
for device-independent bitmaps (DIBs). DrawDib functions support DIBs
of 8-bit, 16-bit, 24-bit, and 32-bit image depths.

DrawDib functions write directly to video memory. They do not rely on
functions of the graphics device interface (GDI).

AS>>И совершенно напрасно, судя по всему И то, и то использует одни и те же сервисы DDI. По-крайней мере, по тестам разница в производительности — доли процента. А bitblt куда как удобнее. DrawDib предназначен несколько для других целей — воспроизведение потока. Впрочем, и тут я в нем уже смысла не вижу.


А>The DrawDib functions provide high performance image-drawing capabilities
А>for device-independent bitmaps (DIBs). DrawDib functions support DIBs
А>of 8-bit, 16-bit, 24-bit, and 32-bit image depths.

А>DrawDib functions write directly to video memory. They do not rely on
А>functions of the graphics device interface (GDI).

Не читайте перед обедом советских газет.

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

Жестко играют профессионалы

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

AS>Не читайте перед обедом советских газет.

http://www.microsoft.com/msj/0197/mfcp1/mfcp1.aspx


AS>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты.

http://www.morgan-multimedia.com/review.htm

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


http://windowssdk.msdn.microsoft.com/en-us/library/ms708083.aspx
http://www.google.com.ua/search?hl=ru&q=DrawDib+functions+write+directly+&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&meta=

AS>пусть даже изначально и написанную не вами.

Какой Вы эксперт, если в элементарных вещах не разбираетесь.

AS>>Не читайте перед обедом советских газет.

А>http://www.microsoft.com/msj/0197/mfcp1/mfcp1.aspx


AS>>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты.

А>http://www.morgan-multimedia.com/review.htm

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


А>http://windowssdk.msdn.microsoft.com/en-us/library/ms708083.aspx
А>http://www.google.com.ua/search?hl=ru&q=DrawDib+functions+write+directly+&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&meta=

AS>>пусть даже изначально и написанную не вами.

А>Какой Вы эксперт, если в элементарных вещах не разбираетесь.

Спасибо, посмеялся. Ветку со ссылками, думаю, можно в юмор Продолжать диалог с господином анонимом намбер 718 возможным не нахожу, от смеха живот заболел. Спасибо, право. Вы продлили мне жизнь как минимум на пару лет. Приходите еще!

Здравствуйте, Andrew S, Вы писали:

AS>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты. Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость, пусть даже изначально и написанную не вами.

Вот сделал тест BitBlt и DrawDibDraw: http://rsdn.ru/File/19450/BltTest.rar (на основе http://www.stereopsis.com/blttest/)
Результаты примерно одинаковые.

AS>>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты. Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость, пусть даже изначально и написанную не вами.

K>Вот сделал тест BitBlt и DrawDibDraw: http://rsdn.ru/File/19450/BltTest.rar (на основе http://www.stereopsis.com/blttest/)
K>Результаты примерно одинаковые.

О чем я и говорил изначально. Так с чем вы не согласны тогда в моем постинге? Или, наоборот, согласны?
Кстати, тесты не совсем корректны (или совсем некорректны, как угодно). Попробуйте варьировать размеры копируемых ректанглов — на маленьких, например, DrawDib (в правильно приготовленном варианте) будет сливать, поскольку имеет в 1.5 раза больше параметров + вынужден часть из них постоянно анализировать, даже с учетом вызова begin.
Единственная библиотека\интерфейс, которые делают gdi по производительности блиттинга, из тех, что я отсматривал — это allegro. Да и тут, поверьте, разница далеко не в разы. Попробуйте, кстати, directx (ddraw, а не 3d). Еще одно удивление гарантирую

Здравствуйте, Andrew S, Вы писали:

AS>>>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты. Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость, пусть даже изначально и написанную не вами.

K>>Вот сделал тест BitBlt и DrawDibDraw: http://rsdn.ru/File/19450/BltTest.rar (на основе http://www.stereopsis.com/blttest/)
K>>Результаты примерно одинаковые.

AS>О чем я и говорил изначально. Так с чем вы не согласны тогда в моем постинге? Или, наоборот, согласны?

Я занимаю нейтральную позицию. Пытаюсь для себя выяснить всё до конца.

AS>Кстати, тесты не совсем корректны (или совсем некорректны, как угодно). Попробуйте варьировать размеры копируемых ректанглов — на маленьких, например, DrawDib (в правильно приготовленном варианте) будет сливать, поскольку имеет в 1.5 раза больше параметров + вынужден часть из них постоянно анализировать, даже с учетом вызова begin.

Попробую.

AS>Единственная библиотека\интерфейс, которые делают gdi по производительности блиттинга, из тех, что я отсматривал — это allegro.

Спасибо, посмотрю.

> Попробуйте, кстати, directx (ddraw, а не 3d). Еще одно удивление гарантирую

А что должно получится? (а то времени особе нет на тесты) Тоже одинаково будет с bitblt?

>> Попробуйте, кстати, directx (ddraw, а не 3d). Еще одно удивление гарантирую

K>А что должно получится? (а то времени особе нет на тесты) Тоже одинаково будет с bitblt?

У меня это медленнее. В общем, если не нужен прямой доступ к видеопамяти, то лучше пользоваться gdi и не ломать голову. Другое дело, что на специфичных задачах gdi может сливать — например, аллегро выигрывает (сильно) на палитре + там удобнее (на мой вкус) интерфейс copy (не blt, а именно copy). Но это все надо тестировать для конкретной задачи. К тому же, еще влияние оказывают видеодрайвера — например, на моей старой машине некоторые результаты наших собственных бенчмарков в качественном плане сильно отличаются. Но то, что gdi и drawDIB пользуются одним низкоуровневым интерфейсом — это даже не обсуждается

Здравствуйте, Andrew S, Вы писали:

AS>Простейший способ проверить — копировать с экрана напрямую (GetDC(NULL), задавая прямоугольки == размерам окна. Если будет такая же производительность — тогда быстрее не получится, даже с использование DirectDraw.

это не верно
DirectDraw может держать картинку в видеопамяти, переключать плоскости (flip chain), делать батч вывод, работать в исключительном выделенном режиме а также синхронизироваться по фронту обратного хода луча. сделайте это в gdi.

Здравствуйте, Andrew S, Вы писали:


А>>Какой Вы эксперт, если в элементарных вещах не разбираетесь.

AS>Спасибо, посмеялся. Ветку со ссылками, думаю, можно в юмор Продолжать диалог с господином анонимом намбер 718 возможным не нахожу, от смеха живот заболел. Спасибо, право. Вы продлили мне жизнь как минимум на пару лет. Приходите еще!


Да дело то, не в смехе, а в некомпетентности гн-а "Andrew S". Вообще то, много смеются в мед. учреждениях специальной направленности.

гн. "Andrew S" пытается сравнивать "немного разные вещи" т.е. BitBlt c DrawDibDraw. Объясню для "эксперта", который не знает элементарных азов (наверное на тройки учился в "институте")

BitBlt копирует rectangle подчеркиваю, копирует прямоугольное изображение без изменения размеров
аналог в каком-то роде — SetDIBitsToDevice

DrawDibDraw (подчеркиваю для псевдо эксперта гн-а Andrew S) имеет основное преимущество — растяжение изображения при той же скорости. Аналог для вывода изображения — StretchDIBits (имеющего опцию расширения), которое еще требует SetStretchBltMode

Следующий момент:
DrawDibDraw позволяет копировать изображение непосредственно из массива без использования такого компонента из BitBlt как HDC hdcSrc // handle to source device context
Что при потоке входящих изображений, сэкономит некоторые ресурсы, при использовании определенного алгоритма.


Что показывают тесты. (для правильного тестирования нужно тестировать кусок полного кода, включая получение HDC)

DrawDibDraw условная усредненная скорость выполнения (количество обр. на единицу времени) 0.27973 (может растянуть изображение)
StretchDIBits условная усредненная скорость выполнения (количество обр. на единицу времени) 0.75634 (может растянуть изображение)

SetDIBitsToDevice условная усредненная скорость выполнения (количество обр. на единицу времени) 0.298634
BitBlt условная усредненная скорость выполнения (количество обр. на единицу времени) 0.2995634

AS>>Простейший способ проверить — копировать с экрана напрямую (GetDC(NULL), задавая прямоугольки == размерам окна. Если будет такая же производительность — тогда быстрее не получится, даже с использование DirectDraw.

O>это не верно
O>DirectDraw может держать картинку в видеопамяти, переключать плоскости (flip chain), делать батч вывод, работать в исключительном выделенном режиме а также синхронизироваться по фронту обратного хода луча. сделайте это в gdi.

При чем тут все это? Вы перечитайте начальный вопрос, он поставлен вполне конкретно. То, что в ddraw есть возможности, которых нет в gdi (как и наоборот) — это понятно, иначе в чем был бы смысл. Сейчас речь идет о bitblt с экранной поверхности в системную память. И даже батч не спасает ddraw в этом случае, кстати. А учитывая то, что ddraw требует одинакового формата поверхностей, то блиттинг в нем становится почти ненужным.

PS У меня такое ощущение, что народ собрался просто пофлеймить. Господа, прочитайте начальный вопрос топика и скажите, каким образом все приведенные тут библиотеки (ddraw, drawdib и т.д.) позволят ускорить блиттинг для указанной в вопросе задачи? Мой ответ — никаким. Если у вас есть другой ответ — отлично, напишите тесты.

PSS Где там господин модератор? Имхо, аноним 718 уже заслужил как минимум предупреждение за нарушение правил форума.

Здравствуйте, Andrew S, Вы писали:

AS>Во-первых, вы копируете с экрана, а не просто перегоняете память\память, как в случае TBitmap->TBitmap (кажется, там по умолчанию DIB секции, хотя могу и ошибаться). Естественно, что для большинства видеоадаптеров это довольно медленно. Хотя с приходом PCI-E ситуация изменилась кардинально — теперь считывать из видеопамяти быстрее, чем копировать в нее

Сам не проверял, но вряд ли ситуация хоть как-то улучшилась на PCI-E. Скорость работы с видеопамятью медленная, потому как эта область обычно не кешируема.

Здравствуйте, <Аноним>, Вы писали:

А>гн. "Andrew S" пытается сравнивать "немного разные вещи" т.е. BitBlt c DrawDibDraw. Объясню для "эксперта", который не знает элементарных азов (наверное на тройки учился в "институте")

Наверняка, если почитать про DDI, окажется что обе эти функции сводятся к какому-нибудь DrvBitBlt.

А>BitBlt копирует rectangle подчеркиваю, копирует прямоугольное изображение без изменения размеров
А>аналог в каком-то роде — SetDIBitsToDevice

А>DrawDibDraw (подчеркиваю для псевдо эксперта гн-а Andrew S) имеет основное преимущество — растяжение изображения при той же скорости.

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

AS>>Во-первых, вы копируете с экрана, а не просто перегоняете память\память, как в случае TBitmap->TBitmap (кажется, там по умолчанию DIB секции, хотя могу и ошибаться). Естественно, что для большинства видеоадаптеров это довольно медленно. Хотя с приходом PCI-E ситуация изменилась кардинально — теперь считывать из видеопамяти быстрее, чем копировать в нее

GN>Сам не проверял, но вряд ли ситуация хоть как-то улучшилась на PCI-E. Скорость работы с видеопамятью медленная, потому как эта область обычно не кешируема.

Ключевая фраза выделена.
Это во-первых.
А во-вторых, видеопамять уже давно (начиная с 430-х чипсетов) кешируется, в некоторых биосах есть отдельная опция, позволяющая управлять кешированием.
+ gart драйвера обычно сами управляют этим, включая кеширование.
В общем, я не вижу тут повода для флейма, поскольку
1. Человек спрашивал, как ему скопировать с экрана, а не на. Очевидно, drawDIB тут не применим никак. В топку.
2. Скорость работы drawDIB не может быть выше ввиду того, что он использует одни и те же низкоуровневые интерфейсы, что и bitblt. В топку. Для потоков, коии используются для работы с видео, есть специализированные интерфейсы, тот же WMR, которые используют аппаратные возможности. Которых drawDIB не использует ввиду убогости и того, что он никому, собственно, и не нужен.
3. Скорость работы видеопамяти через PCI-E _в разы выше_, чем скорость работы системной памяти. По крайней мере, на тех машинах, где я тестировал с GDDR3. Это легко объяснимо — 256 битный доступ, более высокая частота, отдельная PCI-E16 шина. В общем, опять нет повода не выпить

Все остальное, что всплыло в указанной ветке — от незнания основ работы gdi, и от нежелания прочитать исходный вопрос. Точка.

Здравствуйте, Andrew S, Вы писали:

AS>1. Человек спрашивал, как ему скопировать с экрана, а не на. Очевидно, drawDIB тут не применим никак.

Оппа, а я думал наоборот скопировать битмап на экран.
Тогда у меня вопрос, какой самый быстрый способ для win32 скопировать с битмапа на экран?

А>>гн. "Andrew S" пытается сравнивать "немного разные вещи" т.е. BitBlt c DrawDibDraw. Объясню для "эксперта", который не знает элементарных азов (наверное на тройки учился в "институте")

GN>Наверняка, если почитать про DDI, окажется что обе эти функции сводятся к какому-нибудь DrvBitBlt.

В интересующем нас аспекте сводится к DrvCopyBits. Либо к EngCopyBits, если драйвер объявил свою поверхность совместимой с dib engine.

А>>BitBlt копирует rectangle подчеркиваю, копирует прямоугольное изображение без изменения размеров
А>>аналог в каком-то роде — SetDIBitsToDevice

А>>DrawDibDraw (подчеркиваю для псевдо эксперта гн-а Andrew S) имеет основное преимущество — растяжение изображения при той же скорости.

GN>Выделенное не может быть верно. Иначе бы время очистки экрана было бы равно времени установки одного пикселя

Спокойно. Не надо мешать начинающему эксперту — пусть продолжает дальше нас всех поражать А то вдруг узнает, что bitblt и stretchblt суть одна функция...

AS>>1. Человек спрашивал, как ему скопировать с экрана, а не на. Очевидно, drawDIB тут не применим никак.

K>Оппа, а я думал наоборот скопировать битмап на экран.
K>Тогда у меня вопрос, какой самый быстрый способ для win32 скопировать с битмапа на экран?

Все зависит от контекста. Если нужен поток — смотри потоковые интерфейсы с аппаратным ускорением, скорее всего, придется написать свой фильтр и построить граф — этого я не делал, поэтому отправлю в форум мультимедии. Если нужно просто статический фреймбуфер выводить с прямым доступом к нему — лучше memDC, диб секции и банального bitblt ничего не придумано. Если нужно что-то большее — можно ddraw\d3d запользовать, там уже будут варианты аппаратного ускорения (в случае ddraw я такого не наблюдал — впрочем, при желании и bitblt может аппаратное ускорение использовать — все зависит от реализации драйвера, а вот работать со спрайтами в d3d путем 2-х полигонов вроде как удобно — в мультимедии про это было).

Здравствуйте, Andrew S,

GN>>Сам не проверял, но вряд ли ситуация хоть как-то улучшилась на PCI-E. Скорость работы с видеопамятью медленная, потому как эта область обычно не кешируема.

AS>Ключевая фраза выделена.
AS>Это во-первых.

Зато я тестировал разные конфигурации с AGP (4x/8x).

AS>А во-вторых, видеопамять уже давно (начиная с 430-х чипсетов) кешируется, в некоторых биосах есть отдельная опция, позволяющая управлять кешированием.
AS>+ gart драйвера обычно сами управляют этим, включая кеширование.

Если кеширование включено, при записи в видеопамять процессор сначала считает оттуда данные — дополнительное время. Если выключено — чтение всегда долгое. Палка о двух концах. Максимально быстрая операция — запись минуя кеш (movntq), но и здесь скорость в несколько раз меньше, чем у обычной памяти (в этом случае упираемся в латентность у шины или что там еще влияет).

AS>В общем, я не вижу тут повода для флейма

Протестую, это не флейм а оффтопик Интересно просто, серебрянная пуля этот PCI-E или очередное надувалово.

AS>3. Скорость работы видеопамяти через PCI-E _в разы выше_, чем скорость работы системной памяти. По крайней мере, на тех машинах, где я тестировал с GDDR3. Это легко объяснимо — 256 битный доступ, более высокая частота

Дык тоже самое говорили и про AGP 8x по сравнению с SD-RAM... Вообще-то разницу в разы можно получить и на обычной памяти, в зависимости от алгоритмов, так что тут хотелось бы посмотреть на абсолютные цифры в Gb/s. Для DDR памяти достижимо порядка 80% от теоретической (грубо, частоту её работы помножаем на 6.5 и получаем Mb/s на чтении\записи (и видим, как нас надули менеджеры, написав о 100% в названии PC3200)). Если только чтение или запись, то меньше.

Кстати, из видеопамяти читает и GPU, как для вывода на экран, так и для вычислений. Думаю, в это время все остальные отдыхают.

AS>отдельная PCI-E16 шина.

Видимо, дело в "-E16", поскольку AGP тоже отдельная шина.

AS>В общем, опять нет повода не выпить

Точно, ну его.. читать про этот PCI-E и тестировать А по другим тестам (игрушки) не увидел каких-то кардинальных улучшений в этом "explress" (впрочем, понятно, почему).

GN>>>Сам не проверял, но вряд ли ситуация хоть как-то улучшилась на PCI-E. Скорость работы с видеопамятью медленная, потому как эта область обычно не кешируема.

AS>>Ключевая фраза выделена.
AS>>Это во-первых.

GN>Зато я тестировал разные конфигурации с AGP (4x/8x).

Скажем так, по сравнению с AGP 2х и обычной GDDR (128 бит шина, частота 500) GDDR3 со 128 бит шиной на частоте 1200 у меня в 8 (!!!) раз быстрее. При этом блиттинг из видео в системную память примерно в 1.5 раза быстрее блиттинга из системной памяти в системную — одно удовольствие. Я сам был удивлен — потому и говорю, что наши тесты показывают на системах с PCI-E совершенно иные _качественно_, а не количественно (что было бы понятно) результаты.

AS>>А во-вторых, видеопамять уже давно (начиная с 430-х чипсетов) кешируется, в некоторых биосах есть отдельная опция, позволяющая управлять кешированием.
AS>>+ gart драйвера обычно сами управляют этим, включая кеширование.

GN>Если кеширование включено, при записи в видеопамять процессор сначала считает оттуда данные — дополнительное время. Если выключено — чтение всегда долгое. Палка о двух концах. Максимально быстрая операция — запись минуя кеш (movntq), но и здесь скорость в несколько раз меньше, чем у обычной памяти (в этом случае упираемся в латентность у шины или что там еще влияет).

Ровно так же, как и всем другим устройствам (а если нет встроенного контроллера памяти и отдельной шины для нее — так и для памяти, привет Интел). Так что это соображение откидываем — кеширование таки есть, и оно ровно такое же, как и для системной памяти. Разница с отключенным кешем даже на агп2х просто громадна — как по чтению, так и по записи. Это я выяснил еще во времена доса, когда удивлялся, чего это на моем супер модном компутере дюк тормозит — дело как раз в кешировании видеопамяти было. Насчет movntq. Знаешь, странно. Но вот передо мной 2 алгоритма блиттинга из аллегро. Один — оптимизирован на movntq. Второй — обычный 386+ (то бишь банальные выровненные пачки мувов). На athlon64 второй делает movntq. Ненамного, но делает. Вероятно, тут играет роль встроенный контроллер памяти (и, кстати, в примечании к zlib тоже есть фраза о том, что оптимизированный для пайплайнинга код почему то начинает тормозить на атлоне). В общем, результаты очень неоднозначны и предлагаю не заморачиваться по поводу того, как именно реализован блиттинг. Вполне возможно, что его можно реализовать и баз мастерингом, что будет вообще аппаратно (и, почти наверняка, в совокупности быстрее, чем напрягать процессор).

А шина... Шина, похоже, тут как раз минимальное влияние оказывается — по всем тестам, даже PCI-E8 не загружается — разница производительности в единицы процентов. Просто есть матери, где на сли всегда 8х8 подается, без возможности переключить на 16х1.

AS>>В общем, я не вижу тут повода для флейма

GN>Протестую, это не флейм а оффтопик Интересно просто, серебрянная пуля этот PCI-E или очередное надувалово.

Серебряной пули нет, это известно. Это просто очередной шаг вперед, как было agp по сравнениею с PCI33.

AS>>3. Скорость работы видеопамяти через PCI-E _в разы выше_, чем скорость работы системной памяти. По крайней мере, на тех машинах, где я тестировал с GDDR3. Это легко объяснимо — 256 битный доступ, более высокая частота

GN>Дык тоже самое говорили и про AGP 8x по сравнению с SD-RAM... Вообще-то разницу в разы можно получить и на обычной памяти, в зависимости от алгоритмов, так что тут хотелось бы посмотреть на абсолютные цифры в Gb/s. Для DDR памяти достижимо порядка 80% от теоретической (грубо, частоту её работы помножаем на 6.5 и получаем Mb/s на чтении\записи (и видим, как нас надули менеджеры, написав о 100% в названии PC3200)). Если только чтение или запись, то меньше.

На GDDR3 я получал порядка 4.5 Гб/c при копировании из видео в системную память (запись — медленнее примерно на 20%). А вообще, странный у вас способ подсчета. Я думал, что считается примерно так — число байт шины * частота.
Для DDR400 в дуале получаем 16*400 = 6400. Это на чтение. Соответственно, в синтетике у меня и получается порядка 6200. При копировании — 2600, что не удивительно. Т.о., GDDR3-memory в данном случае лучше не за счет того, что она (GDDR3) такая быстрая, а за счет того, что используются разные шины и разные устройства. Коряво сказал, но суть, думаю понятна — переформулировать лень.

GN>Кстати, из видеопамяти читает и GPU, как для вывода на экран, так и для вычислений. Думаю, в это время все остальные отдыхают.

Возвращаемся во времена CGA и пишем только при обратном ходе луча? Видеопамять давно двухпортовая.

AS>>отдельная PCI-E16 шина.

GN>Видимо, дело в "-E16", поскольку AGP тоже отдельная шина.

Не а. E8 тоже ничо так

AS>>В общем, опять нет повода не выпить

GN>Точно, ну его.. читать про этот PCI-E и тестировать А по другим тестам (игрушки) не увидел каких-то кардинальных улучшений в этом "explress" (впрочем, понятно, почему).

Это понятно. Для игр оно и не надо — там важнее всякие вертекс процессоры и количество набортной памяти...
Впрочем, все это дикий оффтопик. Что товарищу то с исходным вопросом делать? Может, отправить его в поиск по форуму на WM_PRINT?

Здравствуйте, Andrew S, Вы писали:

AS>Скажем так, по сравнению с AGP 2х и обычной GDDR (128 бит шина, частота 500) GDDR3 со 128 бит шиной на частоте 1200 у меня в 8 (!!!) раз быстрее. При этом блиттинг из видео в системную память примерно в 1.5 раза быстрее блиттинга из системной памяти в системную

В последнем случае видимо не хватает пропускной способности шины. А AGP 2х — крайне мало для DDR на 500Mhz. Даже 8x (2133 MB/s) мало.

GN>>Если кеширование включено, при записи в видеопамять процессор сначала считает оттуда данные — дополнительное время. Если выключено — чтение всегда долгое. Палка о двух концах. Максимально быстрая операция — запись минуя кеш (movntq), но и здесь скорость в несколько раз меньше, чем у обычной памяти (в этом случае упираемся в латентность у шины или что там еще влияет).

AS>Ровно так же, как и всем другим устройствам (а если нет встроенного контроллера памяти и отдельной шины для нее — так и для памяти, привет Интел).

Все же разница есть:
CPU — контроллер — память
CPU — контроллер PCI\AGP — GPU — видеопамять

AS>Так что это соображение откидываем — кеширование таки есть, и оно ровно такое же, как и для системной памяти.

Кеширование с обратной записью (write-back, применяемое в обычноом ОЗУ) вряд ли можно использовать для видео: когда мы увидим изменения на экране? Сквозное кеширование (write-through) можно использовать, но оно даст задержки из-за чтения. Поэтому практически используют лишь варианты write-combining. И рекомендуют не читать из такой памяти.

Verify that the WC memory is never read from. Reads from WC memory are even slower than WC Partial Writes, and your application should be designed such that they never occur. If you need to read the image data to modify it or create a new image, keep a copy of the data that will need to be read in regular WB memory, and then copy it to the WC memory.

(How to Get Faster Video Rendering on the Intel® Pentium® 4 Processor)

AS>Насчет movntq. Знаешь, странно. Но вот передо мной 2 алгоритма блиттинга из аллегро. Один — оптимизирован на movntq. Второй — обычный 386+ (то бишь банальные выровненные пачки мувов). На athlon64 второй делает movntq.

На небольших спрайтах? Видел что-то подобное. Думаю, это из-за сраниц и банков памяти. Просто отдельно взятая movntq должна быть быстрее обычной записи, так как не провоцирует чтение в кеш модифицируемой линейки памяти.

AS>А шина... Шина, похоже, тут как раз минимальное влияние оказывается — по всем тестам, даже PCI-E8 не загружается — разница производительности в единицы процентов. Просто есть матери, где на сли всегда 8х8 подается, без возможности переключить на 16х1.

Ну как бы в теории даже E8 в 2 раза быстрее чем AGP 8x

AS>На GDDR3 я получал порядка 4.5 Гб/c при копировании из видео в системную память (запись — медленнее примерно на 20%).

Это блиттером или руками?

AS>А вообще, странный у вас способ подсчета. Я думал, что считается примерно так — число байт шины * частота.

8 * 80% = 6.4
Осталось умножить на частоту

AS>Для DDR400 в дуале получаем 16*400 = 6400. Это на чтение. Соответственно, в синтетике у меня и получается порядка 6200. При копировании — 2600, что не удивительно.

При копировании читается (за секунду) 2600 Мб, и записывается столько же. Итого по шине проходит 5200 Мб/с.
5200/6400 = 0.81

AS>Т.о., GDDR3-memory в данном случае лучше не за счет того, что она (GDDR3) такая быстрая, а за счет того, что используются разные шины и разные устройства.

Дык и с AGP ведь отдельная шина... видимо играет роль интегрированные в процессор гипертранспорт и контроллер памяти

GN>>Кстати, из видеопамяти читает и GPU, как для вывода на экран, так и для вычислений. Думаю, в это время все остальные отдыхают.

AS> Возвращаемся во времена CGA и пишем только при обратном ходе луча? Видеопамять давно двухпортовая.

Думаю, его ждали, что бы картинка не дёргалась. А 2 порта мадо для: CPU, GPU и RAMDAC\DVI

AS>Впрочем, все это дикий оффтопик. Что товарищу то с исходным вопросом делать? Может, отправить его в поиск по форуму на WM_PRINT?

Не знаю. Вопрос не понял. Вроде как речь идёт о получении битмапа (а стало быть и о BITMAPINFO) и можно подумать о CreateDIBSection (вот только чужой процесс...). А BitBlt работает с контекстами устройств.

GN>Кеширование с обратной записью (write-back, применяемое в обычноом ОЗУ) вряд ли можно использовать для видео: когда мы увидим изменения на экране? Сквозное кеширование (write-through) можно использовать, но оно даст задержки из-за чтения. Поэтому практически используют лишь варианты write-combining. И рекомендуют не читать из такой памяти.
GN>

Verify that the WC memory is never read from. Reads from WC memory are even slower than WC Partial Writes, and your application should be designed such that they never occur. If you need to read the image data to modify it or create a new image, keep a copy of the data that will need to be read in regular WB memory, and then copy it to the WC memory.

(How to Get Faster Video Rendering on the Intel® Pentium® 4 Processor)

Я все это уже когда то отсматривал. Не понижает кеширование скорость чтения, и все тут. По крайней мере, на моем BX440. А, наоборот, увеличивает, и прилично.

AS>>Насчет movntq. Знаешь, странно. Но вот передо мной 2 алгоритма блиттинга из аллегро. Один — оптимизирован на movntq. Второй — обычный 386+ (то бишь банальные выровненные пачки мувов). На athlon64 второй делает movntq.

GN>На небольших спрайтах? Видел что-то подобное. Думаю, это из-за сраниц и банков памяти. Просто отдельно взятая movntq должна быть быстрее обычной записи, так как не провоцирует чтение в кеш модифицируемой линейки памяти.

Ну если 1280х960х4 считать небольшим спрайтом, то да.

AS>>А шина... Шина, похоже, тут как раз минимальное влияние оказывается — по всем тестам, даже PCI-E8 не загружается — разница производительности в единицы процентов. Просто есть матери, где на сли всегда 8х8 подается, без возможности переключить на 16х1.

GN>Ну как бы в теории даже E8 в 2 раза быстрее чем AGP 8x

AS>>На GDDR3 я получал порядка 4.5 Гб/c при копировании из видео в системную память (запись — медленнее примерно на 20%).

GN>Это блиттером или руками?

Блиттером. Но обычным memcpy медленнее блиттера.

AS>>А вообще, странный у вас способ подсчета. Я думал, что считается примерно так — число байт шины * частота.

GN>8 * 80% = 6.4
GN>Осталось умножить на частоту

AS>>Для DDR400 в дуале получаем 16*400 = 6400. Это на чтение. Соответственно, в синтетике у меня и получается порядка 6200. При копировании — 2600, что не удивительно.

GN>При копировании читается (за секунду) 2600 Мб, и записывается столько же. Итого по шине проходит 5200 Мб/с.
GN>5200/6400 = 0.81

Копирование — прилично сложнее чтения или записи, кроме самих данных по шине пролетает и код, и синхронизации кеша и прочее.
Контроллеры атлона64 — очень эффективны, насколько я помню, в тестах показывали до 96% теоретической пропускной способности при правильной настройке памяти. Тесты были на fcenter.ru. В дуале — до 91%.

AS>>Т.о., GDDR3-memory в данном случае лучше не за счет того, что она (GDDR3) такая быстрая, а за счет того, что используются разные шины и разные устройства.

GN>Дык и с AGP ведь отдельная шина... видимо играет роль интегрированные в процессор гипертранспорт и контроллер памяти

С агп на старых машинах обычно все хуже — там контроллер памяти на этой же шине еще висит.

GN>>>Кстати, из видеопамяти читает и GPU, как для вывода на экран, так и для вычислений. Думаю, в это время все остальные отдыхают.

AS>> Возвращаемся во времена CGA и пишем только при обратном ходе луча? Видеопамять давно двухпортовая.

GN>Думаю, его ждали, что бы картинка не дёргалась. А 2 порта мадо для: CPU, GPU и RAMDAC\DVI

Его ждали, чтобы не было снега на экране, потому что память была однопортовая, и при чтении или записи из нее на экране возникала этакая рябь. Двухпортовая она уже с первых VGA контроллеров. Сколько сейчас портов в GDDR — я не знаю, но думаю, достаточно, чтобы все устройства обращались к памяти независимо.

AS>>Впрочем, все это дикий оффтопик. Что товарищу то с исходным вопросом делать? Может, отправить его в поиск по форуму на WM_PRINT?

GN>Не знаю. Вопрос не понял. Вроде как речь идёт о получении битмапа (а стало быть и о BITMAPINFO) и можно подумать о CreateDIBSection (вот только чужой процесс...). А BitBlt работает с контекстами устройств.

Речь там идет о получении скриншота окна.

Здравствуйте, Andrew S, Вы писали:

AS>Не понижает кеширование скорость чтения, и все тут. По крайней мере, на моем BX440. А, наоборот, увеличивает, и прилично.

Мне кажется, что я тоже видел что-то про "кеширование" видеопамяти в BIOS.
Но согласно даташиту на Intel® 440BX AGPset: 82443BX Host Bridge/Controller (29063301.pdf) —

4.1.1.4 AGP DRAM Graphics Aperture
[]
The aperture range will not be cacheable in the processor caches.

4.2.4 Frame Buffer Memory Support (USWC)
To allow for high speed write capability for graphics, the Pentium Pro processor family has
introduced USWC memory type. The USWC (uncacheable, speculative, write-combining) memory
type provides a write-combining buffering mechanism for write operations. A high percentage of
graphics transactions are writes to the memory-mapped graphics region, normally known as the
linear frame buffer. Reads and writes to USWC are non-cached and can have no side effects.

Может кешировалось на 486, где кеш не был интегрирован в процессор?

AS>>>На GDDR3 я получал порядка 4.5 Гб/c при копировании из видео в системную память (запись — медленнее примерно на 20%).

GN>>Это блиттером или руками?

AS>Блиттером. Но обычным memcpy медленнее блиттера.

Ну вот, а я то о том, что ручками медленно копировать Блиттер аппаратно ускорен... но не везде.

Я вот почему про эти тормоза заговорил. Само по-себе чтение видеопамяти — довольно редкая операция.
Вижу 2 приминения: скриншот (скорость не принципиально важна) и "видеозахват экрана" (скорость критична, но при определённом дизайне видеоподсистемы можно обойтись без чтения — mirror drivers это не то?).
А (выборочная) чтение-модификация-запись видеопамяти могла бы быть полезной во многих случаях. Аппаратный блит всего экрана не поможет — мало смысла, вместо чтения видеопамяти проще хранить копию в локальной. Но в локальную память нельзя (сложно, медленно) рендерить 3D. Сплошные затыки, и решение — 2 лишних блиттинга. Потому игрушки до сих пор не сильно отличаются от 3Dfx voodoo

AS>С агп на старых машинах обычно все хуже — там контроллер памяти на этой же шине еще висит.

Дык шина эта (если не брать Intel) с хорошим запасом... То ли запас этот дутый, толи реализация кривая.

GN>>>>Кстати, из видеопамяти читает и GPU, как для вывода на экран, так и для вычислений. Думаю, в это время все остальные отдыхают.

AS>>> Возвращаемся во времена CGA и пишем только при обратном ходе луча? Видеопамять давно двухпортовая.

GN>>Думаю, его ждали, что бы картинка не дёргалась. А 2 порта мадо для: CPU, GPU и RAMDAC\DVI

AS>Его ждали, чтобы не было снега на экране, потому что память была однопортовая, и при чтении или записи из нее на экране возникала этакая рябь.

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

AS>Речь там идет о получении скриншота окна.

В чужом процессе. Непонятно, что с ним потом делать и зачем такая скорость (точнее, как часто нужен скриншот).

AS>>Не понижает кеширование скорость чтения, и все тут. По крайней мере, на моем BX440. А, наоборот, увеличивает, и прилично.

GN>Мне кажется, что я тоже видел что-то про "кеширование" видеопамяти в BIOS.
GN>Но согласно даташиту на Intel® 440BX AGPset: 82443BX Host Bridge/Controller (29063301.pdf) -

GN>

4.1.1.4 AGP DRAM Graphics Aperture
GN>[]
GN>The aperture range will not be cacheable in the processor caches.

Нагло врут. На моем P2B эта опция рядом с размером апертуры АГП.
http://testmem.nm.ru/testvram04.htm#05

Включение кеширования в BIOS'е весьма значительно повышает скорость доступа по записи к видеопамяти. К примеру, без кеширования скорость записи составляет 43Mb/sec, а с включением кеширования она возрастает до 200Mb/sec. На скорость чтения кеширование записи не оказывает влияния.

Это про USWC. У меня там и было 2 опции — UC и USWC. И они _работают_.

GN>

4.2.4 Frame Buffer Memory Support (USWC)
GN>To allow for high speed write capability for graphics, the Pentium Pro processor family has
GN>introduced USWC memory type. The USWC (uncacheable, speculative, write-combining) memory
GN>type provides a write-combining buffering mechanism for write operations. A high percentage of
GN>graphics transactions are writes to the memory-mapped graphics region, normally known as the
GN>linear frame buffer. Reads and writes to USWC are non-cached and can have no side effects.

GN>Может кешировалось на 486, где кеш не был интегрирован в процессор?

Нет. Я ж говорю — самолично тестировал Еще на дюке.

AS>>>>На GDDR3 я получал порядка 4.5 Гб/c при копировании из видео в системную память (запись — медленнее примерно на 20%).

GN>>>Это блиттером или руками?

AS>>Блиттером. Но обычным memcpy медленнее блиттера.

GN>Ну вот, а я то о том, что ручками медленно копировать Блиттер аппаратно ускорен... но не везде.

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

GN>Я вот почему про эти тормоза заговорил. Само по-себе чтение видеопамяти — довольно редкая операция.
GN>Вижу 2 приминения: скриншот (скорость не принципиально важна) и "видеозахват экрана" (скорость критична, но при определённом дизайне видеоподсистемы можно обойтись без чтения — mirror drivers это не то?).

А ты подумай. Если не читать — приходится постоянно _копировать_. Как я тебе тут показал, операция копирования в 1.5 раза медленнее. Более того, при постоянном копировании в миррор драйвере ты делаешь не только копирование, но и преобразования — фактически, переадресуя все вызовы на свою поверхность в EngXxxx функции. Что, естественнно, в 90% случаев медленее тупого переноса данных. Тем более, обычно накапливают некоторую область обновления, и только после этого копируют. В миррор драйвере этого, по понятным причинам, простыми способами не сделать.

GN>А (выборочная) чтение-модификация-запись видеопамяти могла бы быть полезной во многих случаях. Аппаратный блит всего экрана не поможет — мало смысла, вместо чтения видеопамяти проще хранить копию в локальной. Но в локальную память нельзя (сложно, медленно) рендерить 3D. Сплошные затыки, и решение — 2 лишних блиттинга. Потому игрушки до сих пор не сильно отличаются от 3Dfx voodoo

Не проще. См. выше. А игрушки — отличаются не потому. Просто нет нормальных идей. До сих пор с удовольствием по сетке в анрил турнамент играем, по графике — сравнимо с думом 3 легко. И от всех этих шейдеров игры не становятся ну ни капельки не красочнее и интереснее. Тьфу.

AS>>С агп на старых машинах обычно все хуже — там контроллер памяти на этой же шине еще висит.

GN>Дык шина эта (если не брать Intel) с хорошим запасом... То ли запас этот дутый, толи реализация кривая.

GN>>>>>Кстати, из видеопамяти читает и GPU, как для вывода на экран, так и для вычислений. Думаю, в это время все остальные отдыхают.

AS>>>> Возвращаемся во времена CGA и пишем только при обратном ходе луча? Видеопамять давно двухпортовая.

GN>>>Думаю, его ждали, что бы картинка не дёргалась. А 2 порта мадо для: CPU, GPU и RAMDAC\DVI

AS>>Его ждали, чтобы не было снега на экране, потому что память была однопортовая, и при чтении или записи из нее на экране возникала этакая рябь.

GN>Понятно. И за что только с людей втридорого драли за эти древние уродские писюки На копеечном спектруме никакого снега не было.

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

AS>>Речь там идет о получении скриншота окна.

GN>В чужом процессе. Непонятно, что с ним потом делать и зачем такая скорость (точнее, как часто нужен скриншот).

Ну, кто его знает. Автор больше тут не появлялся. Зато дал возможность поговорить

Здравствуйте, Andrew S, Вы писали:

AS>На моем P2B эта опция рядом с размером апертуры АГП.
AS>http://testmem.nm.ru/testvram04.htm#05
AS>

AS>Включение кеширования в BIOS'е весьма значительно повышает скорость доступа по записи к видеопамяти. К примеру, без кеширования скорость записи составляет 43Mb/sec, а с включением кеширования она возрастает до 200Mb/sec. На скорость чтения кеширование записи не оказывает влияния.

AS>Это про USWC. У меня там и было 2 опции — UC и USWC. И они _работают_.

В цитате даташита так и написано, что это работает. Но это не кеширование, а комбинирование записи.

WC = write-combining
USWC = uncacheable, speculative, write-combining

GN>>Может кешировалось на 486, где кеш не был интегрирован в процессор?

AS>Нет. Я ж говорю — самолично тестировал Еще на дюке.

На PII+ Дюк тормозил?

GN>>Ну вот, а я то о том, что ручками медленно копировать Блиттер аппаратно ускорен... но не везде.

AS>memcpy медленнее и из системной в системную. Но разница там незначительная, т.е. gdi выигрывает просто за счет более оптимизированных процедур.

memcpy может быть разная и отличаться по скорости до 3х раз. Скорее всего, memcpy в gdi просто лучше реализовано (там точно она, в системной памяти не используют аппаратное ускорение)

GN>>Я вот почему про эти тормоза заговорил. Само по-себе чтение видеопамяти — довольно редкая операция.
GN>>Вижу 2 приминения: скриншот (скорость не принципиально важна) и "видеозахват экрана" (скорость критична, но при определённом дизайне видеоподсистемы можно обойтись без чтения — mirror drivers это не то?).

AS>А ты подумай. Если не читать — приходится постоянно _копировать_. Как я тебе тут показал, операция копирования в 1.5 раза медленнее.

Думаю так: по одному пикселю рисовать в видеопамять всё равно долго (вдруг WC отключен, да и техники оптимизации работы с памятью рекомендуют подготовить данные "в кеше CPU" а потом махом копировать все) поэтому изменения строятся в буфере. Да, потом это буфер копируется в видеопамять. Но зато будет готов "бесплатный" скриншот

А иначе копирование всё равно будет, только маленькими кусками.

AS> Более того, при постоянном копировании в миррор драйвере ты делаешь не только копирование, но и преобразования — фактически, переадресуя все вызовы на свою поверхность в EngXxxx функции. Что, естественнно, в 90% случаев медленее тупого переноса данных. Тем более, обычно накапливают некоторую область обновления, и только после этого копируют.

Во, примерно как я и говорил Архитектуру миррор драйверов и всего DDI следует переделать, если плохо вписывается

AS>В миррор драйвере этого, по понятным причинам, простыми способами не сделать.

GN>>А (выборочная) чтение-модификация-запись видеопамяти могла бы быть полезной во многих случаях. Аппаратный блит всего экрана не поможет — мало смысла, вместо чтения видеопамяти проще хранить копию в локальной. Но в локальную память нельзя (сложно, медленно) рендерить 3D. Сплошные затыки, и решение — 2 лишних блиттинга. Потому игрушки до сих пор не сильно отличаются от 3Dfx voodoo

AS>Не проще. См. выше. А игрушки — отличаются не потому. Просто нет нормальных идей.

Дык их и не будет! Дали девелоперам 3D ускоритель LEGO, но кубиков там половина, на сложное не хватает... и постепенно добавляют в него новые кубики. Только сначала кубики были треугольные, а новые какие-то закруглённые. В результате ничего не складывается Всего-то несколько пикселей бы нарисовать, что бы загладить дыры в 3D сцене — но нельзя, юзайте специальный интерфейс и вызовы ядра с двойным копированием !

AS>Автор больше тут не появлялся. Зато дал возможность поговорить

AS>>Нет. Я ж говорю — самолично тестировал Еще на дюке.

GN>На PII+ Дюк тормозил?

С отключенным кешированием (в биосе это именно кешированием называлось) — да. Впрочем, то, что это не кеширование в прямом смысле этого слова — тоже верно (хотя, смотря что понимать под словом кеширование. Если только отображаение в кэш процессора — тогда да).

GN>>>Ну вот, а я то о том, что ручками медленно копировать Блиттер аппаратно ускорен... но не везде.

AS>>memcpy медленнее и из системной в системную. Но разница там незначительная, т.е. gdi выигрывает просто за счет более оптимизированных процедур.

GN>memcpy может быть разная и отличаться по скорости до 3х раз. Скорее всего, memcpy в gdi просто лучше реализовано (там точно она, в системной памяти не используют аппаратное ускорение)

Я вот на атлоне64 не смог такой разницы никакими методами добиться. Максимальная разница — в единицы процентов. Причем правильно написанная процедура с обычными мувами может спокойно делать (на те же единицы процентов) копирование через SSE или MMX. Что еще раз показывает бесперспективность предварительной оптимизации
Да и в большинстве случаев при копировании из видеопамяти аппаратное ускорение не используют. В общем, не в ускорении дело, а в том, что загружаются разные устройства и шины.

GN>>>Я вот почему про эти тормоза заговорил. Само по-себе чтение видеопамяти — довольно редкая операция.
GN>>>Вижу 2 приминения: скриншот (скорость не принципиально важна) и "видеозахват экрана" (скорость критична, но при определённом дизайне видеоподсистемы можно обойтись без чтения — mirror drivers это не то?).

AS>>А ты подумай. Если не читать — приходится постоянно _копировать_. Как я тебе тут показал, операция копирования в 1.5 раза медленнее.

GN>Думаю так: по одному пикселю рисовать в видеопамять всё равно долго (вдруг WC отключен, да и техники оптимизации работы с памятью рекомендуют подготовить данные "в кеше CPU" а потом махом копировать все) поэтому изменения строятся в буфере. Да, потом это буфер копируется в видеопамять. Но зато будет готов "бесплатный" скриншот

GN>А иначе копирование всё равно будет, только маленькими кусками.

Копирование все-равно будет, посколько gdi это и так делает. Собирает оно или нет очень маленькие обновления — по идее должно, даже на уровне юзер. На практике же я этого не наблюдал. Поэтому в случае миррор дравера мы вынуждены рисовать 2 раза — один раз в видеопамять, а второй раз в системную. На любые изменения. И не просто копировать — а делать блиттинг, выводить текст и т.д. — т.е. делать заведомо более тормозные операции, чем тупое копирование данных.
Как я тебе уже тут показал, копирование из системной памяти в системную для PCI-E медленнее, чем из видео в системную. Итого, получается, при собирании все в системную память вместо работы с видео мы имеем:
1. Любое обновление обрабатывается 2 раза — один раз в видео, другой раз в системную память.
2. ОБрабатываются _все_ операции, накопление невозможно.
3. Копирование системная-системная на современных машинах медленнее, чем видео-системная.

Ну и где же столь желаемые преймущества? Отвечу. А нету их. По крайней мере, для моих задач — я это тестировал довольно активно Причем различие — ну просто разительное. Тестировалось, кстати, еще на АГП 2-х и той самой несчастной BX440, где копирование из видео было медленнее, чем в системную память. Просто очень сильно влияет то, что мне не все обновления обычно нужны сразу, можно их сначала собрать (например, пока шедуллер не провернется), и уже затем взять из видеопамяти нужный кусок сразу, целиком. Получается прилично эффективнее даже при условно медленном доступе в видеопамять.

AS>> Более того, при постоянном копировании в миррор драйвере ты делаешь не только копирование, но и преобразования — фактически, переадресуя все вызовы на свою поверхность в EngXxxx функции. Что, естественнно, в 90% случаев медленее тупого переноса данных. Тем более, обычно накапливают некоторую область обновления, и только после этого копируют.

GN>Во, примерно как я и говорил Архитектуру миррор драйверов и всего DDI следует переделать, если плохо вписывается

Архитектура DDI настолько отстойна, что ее надо не переделывать, а просто разрабатывать заново. Миррор драйвер — дешевая подпорка, к сожалению. Грамотно реализовать то, для чего он задумывался, с его помощью очень и очень непросто. А насчет качества его прикручивания — одна невозможность нормального его удаления в вин2к о многом говорит. И никакие сервис паки это так и не исправили. О чем они там думают, непонятно.

M>Вобщем нужно скопировать содержимое другого окна приложения в битмап.

    HDC window_dc = GetWindowDC(winHandle);
    HDC bitmap_dc = CreateCompatibleDC(window_dc);
    HBITMAP bitmap = CreateCompatibleBitmap(window_dc, w, h);
    HGDIOBJ null_bitmap = SelectObject(bitmap_dc, bitmap);    
    PrintWindow(winHandle, bitmap_dc, 0);

M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
M>Или, может быть, есть другие функции.

насчет скорости не скажу — не проверял, но работает корректней. Правда, работает только на XP, 2003 Serv.

Здравствуйте, Andrew S, Вы писали:

AS>С отключенным кешированием (в биосе это именно кешированием называлось) — да.

Да эти названия маркетологи похоже придумывают

AS>Впрочем, то, что это не кеширование в прямом смысле этого слова — тоже верно (хотя, смотря что понимать под словом кеширование. Если только отображаение в кэш процессора — тогда да).

По кешированием понимаю перенос данных в более быстрое хранилище (для возможности повторного быстрого использования). А что еще под ним можно понимать?

Теперь о чтении видеопамяти. Поскольку память эта не кешируется в кеше CPU, то повторные чтения будут медленны. Так же, в случае обычной памяти, в кеш читается сразу несколько последовательных ячеек, что ускоряет доступ к последовательным элементам. Поэтому читать из видеопамять быстро никак не получится.
Видимо, это учли про проектировании PCI-E или видеокарт для неё. И сделали быстрый аппаратный блиттинг, который может быстро скопировать большой объем памяти. На маленьких объёмах он будет проигрывать программному чтению (лишние вызовы ядра, отправка команд GPU). Фактически, копируя видеопамять в основную мы выполняем ручное кеширование.


AS>Копирование все-равно будет, посколько gdi это и так делает. Собирает оно или нет очень маленькие обновления — по идее должно, даже на уровне юзер. На практике же я этого не наблюдал. Поэтому в случае миррор дравера мы вынуждены рисовать 2 раза — один раз в видеопамять, а второй раз в системную. На любые изменения. И не просто копировать — а делать блиттинг, выводить текст и т.д. — т.е. делать заведомо более тормозные операции, чем тупое копирование данных.
AS>Как я тебе уже тут показал, копирование из системной памяти в системную для PCI-E медленнее, чем из видео в системную. Итого, получается, при собирании все в системную память вместо работы с видео мы имеем:
AS>1. Любое обновление обрабатывается 2 раза — один раз в видео, другой раз в системную память.

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

AS>2. ОБрабатываются _все_ операции, накопление невозможно.
AS>3. Копирование системная-системная на современных машинах медленнее, чем видео-системная.

Проблема в том, что на одно копирование системная-системная понадобтся 2 других: системная->видео и видео->системная. Или понядобится видео->системная, в то время, как из системной копировать не надо. Нужен скриншот — просто получил указатель в системной памяти и всё.

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

AS>Ну и где же столь желаемые преймущества? Отвечу. А нету их. По крайней мере, для моих задач — я это тестировал довольно активно Причем различие — ну просто разительное.

Дык правильно, сейчас ведь всё сделано не так, как надо.

Здравствуйте, Multy, Вы писали:

M>Вобщем нужно скопировать содержимое другого окна приложения в битмап.

M> Wd — указатель окна
M> BMP:= TBitmap.Create;
M> Windows.GetClientRect(WD, ARect);
M> with BMP, ARect do
M> begin
M> Width := ARect.Right — ARect.Left;
M> Height := ARect.Bottom — ARect.Top;
M> WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства
M> BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY);
M> end;

M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить?
M>Или, может быть, есть другие функции

Win API позволяет работать с двумя типами битмапов — independed format и compatible format.
Наиболее быстрое копирование для compatible. Т.е., если пользоваться API, то

HDC hdc = CreateCompatibleDC(0);
HBITMAP hbm = CreateCompatibleBitmap(WinDC, Width, Height);
HBITMAP hbp = SelectObject(hdc, hbm);
BitBlt(hdc, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY);


do something ....

DeleteObject(SelectObject(hdc, hbp));
DeleteDC(hdc);

AS>>С отключенным кешированием (в биосе это именно кешированием называлось) — да.

GN>Да эти названия маркетологи похоже придумывают

AS>>Впрочем, то, что это не кеширование в прямом смысле этого слова — тоже верно (хотя, смотря что понимать под словом кеширование. Если только отображаение в кэш процессора — тогда да).

GN>По кешированием понимаю перенос данных в более быстрое хранилище (для возможности повторного быстрого использования). А что еще под ним можно понимать?

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

GN>Теперь о чтении видеопамяти. Поскольку память эта не кешируется в кеше CPU, то повторные чтения будут медленны. Так же, в случае обычной памяти, в кеш читается сразу несколько последовательных ячеек, что ускоряет доступ к последовательным элементам. Поэтому читать из видеопамять быстро никак не получится.
GN>Видимо, это учли про проектировании PCI-E или видеокарт для неё. И сделали быстрый аппаратный блиттинг, который может быстро скопировать большой объем памяти. На маленьких объёмах он будет проигрывать программному чтению (лишние вызовы ядра, отправка команд GPU). Фактически, копируя видеопамять в основную мы выполняем ручное кеширование.

Да не аппаратный это блиттинг, блин, ну сколько можно. Берем directx, получаем указатель на физическую поверхность, применяем алгоритмы из аллегро — получаем немного _быстрее_ gdi. По крайней мере, на моей 6600gt и 80-х драйверах. Ты не забывай, что PCI-E — это серьезная шина, ведь есть программный сли, который работает только через PCI-E, при этом всего на 20-30% медленнее получается, чем при связке через шнурок.

AS>>Копирование все-равно будет, посколько gdi это и так делает. Собирает оно или нет очень маленькие обновления — по идее должно, даже на уровне юзер. На практике же я этого не наблюдал. Поэтому в случае миррор дравера мы вынуждены рисовать 2 раза — один раз в видеопамять, а второй раз в системную. На любые изменения. И не просто копировать — а делать блиттинг, выводить текст и т.д. — т.е. делать заведомо более тормозные операции, чем тупое копирование данных.
AS>>Как я тебе уже тут показал, копирование из системной памяти в системную для PCI-E медленнее, чем из видео в системную. Итого, получается, при собирании все в системную память вместо работы с видео мы имеем:
AS>>1. Любое обновление обрабатывается 2 раза — один раз в видео, другой раз в системную память.

GN>Не так. Модифицируем системную память, и не чаще каждого кадра копируем в видеопамять. Можно копировать только изменения или другие оптимизации применять.

Ага. Т.е., в пределе, изменили один пискел — скопировали кадр. Красиво живем. Нет, текущий вариант DDI, хотя и позволяет некоторым образом кешировать битмапы (для поверхностей есть соотв. флаг), все равно не позволяет это делать нормально для mirror драйвера. То есть, конечно, если хочется большого секса — то можно пробовать, но в этом случае есть риск не сделать проект вообще, не то, что за сколь-либо приемлемое время.

AS>>2. ОБрабатываются _все_ операции, накопление невозможно.
AS>>3. Копирование системная-системная на современных машинах медленнее, чем видео-системная.

GN>Проблема в том, что на одно копирование системная-системная понадобтся 2 других: системная->видео и видео->системная. Или понядобится видео->системная, в то время, как из системной копировать не надо. Нужен скриншот — просто получил указатель в системной памяти и всё.

Нет, не так. У тебя есть 2 копирования — системная-видео и системная-системная, в случае миррор драйвера. Причем это, вообще говоря, не копирования, а конструирования изображения, что, сам понимаешь, обычно в РАЗЫ медленнее.
Итого, 2 конструирования. Причем то, которое в системную память, получается еще и медленнее, чем в видео, поскольку оно может, как ты и говоришь, быть ускорено аппаратно — тут все в руках разработчика драйвера. Великолепно.
В случае же чтения ИЗ видеопамяти у тебя одно конструирования системная-видео (то бишь, эта операция аналогична первому варианту) и одно копирование из видео в системную, причем копирование не при каждой операции DDI, а когда тебе захочется. Таким образом, конструирование из системной в системную память заменяется копированием из видео в системную, что, как ты понимаешь, получается значительно быстрее. А уже если это еще и аппаратно реализовать — ну.. ты понял. Итого — смысла постоянно копировать в системную память я не нашел. Наверное, я тупой

GN>Есть и обратная проблема — сейчас много чего рисуется аппаратно, стало быть — только в видеопамять. То есть я фактически предлагаю отказаться от аппаратного ускорения. Да, я знаю, что это ересь и противоречит пожеланиям инвесторов nVidia

Это и есть ересь. Все, что надо для миррор драйвера — установить свои правила по сбору обновлений. Т.е. кешировать обновления до тех пор, пока ему это надо. А затем давать user коду доступ именно к обновлениям, а не к целиковой back поверхности. А то создается ощущение, что вроде как сделали интерфейс, а когда начинаешь им пользоваться, оказывается, что для своих целей, и уж тем более для нормального взаимодействия с юзер-моде оно не приспособлено вообще. Пока этого не будет сделано нормально в интерфейсе DDI, миррор драйвер пригоден только для сбора регионов обновления и других мелких целей. Точка.

AS>>Ну и где же столь желаемые преймущества? Отвечу. А нету их. По крайней мере, для моих задач — я это тестировал довольно активно Причем различие — ну просто разительное.

GN>Дык правильно, сейчас ведь всё сделано не так, как надо.

... до основания, а затем...

Здравствуйте, Andrew S, Вы писали:

AS>Запись данных группами, например.

Дык Это так и называется. Буржуйский термин — write combining.

AS>В этом случае тоже происходит кеширование в буферах перед записью.

Там происходит накопление данных. После этого данные из этого буфера пишутся один раз.

AS>Да не аппаратный это блиттинг, блин, ну сколько можно. Берем directx, получаем указатель на физическую поверхность, применяем алгоритмы из аллегро — получаем немного _быстрее_ gdi.

В этих алгоритмах память последовательно читается? Тогда понятно. Значит считывается целиком линейка и хранится где-то в буфере (вот это — кеш вне процессора). Буферов этих не много, и при непоследовательном чтении скорость должна упасть. Кеш CPU при рандомном доступе естесственно тоже не помогает, но если доступ "не сильно рандомный", будет намного лучше. Но, конечно, при работе с видеопамятью доступ обычно поледовательный! Красивое решение. А чипсет попробую угадать — nForce Плохо, что даташиты на них не доступны всем желающим


AS>Ага. Т.е., в пределе, изменили один пискел — скопировали кадр.

Зачем же. dirty rectangles можно использовать. ИМХО некоторый аппаратный механизм, который будет отслеживать изменения (не надо по-пиксельно) и потом копировать сам в видеопамять будет значительно проще и дешевле существующих монстров. Еще бы к нему немного памяти, что б он адреса изменений туда сам писал Фактически, смысл видеопамяти получится — кеш для RAMDAC.

Khm a vi chasom ne nazivaete cachirovaniem to chto v BIOS (vrode s pentiumov takoe bilo no mot i ranshe) nazivalos Video BIOS/Memory shadow? Eto sovsem drugaya chtuka. Kstati niche ne dauschaya na sovremennih OS.
A vot Write combining eto da..

А>Khm a vi chasom ne nazivaete cachirovaniem to chto v BIOS (vrode s pentiumov takoe bilo no mot i ranshe) nazivalos Video BIOS/Memory shadow?

Это не то. Так называется отображение video ROM в память. Мимо.

А> Eto sovsem drugaya chtuka. Kstati niche ne dauschaya na sovremennih OS.
А>A vot Write combining eto da..

Write combining это и есть вид кеширования. Уже говорили про это, ну сколько можно. Где формируются пакеты, слово подсказать, как это называется, а?
Никто ведь и не говорил, что данные кэшируются в кэше данных процессора — это по меньшей мере было бы глупо, учитывая затраты на синхронизацию по и без того не слишком быстрой шине. Впрочем, называть это можно как угодно, но сам смысл от этого не изменится.
Вот из мануала асус p2b
http://www.naic.edu/~wapp/DataSheets/ASUS_P2B.pdf#search=%22ASUS%20P2B%20manual%22
стр 46

Посмотрите, как там называется пункт, про который говорим.
Вот, кстати, из терминов:

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

Ну и, что не так то?

Vse tak. Imenno eto ya i pisal v message svoey

AS>>В этом случае тоже происходит кеширование в буферах перед записью.

GN>Там происходит накопление данных. После этого данные из этого буфера пишутся один раз.

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