[Bug 1155] libGL build failure: IEEE_ONE undefined on hppa/mips linux

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   

https://freedesktop.org/bugzilla/show_bug.cgi?id=1155        

kem <at> freedesktop.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kem <at> freedesktop.org,
                   |                            |spyderous <at> gentoo.org

------- Additional Comments From kem <at> freedesktop.org  2004-08-31 17:47 -------
(In reply to comment #4)
> This needs to happen for ARM too. I'm unsure whether __arm32__ or __arm__ is
> more correct.

If we are to include this in the X.Org release, we will need to know ASAP which
one is correct.

   

--         
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email       

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop

[Bug 1155] libGL build failure: IEEE_ONE undefined on hppa/mips linux

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   

https://freedesktop.org/bugzilla/show_bug.cgi?id=1155        

------- Additional Comments From spyderous <at> gentoo.org  2004-08-31 18:21 -------
All I can say is that we know this is required for arm32, and we're not sure
about anything else (e.g., arm in general) because nobody using arm64 has
brought up the issue. I don't know of anyone with arm64 to ask about it, either.
The safe way would probably be to do the thing we know is correct (__arm32__)
rather than the thing that may or may not work for everyone (__arm__).        

   
--         
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email       

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

[Bug 1155] libGL build failure: IEEE_ONE undefined on hppa/mips linux

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   

https://freedesktop.org/bugzilla/show_bug.cgi?id=1155        

------- Additional Comments From ajax <at> nwnk.net  2004-08-31 18:29 -------
i say (__arm__) is correct; i can't imagine arm32 would use IEEE floating point
and arm64 would not.  all five arm64 users are welcome to give me a beatdown if
that turns out not to be the case.        

   
--         
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email       

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

[Bug 1155] libGL build failure: IEEE_ONE undefined on hppa/mips linux

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   

https://freedesktop.org/bugzilla/show_bug.cgi?id=1155        

------- Additional Comments From brian.paul <at> tungstengraphics.com  2004-08-31 21:40 -------
Fixed in Mesa CVS (Added test for __arm__ to mesa/src/main/imports.h).

   

--         
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email       

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

[Bug 1155] libGL build failure: IEEE_ONE undefined on hppa/mips linux

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   

https://freedesktop.org/bugzilla/show_bug.cgi?id=1155        

kem <at> freedesktop.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From kem <at> freedesktop.org  2004-09-01 12:29 -------
Added __arm__ from Mesa CVS.
Closing.

   

--         
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email       

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: enabling APPLE_client_storage for a driver,

>
> On the other hand, if your client-side storage isn't accessible to the  GPU,
> the texture data will have to be copied into AGP or on-board VRAM.  So, the
> net effect is that the client-side texture data is going to reside in your own
> malloc'd buffer, instead of one that OpenGL/Mesa would have otherwise
> allocated.  At least you'd save a memcpy() when glTexImage2D is called.
>
> Is that all you want?

that'd do for a start... I just to need to remove any extras copies from
my system if I can ...

> Finally, there's issues of the texture image format/type/layout.  If your
> client-side storage doesn't match the hardware it'll have to be
> copied/reformatted at some point.

I see the checks in the r200 code alright, but they don't seem to cover
all the cases, it only seems to look at GL_BGRA && type ==
GL_UNSIGNED_INT_8_8_8_8_REV and format == GL_RGB && type ==
GL_UNSIGNED_SHORT_5_6_5

should all formats the hardware support be here?

Dave.

--

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

solo on my radeon

Solo on my Radeon M7 seems broken at the moment, the sample_server starts
up and runs all looks good, I can run miniglxtest and it looks okay but
anything with textures looks foobar, like manytex..

any ideas .. I can probably track it down myself but I'm not sure if I
have the time, it was a quick experiment to see if a newer Mesa tree was
worth using for something..

Dave.

--

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: enabling APPLE_client_storage for a driver,

Dave Airlie wrote:
>>On the other hand, if your client-side storage isn't accessible to the  GPU,
>>the texture data will have to be copied into AGP or on-board VRAM.  So, the
>>net effect is that the client-side texture data is going to reside in your own
>>malloc'd buffer, instead of one that OpenGL/Mesa would have otherwise
>>allocated.  At least you'd save a memcpy() when glTexImage2D is called.
>>
>>Is that all you want?
> 
> 
> that'd do for a start... I just to need to remove any extras copies from
> my system if I can ...
> 
> 
>>Finally, there's issues of the texture image format/type/layout.  If your
>>client-side storage doesn't match the hardware it'll have to be
>>copied/reformatted at some point.
> 
> 
> I see the checks in the r200 code alright, but they don't seem to cover
> all the cases, it only seems to look at GL_BGRA && type ==
> GL_UNSIGNED_INT_8_8_8_8_REV and format == GL_RGB && type ==
> GL_UNSIGNED_SHORT_5_6_5
> 
> should all formats the hardware support be here?

Probably.  I think Keith just chose to check for the formats/types 
that were the most obvious/useful at the time.

-Brian

tdfx driver extensions (was Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk))

Daniel Borca wrote:

> CVSROOT:	/cvs/mesa
> Module name:	Mesa
> Repository:	Mesa/src/mesa/drivers/dri/tdfx/
> Changes by:	dborca <at> gabe.	04/08/30 01:44:32
> 
> Log message:
>   cleaned up extensions a bit
> 
> Modified files:
>       Mesa/src/mesa/drivers/dri/tdfx/:
>         tdfx_context.c 
>   
>   Revision      Changes    Path
>   1.11          +2 -3      Mesa/src/mesa/drivers/dri/tdfx/tdfx_context.c

Here's a patch that modifies the tdfx driver to use the same 
driInitExtensions helper function that the other drivers use.  I didn't 
apply it because I don't have any tdfx hardware.  It does compile, 
anyway. :)

I have a few questions about extensions in the tdfx driver.

1. Why isn't SGIS_generate_mipmap enabled on Napalm hardware?

2. Why isn't ARB_texture_compression enabled on all hardware?  I see 
that was recently changed.

3. Why isn't EXT_stencil_wrap always enabled?  If there's no hardware 

Re: tdfx driver extensions (was Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk))

Ian Romanick wrote:

> Here's a patch that modifies the tdfx driver to use the same 
> driInitExtensions helper function that the other drivers use.  I didn't 
> apply it because I don't have any tdfx hardware.  It does compile, 
> anyway. :)

Man...I gotta quit doing that.  Here's the patch for real.

Index: src/mesa/drivers/dri/tdfx/tdfx_context.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/tdfx/tdfx_context.c,v
retrieving revision 1.11
diff -u -d -r1.11 tdfx_context.c
--- src/mesa/drivers/dri/tdfx/tdfx_context.c	30 Aug 2004 08:44:32 -0000	1.11
+++ src/mesa/drivers/dri/tdfx/tdfx_context.c	3 Sep 2004 18:23:29 -0000
 <at>  <at>  -59,9 +59,41  <at>  <at> 

 #include "drivers/common/driverfuncs.h"

+#include "utils.h"
+
 const char __driConfigOptions[] = { 0 };
 const GLuint __driNConfigOptions = 0;

+/**
+ * Common extension strings exported by all cards
+ */