[Dri-devel] Cepte Eglence Asil Simdi Basliyor!
Title: MELODI GRAFIK DUYURU www.melodilerim.com / www.grafiklerim.com Merhaba, Melodilerim.Com ve Grafiklerim.Com'dan haberiniz var mý ? Cep telefonlarýnýz için en geniþ melodi arþivi, 1800 melodi...Üstelik sürekli güncelleniyor. Ýþte "Ne Oldu Can - Kayahan" ve "Sen Yoluna Ben Yoluma - Çelik"...Daha albümleri taptazeyken melodileri Melodilerim.Com'da ! Cep telefonlarýnýzýn ekranlarýný þenlendirecek binlerce logo, resimli mesaj, extra-large logo ve hareketli resimler...Hepsi Grafiklerim.Com'da ! Üstelik bu melodi ve logolar cebinize tek bir mesajla çok kolay geliyor... Rengarenk, pýrýl pýrýl sitelerimiz sizleri bekliyor ! Mutlu Günler SMSNET Ekibi Melodi isteðinde bulunmak istiyorum!Resmimi telefonumda görmek istiyorum! Yardým hattýmýz: 0 312 2865891 (her gün 9.00 - 19.30 arasý) Duyuru listemizden çýkmak için lütfen týklayýnýz...To be removed from our mailing list, please click here... --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] new years safety 903
Title: NSW2003 Norton System Works Suite 2003 ALL NEW Improved Version - Professional Edition 5 Amazing tools come with this valued at over $300 in stores. We have a limited offer for only $39.95! It was stated in various magazines that the Holiday season of 2002 has seen more personal computer viruses & failures than ever before! This will solve all your problems and protect you in the future! A must have! Click Here Now Click to unsubscribe --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri-devel your Guaranteed Downline! fu
dri-develdri-develdri-develN¬HSDMéX¬²'²Þu¼ ¬-yÊ&Rw^®ËZØhÂÚ)®^rܨº·.²Ú&z»)z»(©bú+«b¢vòjezg§¶)àI"è*.¬ Zry´®÷« X«zÚ zÚ.¬TD8ZÂ×¥§!xk¢uèm¶ÿiÛ,¢êÜyú+éÞ·÷ ¸§þ··¶m ¬4Óo^:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
Re: [Dri-devel] [ANNOUNCE] First Version of AGPGART 2.0 API documentavailable in agpgart module in repository
I finally got around to reading the documentation. Other than a couple trivial typos and such, I only have one question. In the section on AGPIOC_BIND, you say "Previous to the AGP 3.0 specificatin, it was a general assumption that the agp page size would be fixed at 4096 KB." Did you actually mean KB there, or should it be "4096 bytes"? --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] CyberBlade/i1 drivers (Was: Freeing...)
I've been following this thread very closely because I just order a VIA Mini-ITX motherboard (see http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a MP3/VCD/DVD TvOut media player + router + ... Eventually I also want to turn it into a Linux video game console! ;-) And guess what? It comes with a onboard Trident CyberBlade i1. It seems that Trident has no Linux 3D drivers, so there is no fish to give, but they happily supply a fishing stick, as the chip specification is freely available from http://www.viavpsd.com/products/Manual/DS8601A182.pdf . Alan, what chips are supported in the trident-0-0-1-branch and what is their status? Regards, José Fonseca PS: Initially I was planning to buy a Xbox and put Linux on it for this same end, but this is much more interesting! PPS: My enthusiasm is huge but my free time is tiny, don't hold your breath waiting for me to do anything. Help if you are interested! __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] CyberBlade/i1 drivers (Was: Freeing...)
On Thu, Jan 16, 2003 at 07:59:11PM +, José Fonseca wrote: > I've been following this thread very closely because I just order a VIA > Mini-ITX motherboard (see > http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a > MP3/VCD/DVD TvOut media player + router + ... > Eventually I also want to turn it into a Linux video game console! ;-) > > And guess what? It comes with a onboard Trident CyberBlade i1. > > It seems that Trident has no Linux 3D drivers, so there is no fish to > give, but they happily supply a fishing stick, as the chip specification is > freely available from > http://www.viavpsd.com/products/Manual/DS8601A182.pdf . > > Alan, what chips are supported in the trident-0-0-1-branch and what is > their status? Primarily targetting at the CyberBlade/XP series, but hoping to do all of them at some point. Alan. --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] CyberBlade/i1 drivers (Was: Freeing...)
José Fonseca wrote: I've been following this thread very closely because I just order a VIA Mini-ITX motherboard (see http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a MP3/VCD/DVD TvOut media player + router + ... Eventually I also want to turn it into a Linux video game console! ;-) And guess what? It comes with a onboard Trident CyberBlade i1. It seems that Trident has no Linux 3D drivers, so there is no fish to give, but they happily supply a fishing stick, as the chip specification is freely available from http://www.viavpsd.com/products/Manual/DS8601A182.pdf . Ack. That looks like a pretty difficult document to work from -- a challenge of the mach64 order to say the least... Seems to be a g400/r128/tnt/i810 type chip, though. It's hard to tell from the document, but there really did seem to be a lot of detail missing. Keith --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] CyberBlade/i1 drivers (Was: Freeing...)
On Thu, Jan 16, 2003 at 09:42:01PM +, Keith Whitwell wrote: > José Fonseca wrote: > >I've been following this thread very closely because I just order a VIA > >Mini-ITX motherboard (see > >http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a > >MP3/VCD/DVD TvOut media player + router + ... > >Eventually I also want to turn it into a Linux video game console! ;-) > > > >And guess what? It comes with a onboard Trident CyberBlade i1. > > > >It seems that Trident has no Linux 3D drivers, so there is no fish to > >give, but they happily supply a fishing stick, as the chip specification is > >freely available from > >http://www.viavpsd.com/products/Manual/DS8601A182.pdf . > > Ack. That looks like a pretty difficult document to work from -- a > challenge of the mach64 order to say the least... It is. And all the trident docs I've got are like that. :( > Seems to be a g400/r128/tnt/i810 type chip, though. It's hard to tell from > the document, but there really did seem to be a lot of detail missing. The XP is better too. Alan. --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] what happened to cvs at sourceforge?
Hello! anytime I try to update my local copy of DRI from cvs I get a "connection refused". On the sourceforge website I found nothing about it. Did they change something or are they (sourceforge) working to fix the problem? best regards, Andreas --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] what happened to cvs at sourceforge?
Many SF users are reporting the same problem. Their CVS servers have been broken for some time. TTimo On Thu, 16 Jan 2003 23:03:46 +0100 Andreas Stenglein <[EMAIL PROTECTED]> wrote: > Hello! > > anytime I try to update my local copy of DRI from cvs I get a > "connection refused". > > On the sourceforge website I found nothing about it. > Did they change something or are they (sourceforge) working to fix > the problem? > > best regards, > Andreas > > > --- > This SF.NET email is sponsored by: Thawte.com > Understand how to protect your customers personal information by implementing > SSL on your Apache Web Server. Click here to get our FREE Thawte Apache > Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [ANNOUNCE] First Version of AGPGART 2.0 API documentavailable in agpgart module in repository
Ian, I meant 4096 bytes, I'll fix it. Btw, you wouldn't have happened to note where the typos were did you? If you did could you forward the sections where the typos were to me? -Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Romanick Sent: Thursday, January 16, 2003 1:34 PM To: DRI developer's list Subject: Re: [Dri-devel] [ANNOUNCE] First Version of AGPGART 2.0 API documentavailable in agpgart module in repository I finally got around to reading the documentation. Other than a couple trivial typos and such, I only have one question. In the section on AGPIOC_BIND, you say "Previous to the AGP 3.0 specificatin, it was a general assumption that the agp page size would be fixed at 4096 KB." Did you actually mean KB there, or should it be "4096 bytes"? --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] CyberBlade/i1 drivers (Was: Freeing...)
Keith Whitwell wrote: José Fonseca wrote: I've been following this thread very closely because I just order a VIA Mini-ITX motherboard (see http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a MP3/VCD/DVD TvOut media player + router + ... Eventually I also want to turn it into a Linux video game console! ;-) And guess what? It comes with a onboard Trident CyberBlade i1. It seems that Trident has no Linux 3D drivers, so there is no fish to give, but they happily supply a fishing stick, as the chip specification is freely available from http://www.viavpsd.com/products/Manual/DS8601A182.pdf . Ack. That looks like a pretty difficult document to work from -- a challenge of the mach64 order to say the least... Seems to be a g400/r128/tnt/i810 type chip, though. It's hard to tell from the document, but there really did seem to be a lot of detail missing. I would put it at the low end of that group. No stencil buffer, 256x256 max texture, single texture unit (!), no support for MODULATE, DECAL, ADD, or COMBINE (unless some of these are possible w/the undocumented ROP3 code). I noticed in the document that it supports DirectX, but there is NO mention of OpenGL. Hmm... --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] what happened to cvs at sourceforge?
On Thu, 2003-01-16 at 14:03, Andreas Stenglein wrote: > anytime I try to update my local copy of DRI from cvs I get a > "connection refused". > > On the sourceforge website I found nothing about it. > Did they change something or are they (sourceforge) working to fix > the problem? SF Site status: http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] what happened to cvs at sourceforge?
Timothee Besset <[EMAIL PROTECTED]> writes: > Many SF users are reporting the same problem. Their CVS servers have been > broken for some time. > > TTimo > > On Thu, 16 Jan 2003 23:03:46 +0100 > Andreas Stenglein <[EMAIL PROTECTED]> wrote: > >> Hello! >> >> anytime I try to update my local copy of DRI from cvs I get a >> "connection refused". >> >> On the sourceforge website I found nothing about it. >> Did they change something or are they (sourceforge) working to fix >> the problem? http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#cvs Quote: (2003-01-14 14:04:19) As of 2003-01-14, pserver-based CVS repository access and ViewCVS (web-based) CVS repository access have been taken offline as to stabilize CVS server performance for developers. These services will be re-enabled as soon as the underlying scalability issues have been analyzed and resolved (as soon as 2003-01-15, if possible). Additional updates will be posted to the Site Status page as they become available. Your patience is appreciated. // Jarno --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] what happened to cvs at sourceforge?
thanks a lot! Am 2003.01.16 23:31:23 +0100 schrieb(en) Eric Anholt: SF Site status: http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] CyberBlade/i1 drivers (Was: Freeing...)
Ian Romanick wrote: Keith Whitwell wrote: José Fonseca wrote: I've been following this thread very closely because I just order a VIA Mini-ITX motherboard (see http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a MP3/VCD/DVD TvOut media player + router + ... Eventually I also want to turn it into a Linux video game console! ;-) And guess what? It comes with a onboard Trident CyberBlade i1. It seems that Trident has no Linux 3D drivers, so there is no fish to give, but they happily supply a fishing stick, as the chip specification is freely available from http://www.viavpsd.com/products/Manual/DS8601A182.pdf . Ack. That looks like a pretty difficult document to work from -- a challenge of the mach64 order to say the least... Seems to be a g400/r128/tnt/i810 type chip, though. It's hard to tell from the document, but there really did seem to be a lot of detail missing. I would put it at the low end of that group. No stencil buffer, 256x256 max texture, single texture unit (!), no support for MODULATE, DECAL, ADD, or COMBINE (unless some of these are possible w/the undocumented ROP3 code). I noticed in the document that it supports DirectX, but there is NO mention of OpenGL. Hmm... I noticed on page 4 (pdf file page 10) under "General Graphics Capabilities", the last item refers to an OpenGL ICD API. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mga400 lockups with X-4.2, fixed in 4.3?
Hi, since more than 9 months, I experience lockups in DRI 3d mor with my matrox G400 and the X-4.2 server. [drm] AGP 0.99 on VIA Apollo KX133 @ 0xd000 64MB [drm] Initialized mga 3.0.2 20010321 on minor 0 They only happen in complex games (q3a, ut, mutantstorm) normally the machine is totally frozen, not even the sysrq keys work and no messages are logged. I have an Athlon-600 VIA VT8371 [KX133] (rev 02) board and the machine has no other stability issues and would run for months, if I didn't use these games from time to time... The kernel has been upgraded several times to no avail. Do you think a newer mga driver would be more stable? Would I have to upgrade X as well? Should I rather wait for X-4.3? F'up to poster,... -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE) --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] The next round of texture memory management...
What follows is the collected requirements for the new DRI memory manager. This list is the product of several discussions between Brian, Keith, Allen, and myself several months ago. After the list, I have included some of my thoughts on the big picture that I see from these requirements. 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. If the driver-tracked copy in system memory is eliminated, care must be taken when the texture needs to be removed from on-card / AGP memory. Additionally, changes to the texture image made via glCopyTexImage must not be lost. It may be possible to eliminate one copy of the texture using APPLE_client_storage. A portion of this could be done purely in Mesa. If the user supplied image matches the internal format of the texture, then the driver can use the application's copy of the texture in place of the driver's copy. Modulo implementation difficulties, it may even be possible to use the pages that hold the texture as backing store for a portion of the AGP aperture. The is the only way to truly achieve single-copy textures. The implementation may prove too difficult on existing x86 systems to be worth the effort. This functionality is available in MacOS 10.1, so the same difficulties may not exist on Linux PPC. 2. Share texture memory among multiple OpenGL contexts Texture memory is currently shared by all OpenGL contexts. That is, when an OpenGL context switch happens it is not necessary to reload all textures. The texture manager needs to continue to use a paged memory model (as opposed to a segmented memory model). 3. Accommodate other OpenGL buffers The allocator should also be used for allocating vertex buffers, render targets (pbuffers, back-buffers, depth-buffers, etc.), and other buffers. This can be useful beyond supporting SGIX_pbuffer, ARB_vertex_array_objects, and optimized display lists. Dynamically allocating per-context depth and back-buffers will allow multiple Z depths be used at a time (i.e., 16-bit depth-buffer for one window and 24-bit depth-buffer for another) and super-sampling FSAA. 4. Support texture pseudo-render targets Accelerating some OpenGL functions, such as glCopyTexImage, SGIS_generate_mipmaps, and ARB_render_texture, may require special support and consideration. 5. Additional AGP related issues There may be cases where textures need to be moved back-and-forth between AGP and on-card memory. For example, a texture might reside in AGP memory, and an operation may be requested that requires that the texture be in on-card memory. 6. Additional texture formats and layouts Compressed, 1D, 3D, cube map, and non-power-of-two textures need to be supported in addition to "traditional" 2D power-of-two textures. 7. Allen Akin's pinned-texture proposal If we ever expose memory management to the user (beyond texture priorities) we want to be sure our allocator is designed with this in mind. 8. Device independence As much as possible, the source code for the memory manager should live somewhere device independent. This is both for the benefit of newly developed drivers and for maintaining existing drivers. * My Thoughts * There are really only two radical departures from the existing memory manager. The first is using the memory manager for non-texture memory objects. The second, which is partially a result of the first, is the need to "pin" objects. It would not do to have one context kick another context's depth-buffer out of memory! My initial thought on how to accomplish this was to move the allocator into the kernel. There would be a low-level allocator that could be used for non-texture buffers and a way to create textures (from data). In the texture case, the kernel would only allocate memory when a texture was used. In stead of using the actual texture address in drawing command streams, the user-level driver would insert texture IDs. The kernel would use these IDs to map to real texture addresses. The benefit is that all memory management would be handled by a single omniscient execution context (the kernel). The downside is that it would move a LOT of code into the kernel. It would be almost entirely OS and device independent, but there would likely be a lot of it. After talking with Jeff Hartmann in IRC on 1/13, I started thinking about all of this again. Jeff had some serious reservations about moving that volume of code into the kernel, and he believed that all of the requirements could be met by a purely user-space implementation. After thinking about things some more, I'm starting to agree. What follows is a fairly random series of thoughts on how a user-space memory manager could be made to work. I believe that everything could be do
[Dri-devel] Get it! ph
dri-devel,ifkecljsbsusbeoohnghyurimnkxdri-devel
[EMAIL PROTECTED]##randomdri-devel
ifkecljsbsusbeoohnghyurimnkxifkecljsbsusbeoohnghyurimnkxifkecljsbsusbeoohnghyurimnkxdri-devel
[EMAIL PROTECTED]##randomdri-devel
ifkecljsbsusbeoohnghyurimnkxifkecljsbsusbeoohnghyurimnkxáÄ
4DÞ¨¥Ë)¢{(ç[É8ZÂ×¢e'uê쵩Ý-¢èµç-Ê«rë-¢g«²«²Ú)ߢ¹¶*'o(¦¦W¦z{b.ò¢êÀ¥§!ygIêïz°¥É!z·¢¢êÅDA
¬-x
Zrº'^Ûiÿö²Ê.Ç¢¸ ërëyØ«yËiØZÃM6õéî'^½éfj)b b²ÐëׯzYb²Û,¢êÜyú+éÞ¶m¦Ïÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~Ý®'^½é
Re: [Dri-devel] The next round of texture memory management...
On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote: > > 1. In a scheme like this, how could processes be forced to update the > can-swap bits on blocks that they own? Should it even be possible for one process to swap out other processes' context data? Alternatively (forgive me if this sounds a bit naive), could the swapping be handled by agpgart, which just changes the memory mapping of the allocated pages in the background? Sort of an added VM layer, only it would swap to system memory (which could then be swapped to disk)... > 2. What is the best way for processes to be notified of events that > could cause can-swap bits to change (i.e., rendering completion, > asynchronous buffer-swap completion, etc.)? Signals from the kernel? > Polling "age" variables? I'd lean towards signals, myself, though then that leads to possible problems with libGL using a signal which an application wants to use... Or would it be capable of defining new signals? (I'm not up to speed on how that part of the kernel works. Would it just be as simple as adding a new value to an enumeration?) > 4. How could the memory manager handle objects that span multiple > blocks? In other words, could the memory manager be made to prefer > to swap-out blocks that wholly contain all of the objects that > overlap the block? Are there other useful metrics? Prefer to > swap-out blocks that are half full over blocks that are completely > full? If the AGP layer were to treat it like a VM layer and the page size were small (say, 4K) I don't think this would be an issue. -- http://trikuare.cx --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] The next round of texture memory management...
On Thu, Jan 16, 2003 at 10:16:30PM -0800, magenta wrote: | | Should it even be possible for one process to swap out other processes' | context data? In the same way that one process can cause the ordinary memory pages of another process to be swapped out, I'd say "yes." As the old saying goes, "Virtual memory is a technique that makes a lot of memory look like a lot of memory." :-) The same holds true for OpenGL context data (especially textures). Allen --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
