Sven Luther wrote:
On Mon, Jan 20, 2003 at 09:30:50AM -0800, Ian Romanick wrote:
Sven Luther wrote:
On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
1. Single-copy textures
Right now each texture exists in two or three places. There is a copy
in on-card or AGP memory, in system memory (managed by the driver), and
in application memory. Any solution should be able to eliminate one or
two of those copies.
...
BTW, since you are looking into this, have you thought about graphic
chips which can do MMU like tricks. I am not sure if the current set of
graphic chips the DRI runs on do this kind of stuff, but they well may
in the future. I know the gamma drm module use the gamma's virtual
memory table to not need to do virtual<->physical conversion. But more
importantly to you, altough there is not yet a DRI driver for it, the
3Dlabs permedia3 can use virtual memory for its textures. That is you
can basically set up the graphic boards memory as a cache memory, and
have the the MMU-like unit swap the memory pages from host memory, using
i suppose its own page replacement algorithm.
The only chips that I know of that support this technology are the
various, recent 3dlabs chips. They have a number of patents on this
technology, and, AFAIK, they have no intention of licensing it to anyone
for all the tea in China.
Well, sure ...
But that is not reason for not supporting it or something, who knows,
Creative and 3Dlabs may release a consumer board supporting those next
year, and there will be lot of those around.
Right, but without documentation, it's hard to know what we would need
to do to support it or what we would need to NOT do to prevent
supporting it.
And you don't think other manufacturer may develop their own technology
doing this ? virtual memory is hardly that inovative that a patent can
block ATI or NVidia from developping a similar issue, after all it is
used since years in CPUs.
Not to get into too much of a tangent, virtual memory is not novel.
Virtual memory for textures used by a graphics processor is...at least
acording to the USPTO. I haven't read the patents and I don't even know
which ones they are, so I can't comment on this particular aspect any
further.
I agree that it is a good idea to keep virtual textures in mind, but,
since we don't have any hardware documentation for it, it will be
difficult to do more than that.
Mmm, i know of at least 3 persons who have the docs for the pm3 apart
from me, sure, you need to sign an NDA, but who does not these days, i
also have the hardware for it, and am planning to do DRI work for those
in the future, and one of those 3 persons has expressed interrest on
having DRI enabled for the pm3, and i did begin some work for the gamma
+ pm3 combo.
Your input would be very helpful, then. Is there any chance you could
port the gamma driver to use the texmem interface in the texmem-0-0-1
branch? :) That's one of the few drivers that I had given up hope on
seeing ported. The other is the tdfx driver.
That said, sure, there is not really all that much i can contribute to
this discution, since i am under NDA, but, well, virtual memory for
graphic chips work all the same as virtual memory for CPUs so i guess it
is easy to take those things into account also.
Fair enough. You'll have to be careful. :)
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
