Конференция "WinAPI" » Заблокировать участок памяти
 
  • dmk © (15.01.18 08:57) [0]
    Можно ли заблокировать участок памяти при использовании потоков?
    Чтобы до определенного момента этот участок не использовался другими потоками.
  • Rouse_ © (15.01.18 12:02) [1]
    https://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx

    Только не понятно, что это тебе даст
  • Игорь Шевченко © (15.01.18 13:19) [2]

    > Можно ли заблокировать участок памяти при использовании
    > потоков?


    EnterCriticalSection/LeaveCriticalSection

    Управление памятью выполняется на уровне процесса, а не потока
  • dmk © (15.01.18 14:28) [3]
    >EnterCriticalSection/LeaveCriticalSection
    Не то немного.

    Тут суть в том, что нужно дождаться выполнения BitBlt и установить флаг окончания вывода. Потоки очень шустрые ребята и портят мне картинку в момент если стопроцентно не дождаться окончания вывода буфера. Поэтому этот кусок памяти надо защитить или установить какой-то маркер, подтверждающий окончание вывода.
    Может пиксел в конце рисовать определенного цвета и проверять есть ли он на DC или нет? Вот думаю как сделать лучше. Сейчас стоит логический флаг. В принципе работает, но иногда проскакивают полоски из-за асинхронности. Вид портят.
    Может копировать в другой буфер в момент протекции и рисовать из него? В приницпе скорость позволяет. В общем буду вечером пробовать.
  • dmk © (15.01.18 14:32) [4]
    Чтобы было понятнее опишу ситуацию детальнее: потоки рисуют со скоростью ~600 fps, а BitBlt крайне медленна. Поэтому потоки портят изображение еще до окончания вывода.
    Вот думаю может Direct2D может помочь? Там вроде даже вертикальная синхронизация есть. Никто не пробовал Direct2D?
  • han_malign © (15.01.18 18:03) [5]

    > Поэтому потоки портят изображение еще до окончания вывода.

    https://msdn.microsoft.com/en-us/library/windows/desktop/dd144844(v=vs.85).aspx
  • dmk © (15.01.18 19:17) [6]
    han_malign ©   (15.01.18 18:03) [5]
    В 10-ку! То что нужно :) Спасибо!
  • Eraser © (16.01.18 12:14) [7]

    > dmk ©   (15.01.18 19:17) [6]

    это не то что нужно, https://msdn.microsoft.com/en-us/library/windows/desktop/ms684256(v=vs.85).aspx


    > Там вроде даже вертикальная синхронизация есть.

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


    > потоки рисуют со скоростью ~600 fps, а BitBlt крайне медленна

    для вывода можно использовать двойную буферизацию, front/back buffer.


    > Никто не пробовал Direct2D?
    >
    >

    конечно пробовал, именно это и нужно использовать, для ленивых в делфи даже удобная обертка есть.
  • dmk © (16.01.18 18:31) [8]
    Eraser ©   (16.01.18 12:14) [7]
    >это не то что нужно
    Да сделал уже. GdiFlush сразу очередь GDI освобождает не позволяя вмешаться другим потокам в буфер. Тем более все это обернуто в CriticalSection. Механизм параллельности у меня работает. Даже потоки на ходу можно отключать/включать для повышения производительности. Я бы дал ссылочку, но ИШ прибъет :)

    >при чем тут вертикальная синхронизация
    В GDI ее просто нет, а очень бы хотелось. Просто мысли вслух.

    >для вывода можно использовать двойную буферизацию, front/back buffer.
    Так и сделано. Пока один буфер выводится, в другом уже рисуется новый кадр.

    >конечно пробовал
    А там свой буфер доступен как в CreateDIBSection ?
  • Eraser © (17.01.18 01:59) [9]

    > dmk ©   (16.01.18 18:31) [8]


    > Тем более все это обернуто в CriticalSection

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


    > А там свой буфер доступен как в CreateDIBSection ?

    там несколько способов, на сколько я помню. например
    https://msdn.microsoft.com/ru-ru/library/windows/desktop/dd371150(v=vs.85).aspx

    но, любые пересечения с CPU - удар по производительности, лучше рисовать средствами самого Direct2D, как можно реже прибегая к маппингу в основную память том или ином виде.
  • Вайрекс (17.01.18 02:36) [10]
    Он же пояснял - нельзя ссылочки на exe-шники.
    А на свой сайт с описанием проекта, скриншотами и тестовыми сборками - уже можно.
    Ну сделайте себе домашнюю страницу хоть на любом Юкозе или Народе, и всё. С:
  • dmk © (17.01.18 05:03) [11]
    >как можно реже прибегая к маппингу в основную память том или ином виде
    У меня CPU-render. Вся математика своя. В этом и суть. Нужен прямой доступ к памяти.
    Так бы я OpenGL использовал и делов то.

    >любые пересечения с CPU - удар по производительности
    Да не. Современные CPU тянут уже как одни из самых первых видюх.
    У меня Core-i7 6950X Extreme Broadwell 3.4 ГГц. Одно ядро как Voodoo 3 2000 примерно тянет. По совокупной производительности 10 ядер думаю побить по производительности Voodoo 5 6000 (Правда без AA). Беда в том, что у CPU очень маленькая пропускная способность памяти. Мне удалось добиться что-то около 5-6 Гб/с под Win10 x64.
    Это полность текстурированная сцена (16k полигонов) 2560x1600 при ~19-20 fps + динамическое диффузное освещение. Так тянет одно ядро. Все 10 ядер тянут ~38-40 fps при 600к полигонов. Потолок для шины. CPU тянет, а пропускная способность памяти низкая. Если снизить до 300к полигонов, то 2560x1600 при ~60 fps ;) Прям пропорция 1 к 2.
  • han_malign © (17.01.18 17:37) [12]

    > > А там свой буфер доступен как в CreateDIBSection ?
    > там несколько способов, на сколько я помню. например

    https://msdn.microsoft.com/en-us/library/windows/desktop/bb174565(v=vs.85).aspx
    - только надо помнить, что оно не всегда DXGI_FORMAT_B8G8R8A8_UNORM
  • dmk © (17.01.18 18:22) [13]
    GetDisplaySurfaceData это что-то типа glReadPixels. Прямого доступа к памяти нет.
    Просто фреймбуфер из видеопамяти копируется. А свой буфер скинуть возможности нет.
  • dmk © (17.01.18 18:29) [14]
    >Он же пояснял - нельзя ссылочки на exe-шники.
    Ссылок на EXE не было. По ссылке шел переход на mail.ru,
    а там уже предоставлялся выбор - скачивать/не скачивать мой RAR-архив.
    Касперский у меня уже лет 15 лицензионный. Вирусов не было за это время. Ни одного.
    Delphi - лицензия. У меня вообще на все лицензия.
    Хостинг Delphimaster от моего EXE не пострадал :)
  • Вайрекс (17.01.18 22:01) [15]
    Технически это всё же считалось ссылкой на exe-шник. Просто находящийся на некотором файлообменнике. И это создавало спорный момент. Это мы вас достаточно знаем, а если случайный кто зайдёт?
    Многие с форума delphimaster.ru будут рады увидеть вашу домашнюю страницу хотя бы на Юкозе/Народе со скриншотами ваших достижений, результами тестов и всем остальным.
    Можно было бы и на SourceForge, но там вроде можно только с открытым кодом. Вы вроде совсем не планируете исходники выкладывать?
  • Eraser © (17.01.18 22:27) [16]

    > dmk ©

    посмотри класс TCanvasD2D (FMX.Canvas.D2D), там полно работающего кода.
  • dmk © (17.01.18 23:07) [17]
    >Вы вроде совсем не планируете исходники выкладывать?
    Так еще нечего выкладывать. Пока первые результаты. Движок на стадии разработки.
    Из альтернатив есть открытые исходнкики Quake/Doom. У меня пока не очень здоровый каркас :)
  • han_malign © (19.01.18 13:08) [18]

    > GetDisplaySurfaceData это что-то типа glReadPixels. Прямого доступа к памяти нет.
    > Просто фреймбуфер из видеопамяти копируется. А свой буфер скинуть возможности нет.

    - это одно из применений, читать нынче можно только из ресурса с D3D11_USAGE_STAGING в который GPU можно попросить что-то скопировать...
    DXGI(Surface) - базовый механизм(в основном где-то внутрях), копать надо отсюда:
    D3D11CreateDevice[AndSwapChain]()
    ID3D11Device::CreateTexture2D({D3D11_TEXTURE2D_DESC::Usage = D3D11_USAGE_...})
    и вот тут как раз оно(то что во всех остальных справках считается уже must know):
    https://msdn.microsoft.com/en-us/library/windows/desktop/ff476259(v=vs.85).aspx

    а под W10 - появилась еще более прикольная вещь
    ID3D11Device3::ReadFromSubresource()/ID3D11Device3::WriteToSubresource()

    З.Ы. я просто пока еще сам копаю, применительно как раз к захвату...
 
Конференция "WinAPI" » Заблокировать участок памяти
Есть новые Нет новых   [118241   +25][b:0][p:0.001]