Сообщение Re[44]: Еще от 13.06.2017 18:46
Изменено 13.06.2017 18:55 ononim
Re[44]: Еще
CS>>>а "by drawing bitmaps using hardware" это и есть как я понимаю BitBlt ускоренный ...
CS>>>О чём ты вообще?
O>>Понял, надо примеры кода из DDK.
CS>Забей, не нужны мне те примеры. То что драйвера могут у себя внутри использовать фрагменты видео памяти для своих нужд, понятно.
CS>Т.е. то что известно как texture. Но к GDI это не имеет отношения напрямую.
Нет уж. Я уже накропал. Примеры кода из DDK:
CS>Еще раз:
O>> Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи
CS>Фень Юань:
CS>DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space.
CS>Что из этого верно?
Здесь отсутствует may и второй вариант, где могут хранится DDB. Юань ошибся. Или просто недоговорил. Впрочем, для современных версий винды, тут все верно. Потому что все вышеописанное — это XPDM, из WDDM это все выкинули. Просто чтобы через несколько лет продавать эту фичу по новой, под новыми баззвордами и с новым софтом, который только и поддерживает эту новую обертку. Все ради продаж. Кушайте.
CS>>>О чём ты вообще?
O>>Понял, надо примеры кода из DDK.
CS>Забей, не нужны мне те примеры. То что драйвера могут у себя внутри использовать фрагменты видео памяти для своих нужд, понятно.
CS>Т.е. то что известно как texture. Но к GDI это не имеет отношения напрямую.
Нет уж. Я уже накропал. Примеры кода из DDK:
. o O ( Самый интересный код там лежит в disp/gdi/heap.c - видать та самая куча, про которую твой любимый Юань писал. Как думаешь, зачем производителю видеодрайвера было писать свою кучу, а не юзать [url=https://msdn.microsoft.com/en-us/library/windows/hardware/ff567267(v=vs.85).aspx]готовую[/url], как они делали в предыдущей версии своего драйвера, которую я тут приводить не буду по очевидной причине;). Итак. )
// HBITMAP DrvCreateDeviceBitmap
//
// Function called by GDI to create a device-format-bitmap (DFB). We will
// always try to allocate the bitmap in off-screen; if we can't, we simply
// fail the call and GDI will create and manage the bitmap itself.
.....
poh = pohAllocate(ppdev, NULL, cx, cy, 0);
.. o O (смотрим на pohAllocate, отличный кстати префикс, надо взять на заметку)
* OH* pohAllocate
*
* Allocates a rectangle in off-screen memory.
...
* FLOH_MAKE_PERMANENT
*
* Allocates an off-screen rectangle that can never be booted
* of the heap. It's the caller's responsibility to manage
* the rectangle, which includes what to do with the memory in
* DrvAssertMode when the display is changed to full-screen
* mode.
*
* Default
*
* Allocates a 'discardable' off-screen rectangle for a DFB that may
* be kicked out of off-screen if the space is needed.
вот эти состояния битмапа, про которые vdimas рассказывал, о том что он может быть выкинут из off-screen куда? Не в on-screen конечно же, а в не-off-screen память. В обычную, то есть, память.
Внутри pohAllocate дохренища вычислений, но все в итоге сводится к указателю, взятому из по офсету относительно базы ppdev->pjScreen:
pohThis->pvScan0 = ppdev->pjScreen +
( ( pohThis->pixOffset+
pohThis->y * pohThis->lPixDelta +
pohThis->x)
<< ppdev->cPelSize );
Что же такое pjScreen и pixOffset? За инициализацией первой придется сходить в соседний файлик. Тут все просто:
ppdev->pjScreen = (BYTE*) VideoMemoryInfo.FrameBufferBase;
а за pixOffset вкрнемся назад в heap.c:
pixOffset = (DWORD)(fp >> ppdev->cPelSize);
где fp:
fp = mmrq.pMem;
То есть память для GDI битмапа выделяется по хитровысчитанному смещению от VideoMemoryInfo.FrameBufferBase. Ну и дойдем уж совсем до конца. Что же такое FrameBufferBase?
А за этим придется выскочить из нашей уютненькой директории disp/gdi/ и перейти к mini\perm3io.c. Где нас жоско встречает хардвар:
case IOCTL_VIDEO_MAP_VIDEO_MEMORY:
memoryInformation->VideoRamBase = ((PVIDEO_MEMORY)
(RequestPacket->InputBuffer))->RequestedVirtualAddress;
...
memoryInformation->FrameBufferBase = memoryInformation->VideoRamBase;
тада. VideoRamBase - это уже не непонятная off-screen memory, это уже конкретная Video RAM.
фигачим в альма матер - мсдн, читаем про [url=https://msdn.microsoft.com/en-us/library/windows/hardware/ff567812(v=vs.85).aspx]IOCTL_VIDEO_MAP_VIDEO_MEMORY[/url]:
Maps the video hardware frame buffer and video RAM into the virtual address space of the requester. Miniport drivers are required to handle this IOCTL and to map all video memory in the caller's address space with VideoPortMapMemory.
все, привет видеопамять видеоадаптера.CS>Еще раз:
O>> Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи
CS>Фень Юань:
CS>DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space.
CS>Что из этого верно?
Здесь отсутствует may и второй вариант, где могут хранится DDB. Юань ошибся. Или просто недоговорил. Впрочем, для современных версий винды, тут все верно. Потому что все вышеописанное — это XPDM, из WDDM это все выкинули. Просто чтобы через несколько лет продавать эту фичу по новой, под новыми баззвордами и с новым софтом, который только и поддерживает эту новую обертку. Все ради продаж. Кушайте.
Re[44]: Еще
CS>>>а "by drawing bitmaps using hardware" это и есть как я понимаю BitBlt ускоренный ...
CS>>>О чём ты вообще?
O>>Понял, надо примеры кода из DDK.
CS>Забей, не нужны мне те примеры. То что драйвера могут у себя внутри использовать фрагменты видео памяти для своих нужд, понятно.
CS>Т.е. то что известно как texture. Но к GDI это не имеет отношения напрямую.
Нет уж. Я уже накропал. Примеры кода из DDK:
CS>Еще раз:
O>> Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи
CS>Фень Юань:
CS>DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space.
CS>Что из этого верно?
Здесь отсутствует may и второй вариант, где могут хранится DDB. Юань ошибся. Или просто недоговорил. Впрочем, тысячи взращенных китайцев индусов претворили это недоговорку в жизнь и для современных версий винды тут все верно. Потому что все вышеописанное — это XPDM, из WDDM это все выкинули. Просто чтобы через несколько лет продавать эту фичу по новой, под новыми баззвордами и с новым софтом, который только и поддерживает эту новую обертку. Все ради продаж. Кушайте.
CS>>>О чём ты вообще?
O>>Понял, надо примеры кода из DDK.
CS>Забей, не нужны мне те примеры. То что драйвера могут у себя внутри использовать фрагменты видео памяти для своих нужд, понятно.
CS>Т.е. то что известно как texture. Но к GDI это не имеет отношения напрямую.
Нет уж. Я уже накропал. Примеры кода из DDK:
. o O ( Самый интересный код там лежит в disp/gdi/heap.c - видать та самая куча, про которую твой любимый Юань писал. Как думаешь, зачем производителю видеодрайвера было писать свою кучу, а не юзать [url=https://msdn.microsoft.com/en-us/library/windows/hardware/ff567267(v=vs.85).aspx]готовую[/url], как они делали в предыдущей версии своего драйвера, которую я тут приводить не буду по очевидной причине;). Итак. )
// HBITMAP DrvCreateDeviceBitmap
//
// Function called by GDI to create a device-format-bitmap (DFB). We will
// always try to allocate the bitmap in off-screen; if we can't, we simply
// fail the call and GDI will create and manage the bitmap itself.
.....
poh = pohAllocate(ppdev, NULL, cx, cy, 0);
.. o O (смотрим на pohAllocate, отличный кстати префикс, надо взять на заметку)
* OH* pohAllocate
*
* Allocates a rectangle in off-screen memory.
...
* FLOH_MAKE_PERMANENT
*
* Allocates an off-screen rectangle that can never be booted
* of the heap. It's the caller's responsibility to manage
* the rectangle, which includes what to do with the memory in
* DrvAssertMode when the display is changed to full-screen
* mode.
*
* Default
*
* Allocates a 'discardable' off-screen rectangle for a DFB that may
* be kicked out of off-screen if the space is needed.
вот эти состояния битмапа, про которые vdimas рассказывал, о том что он может быть выкинут из off-screen куда? Не в on-screen конечно же, а в не-off-screen память. В обычную, то есть, память.
Внутри pohAllocate дохренища вычислений, но все в итоге сводится к указателю, взятому из по офсету относительно базы ppdev->pjScreen:
pohThis->pvScan0 = ppdev->pjScreen +
( ( pohThis->pixOffset+
pohThis->y * pohThis->lPixDelta +
pohThis->x)
<< ppdev->cPelSize );
Что же такое pjScreen и pixOffset? За инициализацией первой придется сходить в соседний файлик. Тут все просто:
ppdev->pjScreen = (BYTE*) VideoMemoryInfo.FrameBufferBase;
а за pixOffset вкрнемся назад в heap.c:
pixOffset = (DWORD)(fp >> ppdev->cPelSize);
где fp:
fp = mmrq.pMem;
То есть память для GDI битмапа выделяется по хитровысчитанному смещению от VideoMemoryInfo.FrameBufferBase. Ну и дойдем уж совсем до конца. Что же такое FrameBufferBase?
А за этим придется выскочить из нашей уютненькой директории disp/gdi/ и перейти к mini\perm3io.c. Где нас жоско встречает хардвар:
case IOCTL_VIDEO_MAP_VIDEO_MEMORY:
memoryInformation->VideoRamBase = ((PVIDEO_MEMORY)
(RequestPacket->InputBuffer))->RequestedVirtualAddress;
...
memoryInformation->FrameBufferBase = memoryInformation->VideoRamBase;
тада. VideoRamBase - это уже не непонятная off-screen memory, это уже конкретная Video RAM.
фигачим в альма матер - мсдн, читаем про [url=https://msdn.microsoft.com/en-us/library/windows/hardware/ff567812(v=vs.85).aspx]IOCTL_VIDEO_MAP_VIDEO_MEMORY[/url]:
Maps the video hardware frame buffer and video RAM into the virtual address space of the requester. Miniport drivers are required to handle this IOCTL and to map all video memory in the caller's address space with VideoPortMapMemory.
все, привет видеопамять видеоадаптера.CS>Еще раз:
O>> Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи
CS>Фень Юань:
CS>DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space.
CS>Что из этого верно?
Здесь отсутствует may и второй вариант, где могут хранится DDB. Юань ошибся. Или просто недоговорил. Впрочем, тысячи взращенных китайцев индусов претворили это недоговорку в жизнь и для современных версий винды тут все верно. Потому что все вышеописанное — это XPDM, из WDDM это все выкинули. Просто чтобы через несколько лет продавать эту фичу по новой, под новыми баззвордами и с новым софтом, который только и поддерживает эту новую обертку. Все ради продаж. Кушайте.