> thought this was what it was intended to handle, that is, define a surface
in PCI or AGP memory and allow the user to directly access it.
Directly? Are you sure?
IIRC DDraw only allowed the apps to manipulate off-screen videocard memory - a) create a HDC on it and draw on it using GDI b) run
BitBlts between screen/off-screen video memory/system memory (CreateCompatibleDC stuff).
Without DDraw, only the GDI driver could use the off-screen videocard memory (to cache icons and font glyphs like S3 Trio did) - and
no apps can control the way the driver uses it.
But about directly mapping offscreen memory to the user address space - are you sure?
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Absolutely. DDraw lets user mode application access the display surfaces
directly (look at IDirectDrawSurface7::Lock for example). The surface could
be an overlay surface, a backbuffer surface (for page flipping) or even the
primary surface itself. Anyway, it is usually located in device memory
(although I guess sometimes it could be in the AGP aperture).
Now, when I think about it, this partially invalidates the point made by
Mark Roddy that an user mode application could slow down the system if
allowed to read directly from PCI memory. It seems that applications are
already allowed to do that using DDraw. Of course the frame buffer is
prefetchable and possibly write-combined, but reading from PCI is still very
slow (at least compared to writing).
-tzvetan
----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Saturday, October 27, 2001 1:40 PM
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?
> > thought this was what it was intended to handle, that is, define a
surface
> > in PCI or AGP memory and allow the user to directly access it.
>
> Directly? Are you sure?
>
> IIRC DDraw only allowed the apps to manipulate off-screen videocard
memory - a) create a HDC on it and draw on it using GDI b) run
> BitBlts between screen/off-screen video memory/system memory
(CreateCompatibleDC stuff).
>
> Without DDraw, only the GDI driver could use the off-screen videocard
memory (to cache icons and font glyphs like S3 Trio did) - and
> no apps can control the way the driver uses it.
>
> But about directly mapping offscreen memory to the user address space -
are you sure?
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@jupiter.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Now, when I think about it, this partially invalidates the point made by
Mark Roddy that an user mode application could slow down the system if
allowed to read directly from PCI memory. It seems that applications are
already allowed to do that using DDraw. Of course the frame buffer is
prefetchable and possibly write-combined, but reading from PCI is still very
slow (at least compared to writing).
-tzvetan
No, I absolutely don’t think it does invalidate Mark’s argument, and in
fact when NT4.0 was being designed there was quite a bit of debate as to
whether moving the video subsystem around and allowing a user mode DirectX
app to access video memory directly was not opening a gaping security hole
in the OS. This was not possible on NT 3.51. I am not convinced it has
not opened a hole. However, with AGP this is a greatly reduced problem as
AGP is essentially a separate PCI bus and the PCI bus and AGP don’t
actually contend with each other right?
Bill M.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Absolutely. DDraw lets user mode application access the display surfaces
directly (look at IDirectDrawSurface7::Lock for example).
Are you sure it does not do any double buffering?
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com