Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 andpossibly radeon DMA functions
On Mon, 2002-01-28 at 04:54, Davor Buvinic wrote: > > Yes, running glxgears cause the movie player to crawl and if I start to move > or resize their windows X crashes. > > The movie player is MPlayer, today cvs. > > Here is my log file from X. As you can see, at the end of the file the > following messages appears: > > [...] > (II) R128(0): StopVideo > (EE) R128(0): Idle timed out, resetting engine... > [...] I have an idea what the problem could be. The Xv code still uses direct register access, even when the CCE is running. That's exactly what we want to avoid, because it can crash the chip. :) I probably won't have time this week to work on a solution but I suggest you try either shutting down the CCE before accessing registers or adding new Xv functions which use the CCE for register access (à la the CCE accel functions). I'd prefer not shutting down the CCE at any rate. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Son, 2002-01-27 at 19:41, Peter Surda wrote: > On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dänzer wrote: > > > > The first one definitely wasn't correct. A process of pid 0 doesn't exist, but > > > it has been handled as if it existed. > > The test ( buf->pid != current->pid ) isn't there for fun. The pid field > > of the buffer must contain the current process' pid. > Yes, exactly. But this test fails if buf->pid == 0, which is wrong. No. As you say, 0 isn't a valid pid, which is covered by this test. > Hence I added this test. See "added", not "deleted" or "replaced" You "deleted" part of the ( buf->pid != current->pid ) test. > > Looking at r128_freelist_get(), ( buf->pid == 0 ) means the buffer is > > free, i.e. not supposed to be in use by any process. > Yes thats exactly what I'm talking about, this isn't tested though in other > places. It is, see above. > > is in the LeaveServer() function, where it releases the indirect buffer. Can > > you try if that fixes the problem? Another idea is to set > > info->indirectBuffer to NULL in R128CCEAccelInit(). > Sounds reasonable, I'll try it. So the first solution works, what about the second one? > I hope I'll be around on tomorrows irc meeting, we can try stuff in realtime then :-) Unfortunately, I can't attend tonight's meeting because I'm in military service this week. :( -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possiblyradeon DMA functions
On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: > On Mon, 2002-01-28 at 04:54, Davor Buvinic wrote: > > > > Yes, running glxgears cause the movie player to crawl and if I start to move > > or resize their windows X crashes. > > > > The movie player is MPlayer, today cvs. > > > > Here is my log file from X. As you can see, at the end of the file the > > following messages appears: > > > > [...] > > (II) R128(0): StopVideo > > (EE) R128(0): Idle timed out, resetting engine... > > [...] > > I have an idea what the problem could be. The Xv code still uses direct > register access, even when the CCE is running. That's exactly what we > want to avoid, because it can crash the chip. :) > > I probably won't have time this week to work on a solution but I suggest > you try either shutting down the CCE before accessing registers or > adding new Xv functions which use the CCE for register access (à la the > CCE accel functions). I'd prefer not shutting down the CCE at any rate. > Yes, that's what happens. I do think we need to shutdown CCE because in some case we want to read registers - and not only write. The short term solution would be to use XAA->Sync() instead of WaitForEngineIdle because WaitForEngineIdle does not guarantee the card is quiscent in CCE mode. Vladimir Dergachev > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xpert]Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128and possibly radeon DMA functions
On Mon, 28 Jan 2002, Davor Buvinic wrote: > On Sunday 27 January 2002 21:59, you wrote: > > On Sun, 27 Jan 2002, Davor Buvinic wrote: > [...] > > > Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI > > > drivers sources. No more messages in the kernel log like the following: > > > > > > [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 > > > > > > But if I play a video and run glxgears X crashes. Option "UseCCEFor2D" > > > didn't appears to help... > > > > Please try latest GATOS CVS - main branch - and let me know if it works > > better. > > > > Vladimir Dergachev > > With the latest GATOS CVS - the one with changes from Peter Surda at the > files radeon_driver.c, radeon_reg.h, fi1236.c, fi1236.h, msp3430.c, > r128_dri.c, theatre.h and theatre_reg.h - the problem (apparently) is the > same one that at first: corruption at login screen (xdm, kdm), the messages > [drm:r128_cce_indirect] in the kernel log, and X crashes. Patched in the wrong place, please try again. Vladimir Dergachev > > With only the patch from Peter Surda to the file r128_dri.c no corruption at > login screen, no messages in the kernel log but X crash with both mplayer and > glxgears running, or only with mplayer after a while playing a video. > > BTW, which is the appropriate mailing list to discuss this stuff? I think > that we're CC: to too many places... At this step we'll finish CC: to the > linux kernel mailing list :) > > - Davor > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Mon, 2002-01-28 at 10:00, Vladimir Dergachev wrote: > > > On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: > > > On Mon, 2002-01-28 at 04:54, Davor Buvinic wrote: > > > > > > Yes, running glxgears cause the movie player to crawl and if I start to move > > > or resize their windows X crashes. > > > > > > The movie player is MPlayer, today cvs. > > > > > > Here is my log file from X. As you can see, at the end of the file the > > > following messages appears: > > > > > > [...] > > > (II) R128(0): StopVideo > > > (EE) R128(0): Idle timed out, resetting engine... > > > [...] > > > > I have an idea what the problem could be. The Xv code still uses direct > > register access, even when the CCE is running. That's exactly what we > > want to avoid, because it can crash the chip. :) > > > > I probably won't have time this week to work on a solution but I suggest > > you try either shutting down the CCE before accessing registers or > > adding new Xv functions which use the CCE for register access (à la the > > CCE accel functions). I'd prefer not shutting down the CCE at any rate. > > > > Yes, that's what happens. I do think we need to shutdown CCE because in > some case we want to read registers - and not only write. The short term > solution would be to use XAA->Sync() instead of WaitForEngineIdle because > WaitForEngineIdle does not guarantee the card is quiscent in CCE mode. Sounds like the correct fix, except I don't even see 'WaitForEngineIdle' in my trees - is that a GATOS novelty? :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RFC Shared AGP Memory
Matt, I have two questions regarding shared AGP memory. The first is inline--the correlary to Ian's question. The second question is at the end--it's more open ended. "Sottek, Matthew J" wrote: > > >This seems reasonable enough, but I'll have to think about it more > >and learn a bit more about the AGP implementation to fully grok it. > >On question I do have is what impact will this have (if any) on > >chipsets that aren't UMA? > > No impact whatsoever. I specifically didn't touch ANY device independent > code. It is all contained within the i810's driver. Have you gotten any feedback from developers working with any other UMA architectures (Sis or Savage for example)? > Certainly if > the behavior catches on we could move some of it "up" into the > device independent layers so that there is less work to be done in > the drivers. Also, I have been careful to make sure that existing > X servers + DRM run on this without any modifications. Both WITH and > WIHTOUT a framebuffer device having installed the shared memory. Good. > I will post a patch shortly. We look forward to seeing it. My second question is can this kind of shared AGP memory be extended, at least on Intel to all the memory for the graphics subsystem that isn't share across contexts? I'm thinking about private backbuffers, textures, command buffers, etc. The main purpose would be to maximize the available memory in the AGP aperture, which would be especially usefull for a 3D tiling window system. Imagine a UMA system with lots of available memory but only a 64M graphics window. Display memory and enough memory for each applications front buffer would be permanently allocated from the 64M window. The remainder could be shared as 3D context specific memory that utilized a high speed context switch method (shared AGP memory). Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Source -> Documentation using Doxygen
Pontus Lidman wrote: > I agree with all your points, which I interpret as no html tags, > document in the header, brief API documentation only. Good summary. > > Okay. If nobody else volunteers I'll give it a try when I'm finished > > with the FAQ (which by the way was recently updated and can be seen at > > http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/ ). > > I guess this means it's ok to submit patches with just doxygen > comments? I think this could be a productive way to learn and document > at the same time. Jose, Pontus, Work with each other to avoid duplication of effort--we look forward to seeing your progress. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
dri-devel@lists.sourceforge.net
Kevin E Martin wrote: > > On Fri, Jan 25, 2002 at 09:41:17AM -0800, Ian Romanick wrote: > > > > > > If not, what's the prognosis? Is it in the works and just > > > > > > gonna take some time, or are there other issues such as > > > > > > documentation availability? > > > > > > > > > > There was some (brief) talk about this on the developer chat on > > > > > Monday. Work is being done to get Radeon 8500 cards up to the > > > > > level of original Radeons, then work on T&L support will move > > > > > forward. > > > > > > Just to clarify. TG is supporting Keith Whitwell's work for T&L support > > > for the Radeon I (7500 and earlier radeon based cards). The R200 (found > > > on the 8500) is a newer 3D core, and we have no committed plans for that > > > chipset at this time. > > > > Ok, I looked back at the log to make sure I wan't losing my mind. I saw > > your comments about Keith's work at TG. Here is the comment that I was > > refering to, though: > > > > jens: i'm just trying to get the 8500 up to the point that it works as > > well as the currently radeon code -- not focusing on t&l at all yet > > > > So, it looks like both Kevin and Keith are doing some Radeon work, albeit > > coming from different angles. > > Exactly. In my spare time, I'm bringing up the 8500 to the level of the > pre-T&L Radeon code. It's very slow going since my spare time is > limited due to a heavy workload and some upcoming deadlines. And Keith is providing the first T&L driver based on the Radeon I chipset. Both of these projects are important precursers to a 8500 based T&L driver--however, no one has stepped up to provide the development or funding for that project, yet. Perhaps this question could be answer in our new FAQ. I've seen it frequently. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: > On Mon, 2002-01-28 at 10:00, Vladimir Dergachev wrote: > > > > > > On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: > > > > > On Mon, 2002-01-28 at 04:54, Davor Buvinic wrote: > > > > > > > > Yes, running glxgears cause the movie player to crawl and if I start to move > > > > or resize their windows X crashes. > > > > > > > > The movie player is MPlayer, today cvs. > > > > > > > > Here is my log file from X. As you can see, at the end of the file the > > > > following messages appears: > > > > > > > > [...] > > > > (II) R128(0): StopVideo > > > > (EE) R128(0): Idle timed out, resetting engine... > > > > [...] > > > > > > I have an idea what the problem could be. The Xv code still uses direct > > > register access, even when the CCE is running. That's exactly what we > > > want to avoid, because it can crash the chip. :) > > > > > > I probably won't have time this week to work on a solution but I suggest > > > you try either shutting down the CCE before accessing registers or > > > adding new Xv functions which use the CCE for register access (à la the > > > CCE accel functions). I'd prefer not shutting down the CCE at any rate. > > > > > > > Yes, that's what happens. I do think we need to shutdown CCE because in > > some case we want to read registers - and not only write. The short term > > solution would be to use XAA->Sync() instead of WaitForEngineIdle because > > WaitForEngineIdle does not guarantee the card is quiscent in CCE mode. > > Sounds like the correct fix, except I don't even see 'WaitForEngineIdle' > in my trees - is that a GATOS novelty? :) Ahh.. sorry it's called XWaitForIdle :)) WaitForEngineIdle is how its called in ATI sample code. Btw, while I've been sleeping I thought how we could get CCE support into Xvideo. The thing I am really against is duplicating code for case with CCE and without. So, I thought, what about having "Software CCE" ? I.e. always use CCE commands except that in case when dri driver is not availabe emulate it. I am fairly certain emulating indirect buffer and 2d commands would be pretty easy. Vladimir Dergachev > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > ___ > Gatos-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/gatos-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Maybe fixed shared texture object problem
I tried your suggested patches to lib/GL/mesa/src/drv/mga/mgatexmem.c. I still occasionally get the message: Couldn't alloc placeholder sz 4 ofs 8 Memory heap 0x8c27cd0: Offset:, Size:0004, U. ... This mainly happens when switching back and forth between different Gnome/Sawfish workspaces, meaning that the window manager (sawfish) is calling XUnmapWindow and XMapWindow on the top-level frames containing my GLX windows. The messages occur as a result of the XMapWindow calls. I am not sure the patch actually reduced the frequency of the messages or the texture garbling. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] IRC Meeting
I'm going to be at a client most of the day, so I don't know that I can make the IRC meeting. If it happens late enough that I'm home I'll join. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
dri-devel@lists.sourceforge.net
On Mon, 2002-01-28 at 14:17, Jens Owen wrote: > ... > > Perhaps this question could be answer in our new FAQ. I've seen it > frequently. > Okay. I'll add a summary of what was said in this thread into: Harware / ATI / Radeon 8500 / What are the plans to support this card ? Kevin and Keith, if you know any public resources about this card please give me their links to include in the FAQ as well. Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
dri-devel@lists.sourceforge.net
Jose Fonseca wrote: > > On Mon, 2002-01-28 at 14:17, Jens Owen wrote: > > ... > > > > Perhaps this question could be answer in our new FAQ. I've seen it > > frequently. > > > > Okay. I'll add a summary of what was said in this thread into: > > Harware / ATI / Radeon 8500 / What are the plans to support this card ? > > Kevin and Keith, if you know any public resources about this card please > give me their links to include in the FAQ as well. ATI seem to release programming information about their products to individuals, rather than make them publicly available. They actually have been making 8500 information available to opensource ppl since prior to the release of the product, and (as I've just learned) have put together a semi-complete reference 3d driver for the card. All this and more is available through their developer relations program. I've got a pretty-close-to-fully-functional tcl driver now, need to do some work on correctness and then look at optimizations. I'd like to get the source out fairly quickly - once it's ok'd by ATI and correct, I'd like to do the final bugfixing & tuning on sourceforge. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] IRC Meeting
When did we plan on doing the IRC meeting? I missed the final decision. -Matt -Original Message- From: Daryll Strauss [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 8:45 AM To: [EMAIL PROTECTED] Subject: [Dri-devel] IRC Meeting I'm going to be at a client most of the day, so I don't know that I can make the IRC meeting. If it happens late enough that I'm home I'll join. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] RFC Shared AGP Memory
>> No impact whatsoever. I specifically didn't touch ANY device >> independent code. It is all contained within the i810's driver. >Have you gotten any feedback from developers working with any other UMA >architectures (Sis or Savage for example)? The only feedback I've gotten is from this list. Is there another/better place I should solicit further feedback? >> I will post a patch shortly. >We look forward to seeing it. I'll get to it today :) >My second question is can this kind of shared AGP memory be extended, >at least on Intel to all the memory for the graphics subsystem that >isn't share across contexts? I'm thinking about private backbuffers, >textures, command buffers, etc. The main purpose would be to maximize >the available memory in the AGP aperture, which would be especially >usefull for a 3D tiling window system. This is what I'm currently doing with the framebuffer driver I'm finishing up. I have fixed areas within the Gart for different uses. All new drivers would use these fixed offsets to maximize alignment for things that need to be aligned, Minimize the number of tiles needed to cover the things that should be tiled, and allow for totally dynamic memory based on need. Currently I have this for i810: Use Offset Size FB0x05MB (Best mode is really 16x12 which fits here) BB5MB5MB DB10MB5MB (1MB hole, could be moved up to FB) Video 16MB 8MB IRing 24MB 512k LRing 24.5MB 512k Scratch 8MB 8MB Scratch 32MB 32MB So I expect that the first 24MB of memory would all be shared between all clients. The rings are shared as well but only the memory is shared, the clients need to work out a way to shared the USE of the rings. The rest of the memory would be used for any scratch purpose including memory that isn't shared. Although I didn't fully implement it yet (I don't have a use case) I did add an EXCLUSIVE type which basically means !shared. This would make sure to return -EBUSY if any overlap happened. >Imagine a UMA system with lots of available memory but only a 64M >graphics window. Display memory and enough memory for each >applications front buffer would be permanently allocated from the >64M window. The remainder could be shared as 3D context specific >memory that utilized a high speed context switch method (shared >AGP memory). I didn't quite get what you were asking here... Are you suggesting tying the agp resources to the DRM context such that whenever a context is active it's memory is automatically mapped into the gart so it doesn't have to worry about textures going away and such? Certainly sounds interesting and I think the existing alloc/bind/unbind/free method works just fine for doing that. You just need to have a per context agp_mem handle and have the DRM switch the memory on the fly. I'm not sure if the overhead of the memory switch would be higher than the overhead of managing textures in a shared buffer but it is probably worth investigation. One of the things I've disliked about the DRM is the locking rather than full transparent virtualization, the way it currently is a poorly designed client can hold the lock too long and badly impact the rest of the system. Sort of like cooperative multitasking... it CAN work but only if everyone plays the game well. Having context specific agp resources gets us one step closer to real transparent virtualization. I was planning on experimenting with the reverse. Having per context shared agp memory that was reference counted so that when a drm context is created the memory pops into existence and is shared by all current drm contexts just as it is now. But when the last drm context goes away so does the memory. This hold for back buffers and depth buffers too. Wasting all that memory when 3d isn't in use is quite an impact to a system with say 64MB ram or less. -Matt ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] IRC Meeting
Nobody's suggested a time yet. So I'll propose 12:00pm PST (3:00 EST) so that those in Europe can more likely join in. That's about 2:15 from now. Is that OK with everyone? I realize it's short notice but if we push it much further back it'll be harder for those in the UK to join in. -Brian PS: Try http://www.worldtimezone.com/ for timezone conversion. "Sottek, Matthew J" wrote: > > When did we plan on doing the IRC meeting? I missed the final > decision. > > -Matt > > -Original Message- > From: Daryll Strauss [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 28, 2002 8:45 AM > To: [EMAIL PROTECTED] > Subject: [Dri-devel] IRC Meeting > > I'm going to be at a client most of the day, so I don't know that I can > make the IRC meeting. If it happens late enough that I'm home I'll join. > > - |Daryll > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] IRC Meeting
The IRC log says 18:00 GMT. That is 25min from now. Regards, Jose Fonseca On 2002.01.28 17:24 "Sottek, Matthew J" wrote: > > When did we plan on doing the IRC meeting? I missed the final > decision. > > -Matt > > > -Original Message- > From: Daryll Strauss [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 28, 2002 8:45 AM > To: [EMAIL PROTECTED] > Subject: [Dri-devel] IRC Meeting > > > I'm going to be at a client most of the day, so I don't know that I can > make the IRC meeting. If it happens late enough that I'm home I'll join. > > - |Daryll _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] IRC Meeting
We'll meet at 1800 GMT which is 10am pacific time. "Sottek, Matthew J" wrote: > > When did we plan on doing the IRC meeting? I missed the final > decision. > > -Matt > > -Original Message- > From: Daryll Strauss [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 28, 2002 8:45 AM > To: [EMAIL PROTECTED] > Subject: [Dri-devel] IRC Meeting > > I'm going to be at a client most of the day, so I don't know that I can > make the IRC meeting. If it happens late enough that I'm home I'll join. > > - |Daryll > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] IRC Meeting
OK, ignore my other message suggesting a later time then. I didn't realize we'd picked 1800 GMT. -Brian Jens Owen wrote: > > We'll meet at 1800 GMT which is 10am pacific time. > > "Sottek, Matthew J" wrote: > > > > When did we plan on doing the IRC meeting? I missed the final > > decision. > > > > -Matt > > > > -Original Message- > > From: Daryll Strauss [mailto:[EMAIL PROTECTED]] > > Sent: Monday, January 28, 2002 8:45 AM > > To: [EMAIL PROTECTED] > > Subject: [Dri-devel] IRC Meeting > > > > I'm going to be at a client most of the day, so I don't know that I can > > make the IRC meeting. If it happens late enough that I'm home I'll join. > > > > - |Daryll > > > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > -- /\ > Jens Owen/ \/\ _ > [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
dri-devel@lists.sourceforge.net
> I've got a pretty-close-to-fully-functional tcl driver now, need to do > some work on correctness and then look at optimizations. I'd like to > get the source out fairly quickly - once it's ok'd by ATI and correct, > I'd like to do the final bugfixing & tuning on sourceforge. > > Keith Excellent news. I'd be more than happy to help you test it. :) Any kind of ETA before it goes to sf? Weeks? Months? Nick ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RFC Shared AGP Memory
"Sottek, Matthew J" wrote: > > >> No impact whatsoever. I specifically didn't touch ANY device > >> independent code. It is all contained within the i810's driver. > > >Have you gotten any feedback from developers working with any other UMA > >architectures (Sis or Savage for example)? > > The only feedback I've gotten is from this list. Is there > another/better place I should solicit further feedback? Not that I know of, other than pinging the developers directly. > >> I will post a patch shortly. > >We look forward to seeing it. > I'll get to it today :) > > >My second question is can this kind of shared AGP memory be extended, > >at least on Intel to all the memory for the graphics subsystem that > >isn't share across contexts? I'm thinking about private backbuffers, > >textures, command buffers, etc. The main purpose would be to maximize > >the available memory in the AGP aperture, which would be especially > >usefull for a 3D tiling window system. > > This is what I'm currently doing with the framebuffer driver I'm > finishing up. I have fixed areas within the Gart for different uses. > All new drivers would use these fixed offsets to maximize alignment > for things that need to be aligned, Minimize the number of tiles > needed to cover the things that should be tiled, and allow for totally > dynamic memory based on need. > > Currently I have this for i810: > > Use Offset Size > FB0x05MB (Best mode is really 16x12 which fits here) with 16x12 padded out to 2k at 16bpp...this makes sense. > BB5MB5MB BB...Backbuffer? > DB10MB5MB DB...Doublebuffer? Frontbuffer? > (1MB hole, could be moved up to FB) > Video 16MB 8MB 8MB? Must be for 16x12 padded to 2K w/ 24bit YUV. > IRing 24MB 512k > LRing 24.5MB 512k > Scratch 8MB 8MB > Scratch 32MB 32MB Why the seperate 8MB and 32MB Scratch? GART table setup requirements maybe? > > So I expect that the first 24MB of memory would all be shared between > all clients. The rings are shared as well but only the memory is shared, > the clients need to work out a way to shared the USE of the rings. This seams reasonable in the current implementation. > The rest of the memory would be used for any scratch purpose including > memory that isn't shared. Although I didn't fully implement it yet > (I don't have a use case) I did add an EXCLUSIVE type which basically > means !shared. This would make sure to return -EBUSY if any overlap > happened. > > >Imagine a UMA system with lots of available memory but only a 64M > >graphics window. Display memory and enough memory for each > >applications front buffer would be permanently allocated from the > >64M window. The remainder could be shared as 3D context specific > >memory that utilized a high speed context switch method (shared > >AGP memory). > > I didn't quite get what you were asking here... Are you suggesting > tying the agp resources to the DRM context such that whenever a context > is active it's memory is automatically mapped into the gart so it > doesn't have to worry about textures going away and such? Exactly. > Certainly > sounds interesting and I think the existing alloc/bind/unbind/free > method works just fine for doing that. You just need to have a > per context agp_mem handle and have the DRM switch the memory on the > fly. I'm not sure if the overhead of the memory switch would be > higher than the overhead of managing textures in a shared buffer but > it is probably worth investigation. I agree, we would need to investigate whether invalidating the texture cache wouldn't be faster. However, I'd like to point out that I'd even like to switch out the back buffer and as much command processing as possible and try for more transparent virtualization. > One of the things I've disliked > about the DRM is the locking rather than full transparent virtualization, > the way it currently is a poorly designed client can hold the lock too > long and badly impact the rest of the system. Sort of like > cooperative multitasking... it CAN work but only if everyone plays the > game well. Yes, this is the downside of explicit locking. Note however that the DRM locking mechanisms are voluntary and a driver could be written without them--provided you have enough hardware support to implement asynchronous implicit locking. > Having context specific agp resources gets us one step > closer to real transparent virtualization. Agreed, but there are more tough issues to address here. Would having the command buffers in "shared AGP memory" be difficult to manage? A memory faulting mechanism would also be needed as well as a reasonable way to "take away" the HW from an existing context at switch time. > I was planning on experimenting with the reverse. Having per context > shared agp memory that was reference counted so that when a drm context > is created the memory pops into existence and is shared by all current > drm contexts just as it is now. But when the l
[Dri-devel] Patch - scissor fix
Attached patch fixes flag corruption at beginning of RTCW.
--
Michael.
Index: radeon_state.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state.c,v
retrieving revision 1.9.6.7
diff -u -3 -p -r1.9.6.7 radeon_state.c
--- radeon_state.c 2001/11/21 13:34:03 1.9.6.7
+++ radeon_state.c 2002/01/28 18:22:10
@@ -309,15 +309,16 @@ static void radeonUpdateScissor( GLconte
if ( rmesa->dri.drawable ) {
__DRIdrawablePrivate *dPriv = rmesa->dri.drawable;
- int x = ctx->Scissor.X;
- int y = dPriv->h - ctx->Scissor.Y - ctx->Scissor.Height;
- int w = ctx->Scissor.X + ctx->Scissor.Width - 1;
- int h = dPriv->h - ctx->Scissor.Y - 1;
+ int x, y, w, h;
+ x = MAX2(ctx->Scissor.X, dPriv->x);
+ y = MAX2(dPriv->h - ctx->Scissor.Y - ctx->Scissor.Height, 0);
+ w = MIN2(ctx->Scissor.X + ctx->Scissor.Width, dPriv->w);
+ h = MIN2(dPriv->h - ctx->Scissor.Y, dPriv->h);
rmesa->state.scissor.rect.x1 = x + dPriv->x;
rmesa->state.scissor.rect.y1 = y + dPriv->y;
- rmesa->state.scissor.rect.x2 = w + dPriv->x + 1;
- rmesa->state.scissor.rect.y2 = h + dPriv->y + 1;
+ rmesa->state.scissor.rect.x2 = w + dPriv->x;
+ rmesa->state.scissor.rect.y2 = h + dPriv->y;
if ( ctx->Scissor.Enabled )
rmesa->upload_cliprects = 1;
[Dri-devel] IRC meeting is on NOW
In case you missed it, or forgot, the IRC meeting is taking place right now on #dri-devel. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Mon, Jan 28, 2002 at 09:33:51AM +0100, Michel Dänzer wrote: > > Yes, exactly. But this test fails if buf->pid == 0, which is wrong. > No. As you say, 0 isn't a valid pid, ... which means the buffer is unused and the test should fail. > which is covered by this test. ... which is not. > > Hence I added this test. See "added", not "deleted" or "replaced" > You "deleted" part of the ( buf->pid != current->pid ) test. An incorrect one though. > So the first solution works, what about the second one? I'm too lazy :-) > > I hope I'll be around on tomorrows irc meeting, we can try stuff in realtime then >:-) > Unfortunately, I can't attend tonight's meeting because I'm in military > service this week. :( D'oh. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The product Microsoft sells isn't the software; it's comfort. The product that Linux vendors usually sell is freedom. msg02586/pgp0.pgp Description: PGP signature
[Dri-devel] R128 driver status
Hello, Not sure if this is the correct list to paste this message, but I've tried the Xfree Xpert list before, and haven't gotten any (really useful) replies. I've downloaded the latest 4.2.0 sources from the regular Xfree86 mirrors (so no DRI CVS's) to test if my ATI Xpert2000 32MB AGP card still has the "snow" issues, and it still does. With the snow issues i refer to the noise that appears when large parts of the screen are updated. It's on the right side at about 1000 pixels from the left (so at resolutions below 1024x768 it isn't there), from top to bottom. When the accel is disabled (Option "UseCCEFor2D" "true"), it doesn't appear. Also, the console framebuffer doesn't have the issue either. I was told to wait for the next 4.2.0 release, and I did. Yet no luck for me. some info: /proc/pci: Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Rage 128 RF (rev 0). IRQ 11. Master Capable. Latency=64. Min Gnt=8. Prefetchable 32 bit memory at 0xe400 [0xe7ff]. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xed00 [0xed003fff]. Thanks in advance, -- tinus ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Next weeks IRC
Thanks to all who participated this week. It was suggested that we move the meeting to be 3 hours later so might pick up any developers in Australia and New Zealand. None of the European and African developers had a concern with the change, so we'll try next monday at 2100 UTC. Try this link for the local time in your area: http://www.timeanddate.com/worldclock/fixedtime.html?day=4&month=2&year=2002&hour=21&min=0&sec=0&p1=0 -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Next weeks IRC
On Mon, Jan 28, 2002 at 01:03:52PM -0700, Jens Owen wrote: > Thanks to all who participated this week. > > It was suggested that we move the meeting to be 3 hours later so might > pick up any developers in Australia and New Zealand. None of the > European and African developers had a concern with the change, so we'll > try next monday at 2100 UTC. Try this link for the local time in your > area: > Sheesh I didn't see the time until I've just got back in. 8:20pm GMT here now. I'd just nipped to the pub for a couple of hours too. 3 hours later is fine for me. Thanks Jens! Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] IRC meeting log, 2001-01-28
Hi everyone, attached is the log of today's meeting. If someone minds about the size of the attachment (17kB), please mail me privately to put it on a webserver next time. Topics discussed, among others: * Patents * Some bits of info on ATI's Radeon 8500 drivers * Implementation of drivers * The development FAQ -- Marcelo dri-devel-20020128.txt.gz Description: Binary data
[Dri-devel] R128 driver status
Hello, Not sure if this is the correct list to paste this message, but I've tried the Xfree Xpert list before, and haven't gotten any (really useful) replies. I've downloaded the latest 4.2.0 sources from the regular Xfree86 mirrors (so no DRI CVS's) to test if my ATI Xpert2000 32MB AGP card still has the "snow" issues, and it still does. With the snow issues i refer to the noise that appears when large parts of the screen are updated. It's on the right side at about 1000 pixels from the left (so at resolutions below 1024x768 it isn't there), from top to bottom. When the accel is disabled (Option "UseCCEFor2D" "true"), it doesn't appear. Also, the console framebuffer doesn't have the issue either. I was told to wait for the next 4.2.0 release, and I did. Yet no luck for me. The logs say nothing weird, and there are no abnormal messages in /var/log/messages. some info (need more?): /proc/pci: Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Rage 128 RF (rev 0). IRQ 11. Master Capable. Latency=64. Min Gnt=8. Prefetchable 32 bit memory at 0xe400 [0xe7ff]. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xed00 [0xed003fff]. Thanks in advance, -- tinus ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] chown /dev/dri/card0, system crashes
> 3. User runs glxgears. It uses DRI. > 4. Switch VTs, chown otheruser /dev/dri/card0, chmod 600 > /dev/dri/card0. maybe this killed some file handles of the x-server. > 5. Change mind, chown root /dev/dri/card0 (no second chmod) > 6. Switch Vts, user runs glxgears again. Reports "operation not > permitted, using slow indirect rendering" and runs at 230 fps. the system reports on what it thinks that has happend. but i am unsure on my explanation. > 7. Switch VTs, check /dev/dri/card0. IT'S NOT THERE! radeon kernel > module is still loaded and has the same access count. > Remember this > is in devfs. > 8. Used the Magic SysRq Key to sync, remount and reboot. so what have we learnt? better do not manipulate rights of files that are in currently in use by some other application. someone with something better to pop up? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R128 driver status
Hello, Not sure if this is the correct list to paste this message, but I've tried the Xfree Xpert list before, and haven't gotten any (really useful) replies. I've downloaded the latest 4.2.0 sources from the regular Xfree86 mirrors (so no DRI CVS's) to test if my ATI Xpert2000 32MB AGP card still has the "snow" issues, and it still does. With the snow issues i refer to the noise that appears when large parts of the screen are updated. It's on the right side at about 1000 pixels from the left (so at resolutions below 1024x768 it isn't there), from top to bottom. When the accel is disabled (Option "UseCCEFor2D" "true"), it doesn't appear. Also, the console framebuffer doesn't have the issue either. I was told to wait for the next 4.2.0 release, and I did. Yet no luck for me. some info: /proc/pci: Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Rage 128 RF (rev 0). IRQ 11. Master Capable. Latency=64. Min Gnt=8. Prefetchable 32 bit memory at 0xe400 [0xe7ff]. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xed00 [0xed003fff]. Thanks in advance, -- tinus ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] chown /dev/dri/card0, system crashes
> OpenGL applications successfully use DRI, e.g. glxgears gets 628 fps vs. > 220 fps without DRI. I added /dev/dri/card0 to /etc/logindevperm, so xdm > would chown-chmod the device to $USER 600 at login, and root 600 when the > session ends. Users can log in, but when they log out the system > freezes: the screen goes black, you can't switch VTs, and the Magic SysRq > Key has no effect. The failure occurs if and only if that line is present > in /etc/logindevperm. Unless I am mistaken, the short answer is don't do that. /dev/dri/card0 is only directly accessed by the X server, which runs with root permissions. So, you shouldn't ever need to do such a thing. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI driver initialization process
On Thu, Jan 24, 2002 at 09:13:40PM -0700, Jens Owen wrote: > Ian Romanick wrote: > > > I've been going through the DRI code and documents trying to figure out how > > all this stuff works. I decided to start at the start, so I've been looking > > at the driver initialization process. > > You and Brian have already done an excellent job commenting on the > startup process of the 3D core--so I won't touch that. However, I will > add that there is a broader picture that includes how the DDX and DRM > parts are initialized. Where in the source should I start looking at DDX? -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI driver initialization process
On 2002.01.28 22:20 Ian Romanick wrote: > On Thu, Jan 24, 2002 at 09:13:40PM -0700, Jens Owen wrote: > > Ian Romanick wrote: > > > > > I've been going through the DRI code and documents trying to figure > out how > > > all this stuff works. I decided to start at the start, so I've been > looking > > > at the driver initialization process. > > > > You and Brian have already done an excellent job commenting on the > > startup process of the 3D core--so I won't touch that. However, I will > > add that there is a broader picture that includes how the DDX and DRM > > parts are initialized. > Ian, I hope you don't mind but I've put your notes in the FAQ. > Where in the source should I start looking at DDX? > Check at http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/html/architecture.html#DDX-DRIVER-WHERE Regards, Jose Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: IRC meeting is on NOW
On Mon, 28 Jan 2002, Gareth Hughes wrote: >Date: Mon, 28 Jan 2002 10:25:20 -0800 >From: Gareth Hughes <[EMAIL PROTECTED]> >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> >Content-Type: text/plain; > charset="iso-8859-1" >List-Id: >Subject: IRC meeting is on NOW > >In case you missed it, or forgot, the IRC meeting is taking place >right now on #dri-devel. I missed the dang thing. ;o) Didn't get a response to my email query so I went and crashed out for several hours. Perhaps we should settle upon one fixed time, or in lieu of that, a dual time rotation every week, and have it posted somewhere. Pretty much any time at all is good for me, so whatever works best for the most people should be fine. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Repost with Patch: RFC AGP Shared Memory
This is a repost with the patch against 2.4.17 attached. I think Jeff is back on the list so I'll save him from having to read the archives for the original. -Matt I posted a RFC about a new type of "Shared" agp memory a while back but didn't get any input. I thought I would try again since there has been better communication as of late, and the idea has progressed somewhat. The problem: The agpgart usage model is not well suited for UMA architectures because each gart user is expected to allocate memory and only bind it into the gart while it is active. Therefore on systems where all graphics memory is obtained from the gart a huge amount of system memory is wasted (16 Megs is probably a common amount of wasted memory on a system running 2 X servers). To further the problem this memory is non-swappable. The issue has become exacerbated on embedded devices that must have a framebuffer console for smooth graphics transitions during boot. The framebuffer console must share a framebuffer among the virtual terminals and eventually share resources with X. Solution: I have created a new type of agp memory in use in the i810's agpgart. This type is "Shared" memory and works quite differently from regular agpgart memory. First, when memory of type shared is allocated the allocation will basically always succeed, but does not allocate any pages. It only allocates the agp memory structure. The pages are only allocated when bound. There is a shared reference count table (8bit * Number of pages) that allows the agpgart driver to determine if the pages actually need to be allocated at bind time. If a page is being bound where a shared page already exists the reference count is increased and the page is reused. Pages are freed when the last reference is removed (during unbind) Second, in order to be compatible with existing memory types the following rules apply: * Binding regular memory on top of shared memory does NOT result in an -EBUSY. The existing pages are left bound and the reference count is increased. The regular memory pages are wasted, and therefore should be avoided in the future. * Binding shared memory on top of regular memory is not allowed. This is primarily the case because allocate/free of regular memory is handled at the device independent layer. This also gives the first client the guarantee that the memory behavior will be as historically expected. * Binding of Local memory for i810 is carried out as normal. If local memory is being bound on top of shared memory the shared pages are kept instead. (I expect that local memory will be unbound when a client leaves since there is no duplication of memory) * Physical memory is currently still a problem. Since the client is given the physical address of the page at allocation time it can not be ignored when bound into a shared area. Currently I swap the physical page with the one in the shared area. This works fine but would fail if two clients bound a physical page at the same location. The physical type of memory has no actual need to be bound into the gart. It just makes it easy for XFree. So designs that are sharing memory with the framebuffer should just mmap the physical page via the framebuffer and not map it into the gart. Using this scenario I have created a framebuffer that uses a different Shared memory allocation for each virtual terminal. Each virtual terminal allocates and binds the memory at startup and the agpgart internally keep track of the reference counts. When a mode change occurs, the virtual terminal allocates and binds a second memory region (If the size changed), then unbinds and frees the first. Since the memory for each vt in independently reference counted this system guarantees that the minimum amount of memory needed to satisfy any running virtual terminal is allocated into the gart. This plan can be carried forward to accommodate all resource types. DMA buffers, textures, video surfaces, back/depth buffers would all be allocated dynamically only when needed. Thereby saving large amount of memory during normal operation. Comments welcome, -Matt <> linux.diff.gz Description: Binary data
[Dri-devel] unsubsrcibed from list
Hi all, for some reason I got unsubscribed from the list when SF moved over to their new archives. If there was anything concerning the website that I missed please let me know. In any case, some people have stepped up to give the website a glorious new look. So, maybe in the coming months there will be a new website. I will keep you posted. :) Cheers, - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Mon, 2002-01-28 at 19:27, Peter Surda wrote: > On Mon, Jan 28, 2002 at 09:33:51AM +0100, Michel Dänzer wrote: > > > Yes, exactly. But this test fails if buf->pid == 0, which is wrong. > > No. As you say, 0 isn't a valid pid, > ... which means the buffer is unused and the test should fail. Read your sentences. ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
