Perhaps this is a dumb question, but is there any particular reason why
you don’t segregate into different builds? Why is it necessary to cram
everything into a single driver binary?
Chuck
----- Original Message -----
From: “Calvin Guan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, November 19, 2003 2:26 AM
Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon
Buffer
> To add what Alberto said, our miniport has to support a huge list of
desktop
> and mobile ASICs. Each asic has different video BIOS to handle. The
most
> headache to me is the mobile ASICs on notebooks. Different OEMs have
> different LCD panels. And different OEM requires different features.
Also,
> there are many awesome features implemented in the miniport.
>
> Instead of “miniport”, I would call it a griantport. It’s even larger
than
> ntfs.sys in size. I really miss the day when I was with NDIS miniport
that I
> wrote every single line of code for my driver-
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Tuesday, November 18, 2003 10:40 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon
> Buffer
>
>
> There’s a lot of functionality in a Miniport, it does most of the
> non-time-critical functions of driving a graphics subsystem. Some
people put
> support for several different chips in the same piece of code, but
even if
> you only have one chip, your Miniport may end up being pretty big.
Some of
> the actual space is taken by tables, for example, every graphics
driver
> supports several resolutions and bit depths, and one must keep tables
of
> register settings that set up your chip to the corresponding video
mode.
> There’s also tables with configuration and capability settings, and
they
> take space. You must handle initialization, capabilities, mode
changes,
> power management, multiple screens, resource management, you name it.
You
> must also manage the retrace interrupt. In WinXP there’s even new
support
> for DMA. BTW, Calvin, do you guys implement and use the new DMA calls
that
> WinXP added to the Miniport ?
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Monday, November 17, 2003 10:14 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateC
> ommonBuffer
>
>
> Wow! Am I right that this huge amount of code is due to supporting
all
> videocard hardware models and maintaining the backward compatibility,
so
> that the newest binary can work with even the old hardware?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com mailto:xxxxx
> http://www.storagecraft.com http:
>
>
> ----- Original Message -----
> From: Calvin Guan mailto:xxxxx
> To: Windows System Software Devs Interest
mailto:xxxxx List
>
> Sent: Tuesday, November 18, 2003 4:02 AM
> Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateC
> ommonBuffer
>
>
> Well, video miniport is a lot of code-:).
> Our Radeon x86 free build miniport (ati2mtag.sys) is more than 600k.
the chk
> build doesn’t fit into a floppy…
>
> Calvin Guan, Software Developer xxxxx@nospam.ati.com
> mailto:xxxxx
> SW2D-Radeon NT Core Drivers
> ATI Technologies Inc.
> 1 Commerce Valley Drive East
> Markham, Ontario, Canada L3T 7X6
> Tel: (905) 882-2600 Ext. 8654
> Find a driver: http://www.ati.com/support/driver.html
> http:
>
>
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com
> mailto:xxxxx]
> > Sent: Monday, November 17, 2003 7:20 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateC
> > ommonBuffer
> >
> >
> > > Miniport. For example, look at the Permedia P3 sample in
> > the DDK, the DMA
> > > rendering is handled in the driver and not in the Miniport.
> > There’s not
> >
> > Then why the nVidia’s miniport is THIS huge (500KB or such)?
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com http:
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> http:
> >
> > You are currently subscribed to ntdev as: xxxxx@ati.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ati.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the
named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></http:></http:></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>