From: Alexander S. <Ale...@at...> - 2001-12-12 12:36:18
|
> > > typedef struct _agp_allocate { > > > size_t pg_count; /* number of pages */ > > > [Is this really "number of pages", or is it actually > > > "amount of memory"? If really "number of pages", > > > then WHY ISNT IT AN INT?!!] > > > > > > From what is in the code, AFAI understand, this *is* > really the number > > of pages. And 'size_t' is nothing but an 'unsigned int' ... > > Whether it really is an int underneath, is not the point. > "size_t" should be used for "sizes". > Mostly for BYTE counts of buffers. > eg: read(char *,size_t) > write(char *,size_t) > bcopy (const void *, void *, size_t) > > "number of pages" is not a "size". It's a count. Hence it should be > declared as a plain int. Similarly with the other ones in agpgart. > Declaring it as size_t makes it seem like it is the bytecount > of all the > pages, rather than a number of pages. possibly i am thinking a bit more practical: - the number of pages should never go negative, so why do we need the sign? - there is no reason why the number of pages should get limited to i.e. 2 GB instead of 4 GB on 32 bit machines. - you are right in trying to distinguish number_of_bytes and number_of_elements by meance of different type defines for them. - i am not aware of a better type define - you might want to suggest a new one. Suggestion: typedef unsigned int elcount_t; or #define elcount_t unsigned int But to proove you the opposite: void *calloc(size_t nmemb, size_t size); nmemb => number_of_elements size => number_of_bytes (per element of course) so the usage is already a bit puzzled for other central areas. don't blame the agpgart programmers for introducing this... |
From: Alexander S. <Ale...@at...> - 2001-12-12 20:47:14
|
> But we're talking page count, not byte count. So signed vs unsigned is > something like having 8 vs 16 TERRABYTES addressable. > Personally, I dont think that should be an issue :-) well estimated. ;-) consider such a coding: size_t size_of_one_member, total_size_in_bytes; int number_of_members; total_size_in_bytes = size_of_one_member * number_of_members; this might cause some warnings due to the required type intermixing. storing similar objects in compatible types sounds reasonable to me. > So allowing signed int for pagecounts, means you can allow -1 > as a flag for "uninitialized" or something. a special value of zero is sufficient here. > Maybe not passing back to the user. But in internal routines > that calculate pagecounts, etc. with a -1 in that member all your calculations will need extra code for testing this or will give wrong results Regards Alex. PS: to Gareth - i dont do it, unless you give me CVS write permission... |
From: Philip B. <ph...@bo...> - 2001-12-13 01:14:40
|
On Wed, Dec 12, 2001 at 09:46:23PM +0100, Alexander Stohr wrote: > [phil brown wrote] > > So allowing signed int for pagecounts, means you can allow -1 > > as a flag for "uninitialized" or something. > > a special value of zero is sufficient here. well, yeah, pagecount=0 is fine for an error flag :-) But when you're talking about page INDEX, aka "page offset", thats another thing that should be plain signed int. "off_t" is really only supposed to be used for DISK OFFSETS. It even specifically says it is for disk offsets, if you do grep 'off_t;' /usr/include/sys/types.h under either BSD or Solaris. |
From: Philip B. <ph...@bo...> - 2001-12-14 03:12:37
|
It's turning out to be a real pain to port the current schema of AGP usage, due to memory mapping issues. It would be more doable if I could assume that the AGP memory to be allocated+bound would ALWAYS, 100% be only read by the device, and never written to by the device. (doesnt matter if the user app reads and writes: just the device needs to be unidirectional) Can I make that assumption? |
From: Gareth H. <gar...@ac...> - 2001-12-14 03:23:21
|
On Thu, Dec 13, 2001 at 07:12:31PM -0800, Philip Brown wrote: > It's turning out to be a real pain to port the current schema of > AGP usage, due to memory mapping issues. > > It would be more doable if I could assume that the AGP memory to be > allocated+bound would ALWAYS, 100% be only read by the device, and > never written to by the device. > (doesnt matter if the user app reads and writes: just the device needs > to be unidirectional) > > Can I make that assumption? No. -- Gareth |
From: Nathan Thompson-A. <nd...@wa...> - 2001-12-15 01:36:04
|
Hi all, I've got a Matrox G200 with 8MB RAM that I'm having some trouble with. OpenGL programs that don't use textures (as far as I can tell) work fine; Xscreensaver's bubble3d and sierpinksi3d, for example, work correctly. But other OpenGL programs, like atlantis and Quake II, display with wrong (purple garbage) textures and cause the console to spew out "Failed to upload texture" messages. I went through the user guide at http://dri.sourceforge.net/doc/DRIuserguide.html, but it doesn't seem to cover this issue. Are there any other things I could try? Any more appropriate forums I could post to? Further hardware & software specs, if it matters: AMD K6-2 450MHz, 128 MB RAM, AGP enabled; using kernel 2.4.7, XF86 4.1.0 (the stock Red Hat 7.2 stuff) Also, textures worked correctly under XF86 3.something using Utah-GLX. So it's probably not the hardware. :-) Thanks, Nathan |
From: Damien M. <dj...@mi...> - 2001-12-16 07:07:35
|
On 14 Dec 2001, Nathan Thompson-Amato wrote: > Hi all, > > I've got a Matrox G200 with 8MB RAM that I'm having some trouble with. > OpenGL programs that don't use textures (as far as I can tell) work > fine; Xscreensaver's bubble3d and sierpinksi3d, for example, work > correctly. But other OpenGL programs, like atlantis and Quake II, > display with wrong (purple garbage) textures and cause the console to > spew out "Failed to upload texture" messages. You screen resolution is probably too high, thus causing the card to run out of memory. Try dropping it and seeing of the screensavers work. Would the AGP texturing patch for the Matrox cards that was floating around the list a few weeks ago help here? -d -- | By convention there is color, \\ Damien Miller <dj...@mi...> | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) |
From: Nathan Thompson-A. <nd...@wa...> - 2001-12-18 01:47:34
|
On Sun, 2001-12-16 at 02:07, Damien Miller wrote: > On 14 Dec 2001, Nathan Thompson-Amato wrote: > > > > > OpenGL programs that don't use textures (as far as I can tell) work > > fine; Xscreensaver's bubble3d and sierpinksi3d, for example, work > > correctly. But other OpenGL programs, like atlantis and Quake II, > > display with wrong (purple garbage) textures and cause the console to > > spew out "Failed to upload texture" messages. > > You screen resolution is probably too high, thus causing the card to > run out of memory. Try dropping it and seeing of the screensavers > work. That did the trick! Thanks! I'm wondering, though, why this used to work under XF86 3.3.x with Utah-GLX. Is the 4.x driver just not as optimized for low-memory video cards? I'm probably going to buy a Radeon 8500 when the drivers are ready, but in the meantime I'd rather not run X at low resolutions if I can help it... > Would the AGP texturing patch for the Matrox cards that was floating > around the list a few weeks ago help here? > I totally missed this patch, but I'll see if I can dig it up on the mailing list archives. Thanks again, Nathan |
From: Nicolas A. <Nic...@ep...> - 2001-12-12 13:12:00
|
Alexander Stohr wrote: > > possibly i am thinking a bit more practical: - the number of pages > should never go negative, so why do we need the sign? - there is no > reason why the number of pages should get limited to i.e. 2 GB > instead of 4 GB on 32 bit machines. I think Phil *meant* 'unsigned int' instead of 'int' :-) > - you are right in trying to distinguish number_of_bytes and number_of_elements > > by meance of different type defines for them. - i am not aware of a > better type define - you might want to suggest a new one. > > Suggestion: typedef unsigned int elcount_t; or #define elcount_t > unsigned int > > But to proove you the opposite: void *calloc(size_t nmemb, size_t > size); nmemb => number_of_elements size => number_of_bytes (per > element of course) > > so the usage is already a bit puzzled for other central areas. don't > blame the agpgart programmers for introducing this... > > Yep, that's true... So using 'size_t' for element count seems to be a rather common thing (though 'calloc' is the only example I found so far ;-). The alternative of using another #define might make the code more readable, but we may also stick to the existing version and just add a few comments, s.t. people using it are not puzzled by the signification of the value. BTW, is 'size_t' an 'unsigned int' on every 32-bit platform ? and on the 64-bit ones ? Anyone knows about that ? a+ -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) |
From: Philip B. <ph...@bo...> - 2001-12-12 18:20:48
|
On Wed, Dec 12, 2001 at 01:36:10PM +0100, Alexander Stohr wrote: > - the number of pages should never go negative, so why do we need the sign? > - there is no reason why the number of pages should get limited to i.e. > 2 GB instead of 4 GB on 32 bit machines. But we're talking page count, not byte count. So signed vs unsigned is something like having 8 vs 16 TERRABYTES addressable. Personally, I dont think that should be an issue :-) So allowing signed int for pagecounts, means you can allow -1 as a flag for "uninitialized" or something. Maybe not passing back to the user. But in internal routines that calculate pagecounts, etc. |
From: Gareth H. <gar...@ac...> - 2001-12-12 19:26:32
|
On Wed, Dec 12, 2001 at 01:36:10PM +0100, Alexander Stohr wrote: > > Suggestion: > typedef unsigned int elcount_t; > or > #define elcount_t unsigned int Ack. Don't do that. -- Gareth |