[Dri-devel] xaa versioning still seems broken
Every snapshot since 9/20/2002 seems to have the same problem. I know it was supposed to have been resolved the 25th, but perhaps it's not an easy fix. There is a warning message about xaa versions but no errors in the x log. X then segfaults after silken mouse is enabled. Again with no details of the error. Some people on the forums have at least been able to see an x display. X only crashes during a 3d app. For me x is crashing before I get that far (Windowmaker perhaps makes heavy use of xaa). The real problem is I loose all visuals including the console. All virtual terminals are black. I still have keyboard input so I reboot with the three finger salute. It's the only way I know how to get my console back so I can restore the previous working install of dripkg. I hope this helps. I haven't seen any posts about this problem for a couple days but it's still there. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] AGPGART 1/5: minor DRM interface cleanup
This cleans up the GART/DRM interface (in a backwards-compatible
way) and gets rid of the bogus assumption that "GATT_entry & ~0xfff"
is a physical address.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.686 -> 1.687
# drivers/char/agp/agpgart_be.c 1.35-> 1.36
# drivers/char/agp/agp.h 1.18-> 1.19
#
# The following is the BitKeeper ChangeSet Log
#
# 02/09/27 [EMAIL PROTECTED]1.687
# Make agp_memory.memory[] (exported from agpgart to DRM) contain physical
# addresses, not GATT entries.
#
# DRM assumes agp_memory contains GATT entries, and it converts them to
# physical addresses with "paddr = agp_memory.memory[i] & mask". 460GX
# requires both a shift and a mask, so exporting plain physical addresses
# and a mask of ~0UL allows agpgart to add 460GX support without requiring
# DRM interface changes.
#
#
diff -Nru a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
--- a/drivers/char/agp/agp.hFri Sep 27 20:59:30 2002
+++ b/drivers/char/agp/agp.hFri Sep 27 20:59:30 2002
@@ -87,6 +87,7 @@
u32 *gatt_table;
u32 *gatt_table_real;
unsigned long scratch_page;
+ unsigned long scratch_page_real;
unsigned long gart_bus_addr;
unsigned long gatt_bus_addr;
u32 mode;
@@ -99,7 +100,6 @@
int needs_scratch_page;
int aperture_size_idx;
int num_aperture_sizes;
- int num_of_masks;
int capndx;
int cant_use_aperture;
diff -Nru a/drivers/char/agp/agpgart_be.c b/drivers/char/agp/agpgart_be.c
--- a/drivers/char/agp/agpgart_be.c Fri Sep 27 20:59:30 2002
+++ b/drivers/char/agp/agpgart_be.c Fri Sep 27 20:59:30 2002
@@ -209,7 +209,6 @@
}
if (curr->page_count != 0) {
for (i = 0; i < curr->page_count; i++) {
- curr->memory[i] &= ~(0x0fff);
agp_bridge.agp_destroy_page((unsigned long)
phys_to_virt(curr->memory[i]));
}
@@ -262,10 +261,7 @@
agp_free_memory(new);
return NULL;
}
- new->memory[i] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new->memory[i]),
- type);
+ new->memory[i] = virt_to_phys((void *) new->memory[i]);
new->page_count++;
}
@@ -311,9 +307,6 @@
int agp_copy_info(agp_kern_info * info)
{
- unsigned long page_mask = 0;
- int i;
-
memset(info, 0, sizeof(agp_kern_info));
if (agp_bridge.type == NOT_SUPPORTED) {
info->chipset = agp_bridge.type;
@@ -329,11 +322,7 @@
info->max_memory = agp_bridge.max_memory_agp;
info->current_memory = atomic_read(&agp_bridge.current_memory_agp);
info->cant_use_aperture = agp_bridge.cant_use_aperture;
-
- for(i = 0; i < agp_bridge.num_of_masks; i++)
- page_mask |= agp_bridge.mask_memory(page_mask, i);
-
- info->page_mask = ~page_mask;
+ info->page_mask = ~0UL;
return 0;
}
@@ -731,7 +720,8 @@
mem->is_flushed = TRUE;
}
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
- agp_bridge.gatt_table[j] = mem->memory[i];
+ agp_bridge.gatt_table[j] =
+ agp_bridge.mask_memory(mem->memory[i], mem->type);
}
agp_bridge.tlb_flush(mem);
@@ -976,7 +966,8 @@
CACHE_FLUSH();
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
OUTREG32(intel_i810_private.registers,
-I810_PTE_BASE + (j * 4), mem->memory[i]);
+I810_PTE_BASE + (j * 4),
+agp_bridge.mask_memory(mem->memory[i], mem->type));
}
CACHE_FLUSH();
@@ -1042,10 +1033,7 @@
agp_free_memory(new);
return NULL;
}
- new->memory[0] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new->memory[0]),
- type);
+ new->memory[0] = virt_to_phys((void *) new->memory[0]);
new->page_count = 1;
new->num_scratch_pages = 1;
new->type = AGP_PHYS_MEMORY;
@@ -1079,7 +1067,6 @@
intel_i810_private.i810_dev = i810_dev;
agp_bridge.masks = intel_i810_masks;
- agp_bridge.num_of_masks = 2;
agp_bridge.aperture_sizes = (void *) intel_i810_sizes;
agp_bridge.size_type = FIXED_APER_
[Dri-devel] [PATCH] ati_pcigart: support 16K and 64K page size
This adds support for 16K and 64K system page sizes. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet1.660 -> 1.661 # drivers/char/drm/ati_pcigart.h 1.6 -> 1.7 # # The following is the BitKeeper ChangeSet Log # # 02/09/14 [EMAIL PROTECTED]1.661 # Add 64K & 16K page size support to ati_pcigart.h # # diff -Nru a/drivers/char/drm/ati_pcigart.h b/drivers/char/drm/ati_pcigart.h --- a/drivers/char/drm/ati_pcigart.hSat Sep 14 15:26:54 2002 +++ b/drivers/char/drm/ati_pcigart.hSat Sep 14 15:26:54 2002 @@ -29,14 +29,20 @@ #include "drmP.h" -#if PAGE_SIZE == 8192 +#if PAGE_SIZE == 65536 +# define ATI_PCIGART_TABLE_ORDER 0 +# define ATI_PCIGART_TABLE_PAGES (1 << 0) +#elif PAGE_SIZE == 16384 +# define ATI_PCIGART_TABLE_ORDER 1 +# define ATI_PCIGART_TABLE_PAGES (1 << 1) +#elif PAGE_SIZE == 8192 # define ATI_PCIGART_TABLE_ORDER 2 # define ATI_PCIGART_TABLE_PAGES (1 << 2) #elif PAGE_SIZE == 4096 # define ATI_PCIGART_TABLE_ORDER 3 # define ATI_PCIGART_TABLE_PAGES (1 << 3) #else -# error - PAGE_SIZE not 8K or 4K +# error - PAGE_SIZE not 64K, 16K, 8K or 4K #endif # define ATI_MAX_PCIGART_PAGES 8192/* 32 MB aperture, 4K pages */ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website
> > btw what about now? > > Much, much better. I have a few more comments though . ;) Refer to my email about a certain cycle. > 1. For the mailing list info, there is a link to the old Geocrawler > archives. I think that should probably be removed because SF.net has their > own archives now and they also include the content from the old Geocrawler > archives. You can already get to the SF.net archives by clicking on the > mailing list name and then choosing archives on the following page. It might > be nice to add an archive link right next to every mailing list, so for > example: > > dri-devel [Archives] > dri-user [Archives] > > > > Or just have the mailing list name and have > Subscribe/Unsubscribe/Preferences/Achives next to it like SF.net does. You > can just copy/paste their HTML code. Done something like this. > 2. I really like the new font, it makes things a lot easier to read! But, > the font in the left menu frame is not the same, that should be fixed. You should "arial, helvetica, sans-serif" ring any bells. My mistake was dri.inc isn't used in the menu, besides it never looked ugly under Opera 6 or Netscape 7 iirc. Fixed. > 3. On the status page you have the outstanding infrastructure status at the > bottom. While that certainly is status information, I don't think it fits in > with the other content of the page and is probably also not the kind of > status information a user would be looking for. I suggest you move that > information onto the contribute page and reorganize that page into the > following topics/headings: This I like it, gives the contribute page a reason to exist. > a) "We are looking for more developers" : keep the first three > paragraphs of the intro text as it is now. > > b) "Where to get started?" : link to the developer FAQ, pointer to > mailing lists, link to IRC logs and time (just point to the FAQ questions) > and link to documentation page. So basically the last 4 sentences from the > current page. Ah but with links for those who cant / wont click on Help & FAQ or Documentation even with three (with frames, two without) links on the page. Done. > c) "Outstanding Projects" : the outstanding infrastructure status info, > that would be useful for developers wondering what items still need to be > done (aside from drivers of course). Done and now you begin to see the other need for dri card features lists. > 4. Links on the links page should have target="_top" or "_new" so that they > don't open in a frame. The same goes for the links to the mailing lists and > the links to other peoples pages on the Status page (Leif's page has the > problem, I dunno about the others). Wonder why no one mentioned this, thanks. Nailed those two pages and contribute page, don't think there are anymore, or if they are it's probably better that way. > 5. And my last major major gripe is the frame at the top with the big logo. > It really does take up a lot of screenspace -- even at 1024x768. I really > don't think it's necessary to have it there to remind people that they are > on the DRI site. If you really really want to display the DRI logo I suggest > two things: > > a) BEST --- just put the little DRI logo at the top of the left menu > frame, like on the current site > b) If you really want to have a big top logo on every page, insert it at > the top of the page so I can scroll it out of view. Well I'm leaving it just to bug you Seriously though I think others are far more tolerant of this. > Just modify the dri_header() code for that. I know how to do things, I just don't know which things to do. Now I have a question. In the left hand menu / frame at the bottom is: Hosted by: SourceForge .net Now it is obviously slicker to not have "Hosted by:" but should it (the text) be removed? cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 22:42, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote: > > > It's a big hack to be doing this. > > > > > BTW it also seems to work for him without writing to GEN_INT_CNTL all > > the time, i.e. only acknowledging the bits in GEN_INT_STATUS. Would that > > make it slightly less hackish? :) > > > > A small hack is better than a big one... True. Patch updated and committed. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote: > It's a big hack to be doing this. > > BTW it also seems to work for him without writing to GEN_INT_CNTL all > the time, i.e. only acknowledging the bits in GEN_INT_STATUS. Would that > make it slightly less hackish? :) > A small hack is better than a big one... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote: > > >> > >>It's a big hack to be doing this. BTW it also seems to work for him without writing to GEN_INT_CNTL all the time, i.e. only acknowledging the bits in GEN_INT_STATUS. Would that make it slightly less hackish? :) > >> I'd really like to know why this happens, > >> > > > > So would I. I suspect it's a workaround for some problem, it worked fine > > here without. (as I said on IRC yesterday: but then I have sane hardware > > :) > > > > > >>but in the mean time I'm ok to see it go in. > >> > > > > Okay, I'll commit it later tonight. > > > > > > > >>Maybe I should be more pedantic about things... > >> > > > > Well, I'd rather you wouldn't be speaking in riddles. > > Just about committing code that is a hack-around without really understanding > what's going on. I think it's more or less inevitable, however, with all the > different bits of hardware interacting with each other & us in the middle > trying to sort it out. Yeah, this is pretty complex stuff we're dealing with. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
On Fri, 27 Sep 2002, Jens Owen wrote: > > 2) This one's a little wild just for what you want, but it's something > Workstation Vendors have done in the past to virtualize limited > resources...When stealing memory, setup the page tables to generate a > page fault if it's accessed. Then have the handler steal memory from > another application and replace memory for faulting application. This one sucks. It sucks for multiple reasons, the most important of which just makes it totally unusable: - mapping games only work on page granularity. This may or may not be a problem. But it definitely means, for example, that you cannot use things like the 2/4MB pages on Intel hardware to avoid TLB misses. - mapping games are expensive on SMP (just about anythign else works better) - mapping games don't work at _all_ between threads, since threads share the same mappings (not a problem in some areas, but it can be a _huge_ issue and is very fundamental) - the user not only needs to fault the page in, the user also needs to fill the _contents_ of the page. This means that once you take the page fault, you also need to have a signal handler to actually fill the page with whatever texture (or other data) that you want to bring in to the AGP memory in question. Doing this one page at a time can _really_ suck. - mapping games simply do not work on regular PC hardware, since most of the AGP accesses aren't done from user space at all, but from the card itself. So the access is not a faulting access in the first place: the user "accesses" the AGP memory by giving the graphics card an address to it, and the graphics card will use that address. The last one is the one that makes it totally unusable. You can play games here by doing things like "get the dri lock, then touch all pages in the client that we needed to make sure are there", but once you do that you are already in reality doing everything by hand, so you might as well not use the paging hardware at all. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Multitexturing slowness
On Thu, Sep 26, 2002 at 03:00:02AM +0200, Michel Dänzer wrote: > I've been wondering for some time why at least the Quake 2 engine is > very slow with multitexturing enabled, i.e. with I am using mutlitexturing in my own application, tested on my Voodoo3 but also on Radeon VE, Riva Vanta, or GF. No big slowdowns has beed noticed. -- http://decopter.sf.net - free unrealistic helicopter simulator --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On 27 Sep 2002 18:46:20 +0200 Michel Dänzer <[EMAIL PROTECTED]> wrote: > > > (BTW it would have been a pain in the neck for him to debug this without > > > reinit) I agree ! > > OK, I see it now. > > > > It's a big hack to be doing this. I'd really like to know why this happens, > > So would I. I suspect it's a workaround for some problem, it worked fine > here without. (as I said on IRC yesterday: but then I have sane hardware > :) Why not simply re-enabling IRQ, and wait to see if I'm the only one which have this problem? (do we have more reports than me for this?) Perhaps it's my hardware somewhere which lost somes interrupts some times (about 1500 interupts per seconds isn't it high?) My hardware is: Motherboard k7s5a (chipset sis 735) Processor: Athlon Thunderbird @ 1000Mhz The tests was done with shared irq (IO-APIC), and without (just the card with it's irq) -> should I investigate more here? The radeon card is a 8500 "powered by ATI". I also notified network and/or sound stoping working while playing with 3D (irq enabled). Stoping playing with 3D re-enable network and/or sound. With the patch of Michel, it doesn't seem to arrive again, but i need to do more testings to be sure. - nicolas (nicod) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote: > > from overwriting normalptr and floatcolorptr. :) In actuality, should this > > be expanded anyway? How was the value 15 arrived at? > > Yes, you need a bigger maximum for the extra texture coord. Okay. It should be changed to 19, then? + 3 for normal + 3 for color (or are 3f colors not supported?) + 3 for secondary / fog color (or are 3f colors not supported?) + 2 for texture 0 + 2 for texture 1 + 2 for texture 2 + 2 for texture 3 padding --- 17 Since the previous version wouldn't have had the last 2 fields, why was the size 15 (should have been 13)? Are 3f texcoords supported? Was there just extra space for "someday" when support for the 3rd TMU was added? Whatever change gets made, I'll explain exactly why that value is used in the structure. :) > >>>On other question, that I just noticed. Why is the scale by 8 (shl > >>>$3,%edx), and why is the second store to texcoordptr[0]+4? Are the two sets > >>>of texture coordinates interleaved in a single buffer? > >>> > > > > Okay, I figured this one out for myself. If both texture units are enabled, > > then texcoordptr[1] points to texcoordptr[0][2]. texcoordpointer[n+1] > > should point to texcoordptr[n][2] whenever texture units [0,n] are enabled, > > correct? If that's the case, then I'll make some other changes to this code > > path. > > Yes, the code here only handles size 2 texcoords. > > Right. I wanted to move the code that actually does the allocation, > > deallocation, and stealing into the kernel. The only problem that I saw was > > in notifying applications that their memory had been stolen. Sending a > > signal seemed like it would work, but that also felt like a very ugly > > solution. > > > > Linus, do you have any suggestions on this one? > > It also ties in to the way the driver builds buffers. If an app has a > half-built buffer hanging around with texture addresses in it, somebody's got > to go through and find the dead references. > > One option is to have the kernel actually do the fixup of the buffers when > they are submitted by the client, so the driver never knows really where it's > textures are, but talks about them via. some indirection. Interesting. Basically we'd have a kernel API that would mirror a subset of the OpenGL texture API? Something like: int drmCreateTexture( int fd, int * texture_handle, int target, unsigned width, unsigned height, unsigned depth, unsigned bytes_per_texel, int mipmaps ); int drmDestroyTexture( int fd, int texture_handle ); int drmUploadTextureData( int fd, int texture_handle, int level, int xoffset, int yoffset, int zoffset, int width, int height, int depth, void * pixels ); The 'mipmaps' value of Create would have to tell it 'none', 'user supplied', or 'acclerated SGIS_create_mipmaps'. The assumption is that the user-mode driver would supply data to the kernel in the format that it needs to be in. Then the texture pointer programmed by the user-mode driver would be the 'texture_handle' returned by CreateTexture. The kernel would then have to make sure that the texture was addressable and fix-up the pointer. Would some sort of fencing be needed? By that I mean, we're programming in texture addresses and stealing textures. Do we need to know when the card is done rendering the polygons that reference a texture to know when it can safely be kicked-out? What sort of semantics would we want for what the kernel could do with the 'pixels' pointer? Would it be the same as for TexImage or could it keep the pointer until replaced or the texture is destroyed? The latter seems better to me. That might even allow directly mapping the user-mode pointer into AGP space. That being the case, we might change the API all together. Replace UploadTextureData with SetTexturePointer / LockTexture / UnlockTexture. Then user-mode could do all of the TexSubImage-like copying. > One viatal property any of these schemes must support is accelerated > CopyTexSubImage: this can't be done unless you know that the data on the card > is somehow protected, and won't get thrown in the bit bucket by some other app. Right. This is something that's been missing from DRI for way too long. :) This would also enable support for accelereated SGIS_generate_mipmaps. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
Ian Romanick wrote: >>>A lot of this stuff is inherently device independent with some device >>>dependent "direction" (i.e., *ChooseTextureFormat), but it hasn't been >>>implemented that way. As a reference point, my previous work removed >>>somewhere around 450 lines of code from the MGA driver (~5%). The gains in >>>the Radeon weren't quite as significant (there was no radeon_texcnv.c to get >>>rid of). This just feels like a win-win to me. :) >>> >>>Having all of it in the kernel will make it easier to implement other >>>off-screen buffers that can't be stolen (i.e., pbuffers, dynamically >>>allocated back/depth buffer, etc.). >> >>I take it you don't really mean "all" of it, ie. not the texture conversion >>stuff you mention in the preceding paragraph. > > > Right. I wanted to move the code that actually does the allocation, > deallocation, and stealing into the kernel. The only problem that I saw was > in notifying applications that their memory had been stolen. Sending a > signal seemed like it would work, but that also felt like a very ugly > solution. Two potential solutions that I can think of: 1) Track what's valid and not in shared memory and have the client check before using it. Access may need to be protected with a semaphore or DRM lock. 2) This one's a little wild just for what you want, but it's something Workstation Vendors have done in the past to virtualize limited resources...When stealing memory, setup the page tables to generate a page fault if it's accessed. Then have the handler steal memory from another application and replace memory for faulting application. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
On Fri, 27 Sep 2002, Ian Romanick wrote: > > > > A lot of this stuff is inherently device independent with some device > > > dependent "direction" (i.e., *ChooseTextureFormat), but it hasn't been > > > implemented that way. As a reference point, my previous work removed > > > somewhere around 450 lines of code from the MGA driver (~5%). The gains in > > > the Radeon weren't quite as significant (there was no radeon_texcnv.c to get > > > rid of). This just feels like a win-win to me. :) > > > > > > Having all of it in the kernel will make it easier to implement other > > > off-screen buffers that can't be stolen (i.e., pbuffers, dynamically > > > allocated back/depth buffer, etc.). > > > > I take it you don't really mean "all" of it, ie. not the texture conversion > > stuff you mention in the preceding paragraph. > > Right. I wanted to move the code that actually does the allocation, > deallocation, and stealing into the kernel. The only problem that I saw was > in notifying applications that their memory had been stolen. Sending a > signal seemed like it would work, but that also felt like a very ugly > solution. > > Linus, do you have any suggestions on this one? Hmm.. I don't have enough background here to make any good suggestions (I obviously do read the list, but I skim it much more quickly than my kernel mails). It depends a lot on what the usage pattern is. Sending a signal is not extremely fast, but I assume that stealing is a fairly rare event (and signals are by no means _slow_ either, so don't get me wrong). The main problems with signals tend to be that they are hard to use (asynchronous code always is), and that they can be problematic with threads (_which_ thread gets the signal? It's going to be pretty random). There's also some inherent races here: if you need to tell the user that the AGP memory manager stole part of the memory, then how do you make sure he isn't just using it. And having a two-phase hand-off is _really_ slow, since that means context switching back and forth. If we assume that a user can only depend on it's memory map while it is holding the dri lock (to avoid the races with memory going away while being used), then the taking of the lock also becomes the obvious place to notify the user that the memory is gone. One simple and race-free approach is to extend the locking mechanism to include a list of required memory regions (maybe the list can be a single element - this all depends on what the usage pattern is). So instead of just asking for the lock, you ask for the lock _and_ access to your memory region X - and if the memory is gone it returns with some logical error code to tell the user to re-allocate and fill in the texture cache. (Think of the locking as "page faulting" in the AGP memory - the kernel keeps track of the cache of AGP regions, and if the kernel decided to give your region away then you need to re-prime the dang thing). Would that be an acceptable approach? It should be fairly simple to make: each AGP memory area that the kernel keeps track of needs to have a few extra bits associated with it: - current owner / validation / cookie whatever - "am I filled in?" (ie a "cache valid" bit) - usage count or "locked bit" to allow clients to say that the cached region cannot be stolen. - possibly things like dirty and accessed bits that may matter to the stealing policy Think of it as a regular data cache that just happens to be sw managed. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: [Dri-users] Re: S3TC texture compression ATI Cards
> "Charlie" == Charlie Grosvenor <[EMAIL PROTECTED]> writes: Charlie> I am thinking of purchasing a Maya AP Radeon 8500 Deluxe 64MB DDR AGP RP Charlie> VO DVI, what do people think of this card? What is the status of the Charlie> open source drivers? How good are they? Is the dual head supported in Charlie> Linux? Apart from not supporting S3TC texture compression is there any Charlie> thing else that would stop me from playing UT 2003 in Linux? Thanks to The Weather Channel the drivers are working good and are getting better and better - although I occasionally have lockups here. 3D performance is OK - it's not as much as under WinXP - , 2D is solved by now, too. Concerning UT2K3: on the homepage they said that the OpenGL driver is far beyoond the Direct3D one, which means that you will get less fps. I don't know how much, have no cards to try. Bye, Adam. -- Adam Duck ([EMAIL PROTECTED]) Bockenheimer Landstr. 135 / Zi. 211 60325 Frankfurt/Main __ If it's zero degrees outside today and it's supposed to be twice as cold tomorrow, how cold is it going to be? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
> > Right. Here's my updated suggestion. Leave the '&3' in the patch, but > expand the 'vertex' array in radeon_vb from 15 elements to 17. That will > prevent code like > > glMultiTexCoord2fv( GL_TEXTURE3, foo ); Yes, that works for this path. The other you have to look at is where the generated code actually dereferences the texcoordptr array -- it means we need 4 elements in there, one of them a dummy. > from overwriting normalptr and floatcolorptr. :) In actuality, should this > be expanded anyway? How was the value 15 arrived at? Yes, you need a bigger maximum for the extra texture coord. > >>>On other question, that I just noticed. Why is the scale by 8 (shl >>>$3,%edx), and why is the second store to texcoordptr[0]+4? Are the two sets >>>of texture coordinates interleaved in a single buffer? >>> > > Okay, I figured this one out for myself. If both texture units are enabled, > then texcoordptr[1] points to texcoordptr[0][2]. texcoordpointer[n+1] > should point to texcoordptr[n][2] whenever texture units [0,n] are enabled, > correct? If that's the case, then I'll make some other changes to this code > path. Yes, the code here only handles size 2 texcoords. > Right. I wanted to move the code that actually does the allocation, > deallocation, and stealing into the kernel. The only problem that I saw was > in notifying applications that their memory had been stolen. Sending a > signal seemed like it would work, but that also felt like a very ugly > solution. > > Linus, do you have any suggestions on this one? It also ties in to the way the driver builds buffers. If an app has a half-built buffer hanging around with texture addresses in it, somebody's got to go through and find the dead references. One option is to have the kernel actually do the fixup of the buffers when they are submitted by the client, so the driver never knows really where it's textures are, but talks about them via. some indirection. This scheme appeals to me, but so does static allocation... One viatal property any of these schemes must support is accelerated CopyTexSubImage: this can't be done unless you know that the data on the card is somehow protected, and won't get thrown in the bit bucket by some other app. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] nForce and AGPGART
On Fri, 2002-09-27 at 13:51, Dieter Nützel wrote: > > Is it true that the nForce is unsupported by agpgart > Yes. News to me that it is > Have a close look at LKML and watch out for some posts from Alan Cox about > nForce. I think I remember he had something going. We have IDE (in the newest tree) and basic audio for the nForce but no graphics stuff. If there is AGP support then its in the XFree cvs but not yet in the kernel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fri, 2002-09-27 at 17:01, Michel Dänzer wrote: > > Yep, but I guess you have to worry about then going to sleep *after* the > > interrupt has arrived, if there is a delay in getting the scratch write across > > the bus, compared to the irq, which should be instantaneous. > > Is that really an issue? The scratch register is written to before the > interrupt is triggered, so I'd expect a register read to yield the > correct value when the interrupt has arrived. Interrupt delivery on x86 is extremely asynchronous on some systems - especially Pentium II/Pentium III SMP boxes. You can sometimes see situations like IRQ raised driver clear irq allowed flag driver reads PCI bus to force posting driver free some resources IRQ arruves driver explodes In almost all cases PCI/IRQ synchronization isnt quite what you might intuitively wish for or expect. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
On Thu, Sep 26, 2002 at 04:51:37PM +0100, Keith Whitwell wrote: > Ian Romanick wrote: > > On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote: > > I guess my problem is, should values other than [GL_TEXTURE0, GL_TEXTURE0 + > > MAX_TEXTURE_UNITS] ever get this far in the pipeline? > > This far This function gets hooked right into the dispatch table! Yeah, I knew that. :) > >>which is slightly more work when looking at the codegen templates. > > > > On archs. with CMOV we could work around this with something like (this is > > off the top of my head): [snip] > > On any of the archs. that support CMOV, that only adds 2 instructions and > > should only add 2 clock cycles. In any case, it would be a trivial > > addition. > > Yes, but the generic x86 arch doesn't have cmov. For p4's we really want to > be using sse2, so yes, p3's and athlons could do this. Right. Here's my updated suggestion. Leave the '&3' in the patch, but expand the 'vertex' array in radeon_vb from 15 elements to 17. That will prevent code like glMultiTexCoord2fv( GL_TEXTURE3, foo ); from overwriting normalptr and floatcolorptr. :) In actuality, should this be expanded anyway? How was the value 15 arrived at? > > On other question, that I just noticed. Why is the scale by 8 (shl > > $3,%edx), and why is the second store to texcoordptr[0]+4? Are the two sets > > of texture coordinates interleaved in a single buffer? Okay, I figured this one out for myself. If both texture units are enabled, then texcoordptr[1] points to texcoordptr[0][2]. texcoordpointer[n+1] should point to texcoordptr[n][2] whenever texture units [0,n] are enabled, correct? If that's the case, then I'll make some other changes to this code path. > >>>By the end of this week I hope to have two more Radeon patches (one to fix > >>>one of the crashes on non-TCL hw, and one to enable AGP textures). I've > >>>finally gotten back to cleaning up my old texture manager patch, so I hope > >>>to get that out RSN as well. > >>> > >>Please note that the r200 has taken a divergent path with respect to the use > >>of the agp texture memory. In summary, there's a kernel-space manager for > >>this memory heap which allows us to divide up that region of agp space without > >>the fear that it will be 'stolen' by another context, as the existing texture > >>management code allows. This allows me to implement the client agp allocator > >>from GL_NV_vertex_array_range, and will allow a full implementation of that > >>extension presently... [snip] > > What I'd really like to see is other drivers implement this as > > well. At some level, it could be moved to the device independent part of > > the DRM. One of the things that irritated me the most in my previous > > texture management work was how differently each driver allocated and > > managed textures. One of the first things I did in the MGA driver was > > eliminate the need for mgatexcnv.c and make mgaChooseTextureFormat work like > > the Radeon driver. > > This is historic (the mga part) -- the radeon driver uses new facilities that > weren't available at the time the mga driver was written. That's pretty much what I figured. > > A lot of this stuff is inherently device independent with some device > > dependent "direction" (i.e., *ChooseTextureFormat), but it hasn't been > > implemented that way. As a reference point, my previous work removed > > somewhere around 450 lines of code from the MGA driver (~5%). The gains in > > the Radeon weren't quite as significant (there was no radeon_texcnv.c to get > > rid of). This just feels like a win-win to me. :) > > > > Having all of it in the kernel will make it easier to implement other > > off-screen buffers that can't be stolen (i.e., pbuffers, dynamically > > allocated back/depth buffer, etc.). > > I take it you don't really mean "all" of it, ie. not the texture conversion > stuff you mention in the preceding paragraph. Right. I wanted to move the code that actually does the allocation, deallocation, and stealing into the kernel. The only problem that I saw was in notifying applications that their memory had been stolen. Sending a signal seemed like it would work, but that also felt like a very ugly solution. Linus, do you have any suggestions on this one? > > 3. I honestly do not think that NV_var should be exposed by any driver that > > doesn't already expose it (on any platform). The biggest problem with that > > extension is that it requires applications to know a priori if a SW TCL > > fallback will be needed. This can be problematic enough just across the > > GeForce line! Not only that, NV_var is really hard to use correctly (for > > the most common uses) w/o NV_fence. A better choice for right now would be > > ATI_vertex_array_object, and hopefully something better will be available > > soon. > > We want NV_fence as well, hence the irq ioctls in the newest r200 work. > > > Given some of the interrupt
Re: [Dri-devel] nForce and AGPGART
Alexander Stohr wrote: > Can you please send the outputs of > `lspci -v -xxx` to the list? > Sure. 00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2) Flags: bus master, 66Mhz, fast devsel, latency 0 Memory at e000 (32-bit, prefetchable) [size=256M] Capabilities: [40] AGP version 2.0 Capabilities: [60] #08 [2001] 00: de 10 a4 01 06 00 b0 00 b2 00 00 06 00 00 80 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 02 60 20 00 17 02 00 1f 04 01 00 00 ff ff ff ff 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 60: 08 00 01 20 20 00 88 88 10 00 00 00 01 0f 0f 0f 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80: 08 01 00 00 ff ff ff 3f 00 00 00 00 12 ff fe 3f 90: 00 00 00 00 ff 6f ff ff 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: f1 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 33 33 03 00 33 33 03 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 01 00 00 00 ff ff f0 07 02 00 00 00 e0: 0e 00 47 00 96 34 ff 01 00 00 00 00 00 00 00 00 f0: 09 00 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)Subsystem: nVidia Corporation: Unknown device 0c11 Flags: 66Mhz, fast devsel 00: de 10 ac 01 00 00 20 00 b2 00 00 05 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 01 00 00 ff 44 ff 66 ff 99 ff 99 ff 99 ff 99 50: ff 44 ff 66 88 ff 88 ff f0 00 e0 00 7f 3f fe 0f 60: 00 00 00 80 00 00 00 00 01 00 00 00 01 00 00 00 70: 38 20 00 00 38 20 00 00 1f 00 00 01 11 10 0f 17 80: 2f 2f 2f 31 33 35 33 33 0b 0b 0b 0b 0c 0d 0c 0c 90: 09 0a 33 33 40 32 43 22 1f 04 61 03 20 00 00 00 a0: 6a 00 00 00 02 00 20 00 6a 00 00 00 02 00 20 00 b0: 6a 00 00 00 02 00 20 00 2a 00 00 00 01 00 20 00 c0: 06 00 00 00 00 00 00 00 00 00 00 00 80 88 02 00 d0: 40 4c 00 00 20 22 00 00 0c 00 00 00 0e 00 00 00 e0: 0a 00 00 00 80 00 00 00 88 44 92 24 11 10 00 00 f0: 18 10 00 11 20 20 00 00 01 04 00 00 31 02 03 32 00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)Subsystem: nVidia Corporation: Unknown device 0c11 Flags: 66Mhz, fast devsel 00: de 10 ad 01 00 00 20 00 b2 00 00 05 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 01 20 22 01 01 20 22 01 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: ff ff 7b 5e ff ff ab 5b ff ff 15 2f ff 7f b5 2d 80: ff ff ea 3f ff ff 87 49 ff 7f f7 0f ff ff d6 63 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 02 08 00 00 00 00 00 00 d0: 11 00 00 00 04 00 00 00 00 00 00 e0 ff ff ff ef e0: 01 00 48 0c 01 00 49 0c 01 00 4a 0c 01 00 4b 0c f0: 01 00 48 0c 01 00 49 0c 01 00 4a 0c 01 00 4b 0c 00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2) Subsystem: nVidia Corporation: Unknown device 0c11 Flags: 66Mhz, fast devsel 00: de 10 ab 01 00 00 20 00 b2 00 00 05 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 80 80 50 50 00 40 80 0f 65 65 55 66 86 77 77 86 50: 65 65 55 00 cb bb 00 00 35 33 04 00 10 10 03 00 60: 56 66 00 00 01 80 e0 00 6b 00 00 00 03 03 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3) Subsystem: nVidia Corporation: Unknown device 0c11 Flags: bus master, 66Mhz, fast devsel, latency 0 Capabilities: [50] #08 [01e1] 00: de 10 b2 01 0f 00 b0 00 c3 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 00 00 40: de 10 11 0c 00 00 10 20 00 07 00 00 de fd 00 00 50: 08 00 e1 01 60 00 88 88 a0 00 00 00 00 00 00 00 60: 00 00 00 00 09 05 0b 00 03 10 55 50 aa 00 00 00 70: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 10 00 07 01 e4 00 00 0f 00 00 00 00 3c 00 88 90: 80 00 00 00 00 00 00 00 02 70 1c 81 06 a1 1c 87 a0: 00 00 00 00 44 00 50 01 04 00 15 00 01 00 07 00 b0: 00 00 01 02 12 00 01 00 00
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
>> >>It's a big hack to be doing this. I'd really like to know why this happens, >> > > So would I. I suspect it's a workaround for some problem, it worked fine > here without. (as I said on IRC yesterday: but then I have sane hardware > :) > > >>but in the mean time I'm ok to see it go in. >> > > Okay, I'll commit it later tonight. > > > >>Maybe I should be more pedantic about things... >> > > Well, I'd rather you wouldn't be speaking in riddles. Just about committing code that is a hack-around without really understanding what's going on. I think it's more or less inevitable, however, with all the different bits of hardware interacting with each other & us in the middle trying to sort it out. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 18:11, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote: > > > >>Michel Dänzer wrote: > >> > >>>On Don, 2002-09-26 at 18:17, Keith Whitwell wrote: > >>> > >>> > Michel Dänzer wrote: > > > >Something else I've been thinking about is that relying on the > >swi_emitted and swi_received counters being in sync is pretty fragile. > >It might be better to use a scratch register instead. > > > > > Yes, it could be made more robust. > > > >>>Do you think the approach with a scratch register is good? > >>> > >>Yep, but I guess you have to worry about then going to sleep *after* the > >>interrupt has arrived, if there is a delay in getting the scratch write across > >>the bus, compared to the irq, which should be instantaneous. > >> > > > > Is that really an issue? The scratch register is written to before the > > interrupt is triggered, so I'd expect a register read to yield the > > correct value when the interrupt has arrived. > > I was under the understanding that the scratch registers were actually > 'shadows' in main memory, updated by the card across the agp bus. If so, I > don't think there's any guarantee of synchronization with the irq delivery. > Maybe it's not a real risk, but certainly worthwhile to keep it in mind. That's one reason why I don't use writeback for this one. It should normally only be read once or twice per interrupt anyway. > We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out > what has happened -- particularly have the interrupts been disabled? > > > >>>Turns out they haven't. GEN_INT_CNTL looks exactly like it should. > >>>Interestingly, the GEN_INT_STATUS bits are set as well, and > >>>acknowledging them helps. So it seems that somehow, the service routine > >>>didn't get called for an interrupt, or the acknowledgement got lost. > >>> > >>>If the updated patch works for you as well, I'll commit it. > >>> > >>The patch doesn't seem to do anything about this case, just print something out... > >> > > > > Are we talking about the same patch, > > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff with md5sum > > 6abf27a2a1d6a4e57a8c36b19ef0e17b? It worked fine for nicod yesterday... > > (BTW it would have been a pain in the neck for him to debug this without > > reinit) > > OK, I see it now. > > It's a big hack to be doing this. I'd really like to know why this happens, So would I. I suspect it's a workaround for some problem, it worked fine here without. (as I said on IRC yesterday: but then I have sane hardware :) > but in the mean time I'm ok to see it go in. Okay, I'll commit it later tonight. > Maybe I should be more pedantic about things... Well, I'd rather you wouldn't be speaking in riddles. ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] (r200) AGP Fast Write disabled by default
Keith Whitwell wrote: > Stephane Chauveau wrote: > >> Hi, >> >> The r200 dri drivers are working fine on my system but I noticed >> something strange in my logs: >> >> (**) RADEON(0): Using AGP 4x mode >> (II) RADEON(0): AGP Fast Write disabled by default >> >> My bios says that AGP Fast Write is enabled. >> >> Is there an issue with AGP Fast Write and the r200? >> >> I couldn't find anything about AGP fast write in XFree86 documentation >> but I assume that if it is 'disabled by default' then there should be >> a way to enable it. >> > > Option "AGPFastWrite" "1" > > I think there are problems with some motherboards, i845 in particular... > > Keith Thanks. Is there a documentation for those options? For AGPFastWrite, Google gives me one message in dri-patches and a bunch of japanese pages and, guess what! I don't speak japanese :-) S. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote: > >>Michel Dänzer wrote: >> >>>On Don, 2002-09-26 at 18:17, Keith Whitwell wrote: >>> >>> Michel Dänzer wrote: >Something else I've been thinking about is that relying on the >swi_emitted and swi_received counters being in sync is pretty fragile. >It might be better to use a scratch register instead. > > Yes, it could be made more robust. >>>Do you think the approach with a scratch register is good? >>> >>Yep, but I guess you have to worry about then going to sleep *after* the >>interrupt has arrived, if there is a delay in getting the scratch write across >>the bus, compared to the irq, which should be instantaneous. >> > > Is that really an issue? The scratch register is written to before the > interrupt is triggered, so I'd expect a register read to yield the > correct value when the interrupt has arrived. I was under the understanding that the scratch registers were actually 'shadows' in main memory, updated by the card across the agp bus. If so, I don't think there's any guarantee of synchronization with the irq delivery. Maybe it's not a real risk, but certainly worthwhile to keep it in mind. > > >>... >> >> We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out what has happened -- particularly have the interrupts been disabled? >>>Turns out they haven't. GEN_INT_CNTL looks exactly like it should. >>>Interestingly, the GEN_INT_STATUS bits are set as well, and >>>acknowledging them helps. So it seems that somehow, the service routine >>>didn't get called for an interrupt, or the acknowledgement got lost. >>> >>>If the updated patch works for you as well, I'll commit it. >>> >>The patch doesn't seem to do anything about this case, just print something out... >> > > Are we talking about the same patch, > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff with md5sum > 6abf27a2a1d6a4e57a8c36b19ef0e17b? It worked fine for nicod yesterday... > (BTW it would have been a pain in the neck for him to debug this without > reinit) OK, I see it now. It's a big hack to be doing this. I'd really like to know why this happens, but in the mean time I'm ok to see it go in. Maybe I should be more pedantic about things... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Don, 2002-09-26 at 18:17, Keith Whitwell wrote: > > > >>Michel Dänzer wrote: > >> > >>>Something else I've been thinking about is that relying on the > >>>swi_emitted and swi_received counters being in sync is pretty fragile. > >>>It might be better to use a scratch register instead. > >>> > >>Yes, it could be made more robust. > >> > > > > Do you think the approach with a scratch register is good? > > Yep, but I guess you have to worry about then going to sleep *after* the > interrupt has arrived, if there is a delay in getting the scratch write across > the bus, compared to the irq, which should be instantaneous. Is that really an issue? The scratch register is written to before the interrupt is triggered, so I'd expect a register read to yield the correct value when the interrupt has arrived. > ... > > >>We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out > >>what has happened -- particularly have the interrupts been disabled? > >> > > > > Turns out they haven't. GEN_INT_CNTL looks exactly like it should. > > Interestingly, the GEN_INT_STATUS bits are set as well, and > > acknowledging them helps. So it seems that somehow, the service routine > > didn't get called for an interrupt, or the acknowledgement got lost. > > > > If the updated patch works for you as well, I'll commit it. > > The patch doesn't seem to do anything about this case, just print something out... Are we talking about the same patch, http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff with md5sum 6abf27a2a1d6a4e57a8c36b19ef0e17b? It worked fine for nicod yesterday... (BTW it would have been a pain in the neck for him to debug this without reinit) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] (r200) AGP Fast Write disabled by default
Stephane Chauveau wrote: > Hi, > > The r200 dri drivers are working fine on my system but I noticed > something strange in my logs: > > (**) RADEON(0): Using AGP 4x mode > (II) RADEON(0): AGP Fast Write disabled by default > > My bios says that AGP Fast Write is enabled. > > Is there an issue with AGP Fast Write and the r200? > > I couldn't find anything about AGP fast write in XFree86 documentation > but I assume that if it is 'disabled by default' then there should be a > way to enable it. > Option "AGPFastWrite" "1" I think there are problems with some motherboards, i845 in particular... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] (r200) AGP Fast Write disabled by default
Hi, The r200 dri drivers are working fine on my system but I noticed something strange in my logs: (**) RADEON(0): Using AGP 4x mode (II) RADEON(0): AGP Fast Write disabled by default My bios says that AGP Fast Write is enabled. Is there an issue with AGP Fast Write and the r200? I couldn't find anything about AGP fast write in XFree86 documentation but I assume that if it is 'disabled by default' then there should be a way to enable it. Stephane. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Don, 2002-09-26 at 18:17, Keith Whitwell wrote: > >>Michel Dänzer wrote: >> >>>Something else I've been thinking about is that relying on the >>>swi_emitted and swi_received counters being in sync is pretty fragile. >>>It might be better to use a scratch register instead. >>> >>Yes, it could be made more robust. >> > > Do you think the approach with a scratch register is good? Yep, but I guess you have to worry about then going to sleep *after* the interrupt has arrived, if there is a delay in getting the scratch write across the bus, compared to the irq, which should be instantaneous. ... >>We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out >>what has happened -- particularly have the interrupts been disabled? >> > > Turns out they haven't. GEN_INT_CNTL looks exactly like it should. > Interestingly, the GEN_INT_STATUS bits are set as well, and > acknowledging them helps. So it seems that somehow, the service routine > didn't get called for an interrupt, or the acknowledgement got lost. > > If the updated patch works for you as well, I'll commit it. The patch doesn't seem to do anything about this case, just print something out... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snapshots now being built with gcc 3.2
On Fre, 2002-09-27 at 04:25, Andy Dustman wrote: > > Most obvious feature of this is what looks like a NULL pointer > reference at the end. Also there is a load/unload/load of the xaa > module. That's expeceted, the only way to find out the version of the xaa module is to try loading the new version and if that fails the old one. > Driver provided ScreenToScreenBitBlt replacement > Driver provided FillSolidRects replacement > Driver provided WriteBitmap replacement > Driver provided NonTEGlyphRenderer replacement No it doesn't, actually... this really smells like the layout of the XAAInfoRec struct has changed between compiler versions, it would be interesting to see if a binary snapshot built with the same compiler as the rest of the X server has the same problem. > With the 20020926 official snapshot, the last line is the "Silken mouse" > message. Otherwise the log appears to be the same. Hmm, I committed the last XAA changes (trying to fix the incompatibility) on the 24th... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website
Am Freitag, 27. September 2002 06:19 schrieb Frank Worsley: > > btw what about now? > > Much, much better. I have a few more comments though . ;) > > 1. For the mailing list info, there is a link to the old Geocrawler > archives. I think that should probably be removed because SF.net has their > own archives now and they also include the content from the old Geocrawler > archives. You can already get to the SF.net archives by clicking on the > mailing list name and then choosing archives on the following page. It > might be nice to add an archive link right next to every mailing list, so > for example: > > dri-devel [Archives] > dri-user [Archives] What about the main central archive? http://marc.theaimsgroup.com/?l=dri-devel&r=1&w=2 It is fast and dany. Thanks, Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] nForce and AGPGART
Am Freitag, 27. September 2002 08:26 schrieb Rene Sepulveda: > I tried to install a Radeon 8500 on a system with an nForce-based > motherboard but I couldn't direct rendering to work because agpgart > failed to load: > > Linux agpgart interface v0.99 (c) Jeff Hartmann > agpgart: Maximum main memory to use for agp memory: 816M > agpgart: unsupported bridge > agpgart: no supported devices found. > > Is it true that the nForce is unsupported by agpgart Yes. > or am I doing something wrong? No. > I looked at the agpgart code in the 2.4.19 gentoo > kernel and sure enough I saw no references to nForce or Nvidia in the > code and in particular no nForce in the agp_bridge_info array. > > I tried agp_try_unsupported=1 but that didn't help. Good try. Have a close look at LKML and watch out for some posts from Alan Cox about nForce. I think I remember he had something going. -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] nForce and AGPGART
Title: RE: [Dri-devel] nForce and AGPGART Can you please send the outputs of `lspci -v -xxx` to the list? > -Original Message- > From: Rene Sepulveda [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 27, 2002 08:27 > To: [EMAIL PROTECTED] > Subject: [Dri-devel] nForce and AGPGART > > > I tried to install a Radeon 8500 on a system with an nForce-based > motherboard but I couldn't direct rendering to work because agpgart > failed to load: > > Linux agpgart interface v0.99 (c) Jeff Hartmann > agpgart: Maximum main memory to use for agp memory: 816M > agpgart: unsupported bridge > agpgart: no supported devices found. > > Is it true that the nForce is unsupported by agpgart or am I doing > something wrong? I looked at the agpgart code in the 2.4.19 gentoo > kernel and sure enough I saw no references to nForce or Nvidia in the > code and in particular no nForce in the agp_bridge_info array. > > I tried agp_try_unsupported=1 but that didn't help. > > Thanks, > > Rene > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > >
Re: [Dri-devel] Snapshots now being built with gcc 3.2
On Fri, 2002-09-27 at 04:25, Andy Dustman wrote: > Still getting the same problem with the r200. Interestingly, the amount > of memory used for textures has gone up recently, from about 93 MB to > 113 MB. Most obvious feature of this is what looks like a NULL pointer > reference at the end. Also there is a load/unload/load of the xaa > module. > > (WW) module minor version (0) is less than the required minor version (1) Hmmm, Michel, is this what you expect? Andy, you can download from my site http://cpotha.net/dri_resume.html my latest snapshot just for the included libxaa.a and libGL* - copy these out over your dri.sf.net installation. > One other thing: There is a variable in the dripkg.sh script, > PKG_MINIMAL=1, which is causing GL and core libraries not to be included > the snapshot. Commenting this out reveals that the non-shared libraries > are not getting built anyway. As above, you can get more up to date libGL.* thingies from my snapshot. HTH, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
