XGI Volario
Is someone working on writing a driver for these chips? XGI provides a free framebuffer driver and drm, but the Mesa part of their driver is only available as closed-source. Philipp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
On Sat, Feb 19, 2005 at 04:11:08PM -0500, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Also, to cover the obvious, you did update the DRM driver, recompile it and reloaded it ? Check that there are no stray binaries around.. Yeah, the DRM was updated as well. I've compared md5sums on the drm.ko and radeon.ko modules in /lib/modules/2.6.10/kernel/drivers/char/drm to the ones in the drm directory of r300_driver tree that I just built from this morning. Exact match. Even after doing a make clean in the drm source directory and rebuilding it just now, they match. I'm not sure what stray binaries would cause this.. However, libGL.so is definitely loading /usr/X11R6/lib/modules/dri/r300_dri.so, and I build and installed that this morning (and have since updated it this afternoon). First post on this topic, sorry if it's messy. I have an amd64 portable (Mitac 8355) with a RV350 (Mobility Radeon 9600 M10). I just updated the drivers yesterday, and tried enabling VB mode by altering that #if 1. The system did a hard lockup pretty much immediately on running glxgears; at least one frame was drawn, then not even network logins worked. The update also brought another curious change. Back in immediate mode, there now seems to be some sort of waiting going on that shouldn't be. GL apps tend to freeze their display unless there are events for the X server to deal with, such as touchpad input. dmesg is full of this: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit glxgears tends to resume for short bursts occasionally, but neverputt does not. I tried rolling back the Mesa and Xorg drivers separately, but it appears to me like this is caused by a DRM change. crack-attack does not suffer from this problem. glxgears reports normal framerates (90 fps on 1400x1050, window size 1398x1030) despite few visual updates occurring. Tips on how to proceed isolating this would be very welcome. The previous update, if I am not mistaken, was from about four or five days ago. -- PGP fingerprint = 9242 DC15 2502 FEAB E15F 84C6 D538 EC09 5380 5746 signature.asc Description: Digital signature
Re: [R300 and other radeons] MergedFB lockups
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote:
Well my rv250 lockups occour only during mouse movement in fullscreen
applications. But for month ago there were no lockups. The situation
was slowly getting worse since. With current DRM and Mesa driver I
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the above are about 5 days old, doesn't have
Vladimir latest fixes), I get very jerky display with g117 and broken
textures, ultimately it locks up after moving the mouse a little bit (at
the meny screen).
I can kill X tho, that works, so the chip/bus isn't totally dead (or it
recovers with an engine reset).
Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts
Please wait {or something like that} up, then hangs) for me on my
rv280 (Radeon 9200SE).
This is with the nixnuts Debian dri packages, so dri CVS from
2005-02-08 or so.
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote:
Well my rv250 lockups occour only during mouse movement in fullscreen
applications. But for month ago there were no lockups. The situation
was slowly getting worse since. With current DRM and Mesa driver I
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the above are about 5 days old, doesn't have
Vladimir latest fixes), I get very jerky display with g117 and broken
textures, ultimately it locks up after moving the mouse a little bit (at
the meny screen).
I can kill X tho, that works, so the chip/bus isn't totally dead (or it
recovers with an engine reset).
Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts
Please wait {or something like that} up, then hangs) for me on my
rv280 (Radeon 9200SE).
This is with the nixnuts Debian dri packages, so dri CVS from
2005-02-08 or so.
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Mesa texture format REV
Vladimir Dergachev wrote: The reason I am asking is that R300 appears to support all (or almost all) GL texture formats and it would not be too difficult to add this support, but we are using R200 switch() due to lack of understanding of Mesa-driver interface. Well, even if the hardware does support all the present Mesa texture formats doesn't mean you _have_ to use them all. The end user isn't really going to care. Is there no penalty for format conversion ? Sure there is, but it varies. If the user specifies his texture images as GL_RGB/GL_FLOAT and the hardware texture format chosen is _mesa_texformat_argb155, clearly, there's going to be a cost to doing the conversion. In some cases, however, the conversion can be done with memcpy(). For example, if the incoming image is GL_UNSIGNED_INT_8_8_8_8/GL_RGBA and the chosen hardware format is _mesa_texformat_rgba, the memcpy_texture() texture routine will be used. See texstore.c. Mesa's texture conversion functions also handle all the GL_UNPACK_* parameters, color table lookup, scale and biasing, convolutions, etc. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
Dave Airlie wrote: Hi, Well I spent the day hacking and managed to get Xgl running on top of Mesa solo, the solo stuff I've checked into Mesa, Neat! The glitz backend for miniglx and the Xserver miniglx stuff are up at http://www.skynet.ie/~airlied/patches/xminiglx/ There is no input hooked up to it yet.. a Linux /dev/input hook mightn't be that hard to do, I wonder though whether trying to work with the kdrive stuff that is already there might be a better option, I see keithp committed some event device stuff recently. I'm not sure when I'll get a chance to do anything else on it... I'm sure the miniglx backend could be cleaned up a bit.. (i.e. I hacked a lot of it out as miniglx doesn't support it ..) In your other message, you wrote: building an Xserver on top of mesa solo is a bit of a nightmare in terms of includes and defines .. as an Xserver requires all the X types to build but solo has its own set of defines/typedefs that don't match what the Xserver has... so calling XCreateWindow is a bit painful for example... glitz-glx also includes X headers... (not sure if it really needs them as glx.h should pull in any necessary headers... I've mentioned this before: my thinking is that for the long term, mini GLX could/should be replaced by a different API, such as EGL (from OpenGL-ES) plus a few extensions. Mini GLX is a hack. It filled a specific need when it was created but I'm not sure it's an appropriate base for large projects. An enhanced EGL interface could be a nice clean foundation. Xgl could layer upon it and other people could use it as-is for projects where X isn't wanted. Hopefully, other IHVs would adopt/implement it too. What do you think of something like that, Dave? -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Sun, 20 Feb 2005 09:29:36 -0700, Brian Paul [EMAIL PROTECTED] wrote: An enhanced EGL interface could be a nice clean foundation. Xgl could layer upon it and other people could use it as-is for projects where X isn't wanted. Hopefully, other IHVs would adopt/implement it too. This was brought up at the xdev conference last week. Everyone is in favor of it. I will help as soon as I can get fbdev fixed for the things mesa-solo needs. Also there was significant interest from mobile phone people at the conference in XGL. There are commercial 100K OpenGL stacks targeted for phones. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: XGI Volario
On Sun, 20 Feb 2005 11:39:24 +0100, Philipp Klaus Krause [EMAIL PROTECTED] wrote: Is someone working on writing a driver for these chips? XGI provides a free framebuffer driver and drm, but the Mesa part of their driver is only available as closed-source. Philipp http://bugs.xfree86.org/show_bug.cgi?id=1550 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Sunday 20 February 2005 11:29, Brian Paul wrote: Dave Airlie wrote: building an Xserver on top of mesa solo is a bit of a nightmare in terms of includes and defines .. as an Xserver requires all the X types to build but solo has its own set of defines/typedefs that don't match what the Xserver has... so calling XCreateWindow is a bit painful for example... glitz-glx also includes X headers... (not sure if it really needs them as glx.h should pull in any necessary headers... I've mentioned this before: my thinking is that for the long term, mini GLX could/should be replaced by a different API, such as EGL (from OpenGL-ES) plus a few extensions. Mini GLX is a hack. It filled a specific need when it was created but I'm not sure it's an appropriate base for large projects. An enhanced EGL interface could be a nice clean foundation. Xgl could layer upon it and other people could use it as-is for projects where X isn't wanted. Hopefully, other IHVs would adopt/implement it too. I'm working on this, actually. Right now I'm doing it as an EGL-GLX translation layer so we can get glitz retargeted at the EGL API. Turning that into a dispatch layer wouldn't be too tough, particularly since a good bit of the engine is already written in miniglx. I've nearly got it to the point of being able to run eglinfo, but it seems to have uncovered a bug or two in the fbconfig handling. My only complaint with EGL is that a lot of the 1.1 version is, on big systems, a lot of work for not a lot of gain (OES_byte_coordinates for example). - ajax pgph3Sp6rr6S9.pgp Description: PGP signature
Re: Solo Xgl..
Adam Jackson wrote: On Sunday 20 February 2005 11:29, Brian Paul wrote: Dave Airlie wrote: building an Xserver on top of mesa solo is a bit of a nightmare in terms of includes and defines .. as an Xserver requires all the X types to build but solo has its own set of defines/typedefs that don't match what the Xserver has... so calling XCreateWindow is a bit painful for example... glitz-glx also includes X headers... (not sure if it really needs them as glx.h should pull in any necessary headers... I've mentioned this before: my thinking is that for the long term, mini GLX could/should be replaced by a different API, such as EGL (from OpenGL-ES) plus a few extensions. Mini GLX is a hack. It filled a specific need when it was created but I'm not sure it's an appropriate base for large projects. An enhanced EGL interface could be a nice clean foundation. Xgl could layer upon it and other people could use it as-is for projects where X isn't wanted. Hopefully, other IHVs would adopt/implement it too. I'm working on this, actually. Right now I'm doing it as an EGL-GLX translation layer so we can get glitz retargeted at the EGL API. Turning that into a dispatch layer wouldn't be too tough, particularly since a good bit of the engine is already written in miniglx. I've nearly got it to the point of being able to run eglinfo, but it seems to have uncovered a bug or two in the fbconfig handling. I actually started writing some EGL interface code a few months ago, but haven't touched it since. Give me a day or two to clean it up. Then let's exchange code and see what we've got. My only complaint with EGL is that a lot of the 1.1 version is, on big systems, a lot of work for not a lot of gain (OES_byte_coordinates for example). Well, GL_OES_byte_coordinate is an (optional) extension. I'm not sure we need to be concerned with it for now. Just to be clear, I was thinking of using the EGL API with full Mesa/OpenGL, not the ES subset. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2578] [radeon] Rendering glitches in unreal tournament 2003
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://bugs.freedesktop.org/show_bug.cgi?id=2578 --- Additional Comments From [EMAIL PROTECTED] 2005-02-20 10:52 --- Created an attachment (id=1948) -- (https://bugs.freedesktop.org/attachment.cgi?id=1948action=view) a picture of the purple shadows. it seems that in this level the place that the purple shadows appear is always underneeth spinning fans (that cast dynamic shadows). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Sunday 20 February 2005 13:20, Brian Paul wrote: Adam Jackson wrote: I'm working on this, actually. Right now I'm doing it as an EGL-GLX translation layer so we can get glitz retargeted at the EGL API. Turning that into a dispatch layer wouldn't be too tough, particularly since a good bit of the engine is already written in miniglx. I've nearly got it to the point of being able to run eglinfo, but it seems to have uncovered a bug or two in the fbconfig handling. I actually started writing some EGL interface code a few months ago, but haven't touched it since. Give me a day or two to clean it up. Then let's exchange code and see what we've got. Sounds good. My only complaint with EGL is that a lot of the 1.1 version is, on big systems, a lot of work for not a lot of gain (OES_byte_coordinates for example). Well, GL_OES_byte_coordinate is an (optional) extension. I'm not sure we need to be concerned with it for now. Optional if you're only doing 1.0. From the webpage, describing the changes between 1.0 and 1.1 (cleaned up slightly): New Core Additions and Profile Extensions: for the Common and Common-Lite profiles add subsets of the OES_byte_coordinates, OES_fixed_point, OES_single_precision and OES_matrix_get ES-specific extensions as core additions; OES_read_format, OES_compressed_paletted_texture, OES_point_size_array and OES_point_sprite as required profile extensions; and OES_matrix_palette and OES_draw_texture as optional profile extensions. Perversely, of these OES_draw_texture would be most useful for Xgl. Just to be clear, I was thinking of using the EGL API with full Mesa/OpenGL, not the ES subset. Right, same here. I'm more concerned about the API than the embedded feature set; but it would be nice to have GLES apps Just Work against Mesa. - ajax pgpokghyGUwOB.pgp Description: PGP signature
Re: [Unichrome-devel] .drirc?!
Felix Kühling wrote: Should I rephrase the message to clearly state that this is *not an error* or just not print anything if the file can't be read? Preferably rephrase, something like (this is just a note), as it is good to know that it is looking for the file. Benno --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] .drirc?!
Hi! Benno Schulenberg wrote: Felix Khling wrote: Should I rephrase the message to clearly state that this is *not an error* or just not print anything if the file can't be read? Preferably rephrase, something like "(this is just a note)", as it is good to know that it is looking for the file. Benno I only get this message when LIBGL_DEBUG is set to verbose, but maybe it should be just a warning? /Thomas
Re: [Unichrome-devel] .drirc?!
Thomas Hellström wrote: Benno Schulenberg wrote: Preferably rephrase, something like (this is just a note), as it is good to know that it is looking for the file. I only get this message when LIBGL_DEBUG is set to verbose, but maybe it should be just a warning? Not even a warning, preferably just a message. Best would probably be to remove the 'fprintf(stderr, libGL error: \n);' line from the __driUtilMessage function in Mesa/src/mesa/drivers/dri/common/dri_util.c, as the messages themselves should be clear enough. Benno --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
In your other message, you wrote: building an Xserver on top of mesa solo is a bit of a nightmare in terms of includes and defines .. as an Xserver requires all the X types to build but solo has its own set of defines/typedefs that don't match what the Xserver has... so calling XCreateWindow is a bit painful for example... glitz-glx also includes X headers... (not sure if it really needs them as glx.h should pull in any necessary headers... I've mentioned this before: my thinking is that for the long term, mini GLX could/should be replaced by a different API, such as EGL (from OpenGL-ES) plus a few extensions. Yeah I totally agree.. MiniGLX should die.. I was just curious to see what would be needed to get it working, I believe EGL + one or two extensions from us would be a much better platform to build on .. Mini GLX is a hack. It filled a specific need when it was created but I'm not sure it's an appropriate base for large projects. And it gets more hacked everytime I add another piece of the full GLX to it to do something, ... when Adam is thinks he has something worth looking at I'd gladly move everything to using it ... It's also a bad hack that the current miniglx sample_server has to be run then the X server, current miniglx I don't think supports rendering in its server application.. Dave. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Mon, 21 Feb 2005 10:00:04 +1100, Dave Airlie [EMAIL PROTECTED] wrote: It's also a bad hack that the current miniglx sample_server has to be run then the X server, current miniglx I don't think supports rendering in its server application.. It doesn't support it and that's another reason to kill it. Next thing you are going to run into is lack of FBO (ie render-to-texture, frame buffer object, superbuffers). Hint, hint Ian. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2578] [radeon] Rendering glitches in unreal tournament 2003
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://bugs.freedesktop.org/show_bug.cgi?id=2578 --- Additional Comments From [EMAIL PROTECTED] 2005-02-20 15:43 --- This is a problem with projected textures. It was fixed in Mesa cvs some months ago, but these (quite substantial) changes are not in xorg 6.8.2. New driver snapshots should work ok though. About the pointer shadow, I wondered about that too some time ago and came to the conclusion it's actually not a bug. IIRC it looked the same with software mesa and other drivers. I may be remembering that wrong however. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
cant compile Mesa DRI: `X_GLXCreateNewContext' undeclared (first use in this function)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I installed sucessfully xorg from CVS, DRM from CVS on Debian SID. I downloaded Mesa from CVS; make linux-x86 works fine; the problem is about dri: $ make linux-dri-x86 make[3]: Entering directory `/home/src/mesa_cvs/Mesa/src/glx/x11' gcc -c -I. -I../../../include -I../../../include/GL/internal - -I../../../src/mesa -I../../../src/mesa/main -I../../../src/mesa/glapi - -I../../../s rc/mesa/math -I../../../src/mesa/transform -I../../../src/mesa/swrast - -I../../../src/mesa/swrast_setup -I../../../src/mesa/drivers/dri/common -I ../../../../drm/libdrm -I../../../../drm/shared -I/usr/X11R6/include - -I/usr/X11R6/include/X11/extensions -Wall -O -g -DUSE_X86_ASM -DUSE_MMX_ASM ~ -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE - -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_ NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 - -DGLX_DIRECT_RENDERING -DGLXEXT -DXF86DRI -DGLX_USE_DLOPEN -DGLX_USE_MESA - -DXF86VIDMODE ~ -D_REENTRANT -UDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE - -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE - -DDRI_NEW_INTERFACE_ ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DGLX_DIRECT_RENDERING -DGLXEXT - -DXF86DRI -DGLX_USE_DLOPEN -DGLX_USE_MESA -DXF86VIDMODE -D_REENTRANT - -UDRI_NEW_INTERFACE_ONLY glxcmds.c -o glxcmds.o In file included from glxclient.h:59, ~ from glxcmds.c:43: /usr/X11R6/include/GL/glxproto.h:77:1: warning: GLX_VENDOR redefined In file included from glxclient.h:50, ~ from glxcmds.c:43: ../../../include/GL/glx.h:104:1: warning: this is the location of the previous definition In file included from glxclient.h:59, ~ from glxcmds.c:43: /usr/X11R6/include/GL/glxproto.h:78:1: warning: GLX_VERSION redefined In file included from glxclient.h:50, ~ from glxcmds.c:43: ../../../include/GL/glx.h:105:1: warning: this is the location of the previous definition In file included from glxclient.h:59, ~ from glxcmds.c:43: /usr/X11R6/include/GL/glxproto.h:79:1: warning: GLX_EXTENSIONS redefined In file included from glxclient.h:50, ~ from glxcmds.c:43: ../../../include/GL/glx.h:106:1: warning: this is the location of the previous definition glxcmds.c: In function `CreateContext': glxcmds.c:507: error: `X_GLXCreateNewContext' undeclared (first use in this function) glxcmds.c:507: error: (Each undeclared identifier is reported only once glxcmds.c:507: error: for each function it appears in.) glxcmds.c:519: error: `xGLXCreateContextWithConfigSGIXReq' undeclared (first use in this function) glxcmds.c:519: error: `req' undeclared (first use in this function) glxcmds.c:522: error: `sz_xGLXCreateContextWithConfigSGIXReq' undeclared (first use in this function) glxcmds.c:524: error: parse error before ')' token glxcmds.c:527: error: `X_GLXvop_CreateContextWithConfigSGIX' undeclared (first use in this function) glxcmds.c: In function `__glXQueryContextInfo': glxcmds.c:1526: error: `X_GLXQueryContext' undeclared (first use in this function) glxcmds.c: In function `glXSwapIntervalSGI': glxcmds.c:1836: error: `X_GLXvop_SwapIntervalSGI' undeclared (first use in this function) glxcmds.c: In function `glXCreateGLXPixmapWithConfigSGIX': glxcmds.c:2139: error: `xGLXCreateGLXPixmapWithConfigSGIXReq' undeclared (first use in this function) glxcmds.c:2139: error: `req' undeclared (first use in this function) glxcmds.c:2160: error: `sz_xGLXCreateGLXPixmapWithConfigSGIXReq' undeclared (first use in this function) glxcmds.c:2162: error: parse error before ')' token glxcmds.c:2165: error: `X_GLXvop_CreateGLXPixmapWithConfigSGIX' undeclared (first use in this function) make[3]: *** [glxcmds.o] Error 1 make[3]: Leaving directory `/home/src/mesa_cvs/Mesa/src/glx/x11' Am I missing some system lib ? some -dev libs ? my card is :01:00.0 VGA compatible controller: S3 Inc. VT8636A [ProSavage KN133] AGP4X VGA Controller (TwisterK) (rev 01), but I dont think mesa/make is able to deal with that. my error looks a generic build error. I found one reference to that bug in google, but impossible to grab the answer. my base document is http://dri.freedesktop.org/wiki/Building [EMAIL PROTECTED]:/home/src/mesa_cvs/Mesa$ cat configs/linux-dri-x86 # -*-makefile-*- # Configuration for linux-dri: Linux DRI hardware drivers for XFree86 others include $(TOP)/configs/linux-dri CONFIG_NAME = linux-dri-x86 # Unnecessary on x86, generally. PIC_FLAGS = ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM ASM_SOURCES = $(X86_SOURCES) DRI_DIRS = dri_client i810 i915 mach64 mga r128 r200 radeon tdfx unichrome \ savage sis whats wrong ? what can I do ? - -- DEMAINE Benoît-Pierre http://www.demaine.info/ \_o apt-get remove ispell o_/ There're 10 types of people: those who can count in binary and those who can't. There are two kind of admins: those who have already done something bad as root, and those who will. -BEGIN
Re: Solo Xgl..
On Sunday 20 February 2005 13:20, Brian Paul wrote:
Adam Jackson wrote:
I'm working on this, actually. Right now I'm doing it as an EGL-GLX
translation layer so we can get glitz retargeted at the EGL API. Turning
that into a dispatch layer wouldn't be too tough, particularly since a
good bit of the engine is already written in miniglx. I've nearly got it
to the point of being able to run eglinfo, but it seems to have uncovered
a bug or two in the fbconfig handling.
I actually started writing some EGL interface code a few months ago,
but haven't touched it since. Give me a day or two to clean it up.
Then let's exchange code and see what we've got.
I pounded out most of the rest of the API compat today. This is good enough
to run eglinfo and return mostly correct answers (caveat is always slow for
some reason), and of the 25ish egl* entrypoints only around three are still
stubs.
Apply patch to a newish Mesa checkout, add egl.c to sources in
src/glx/x11/Makefile, build libGL.
- ajax
--- /dev/null 2004-05-08 19:17:35.0 -0400
+++ src/glx/x11/egl.c 2005-02-20 19:57:11.0 -0500
@@ -0,0 +1,780 @@
+/*
+ * Copyright 2005 Adam Jackson.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * ADAM JACKSON BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+ * IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * \file egl.c
+ * API compatibility with OpenGL ES.
+ *
+ * \author Adam Jackson [EMAIL PROTECTED]
+ */
+
+#include GL/egl.h
+#include GL/glx.h
+#include glheader.h
+#include glxclient.h
+
+#define DISPLAY_CHECK(d) \
+do { \
+if (!d || !d-dpy) { \
+_egl_errno = EGL_BAD_DISPLAY; \
+return EGL_FALSE; \
+} \
+} while (0)
+
+#define CONTEXT_CHECK(c) \
+do { \
+if (!c || !c-ctx) { \
+_egl_errno = EGL_BAD_CONTEXT; \
+return EGL_FALSE; \
+} \
+} while (0)
+
+#define INITED_CHECK(d) \
+do { \
+if (!d-initialized) { \
+_egl_errno = EGL_NOT_INITIALIZED; \
+return EGL_FALSE; \
+} \
+} while (0)
+
+#define SURFACE_CHECK(s) \
+do { \
+if (!s || !s-surf) { \
+_egl_errno = EGL_BAD_SURFACE; \
+return EGL_FALSE; \
+} \
+} while (0)
+
+typedef struct _egl_context
+{
+GLXContext ctx;
+XVisualInfo *visinfo;
+EGLSurface read;
+EGLSurface draw;
+EGLint config_id;
+EGLBoolean current;
+EGLBoolean doomed;
+} egl_context;
+
+typedef struct _egl_display
+{
+Display *dpy;
+EGLBoolean initialized;
+} egl_display;
+
+#define _EGL_WINDOW_SURFACE 1
+#define _EGL_PIXMAP_SURFACE 2
+#define _EGL_PBUFFER_SURFACE3
+
+typedef struct _egl_surface
+{
+EGLint type;
+GLXDrawable surf;
+EGLBoolean current;
+EGLBoolean doomed;
+} egl_surface;
+
+#ifdef GLX_USE_TLS
+#define _EGL_TLSVAR __thread
+#else
+#define _EGL_TLSVAR
+#endif
+static _EGL_TLSVAR EGLint _egl_errno = EGL_SUCCESS;
+static _EGL_TLSVAR egl_context *_egl_current_ctx = EGL_NO_CONTEXT;
+static _EGL_TLSVAR egl_display *_egl_current_dpy = EGL_NO_DISPLAY;
+
+/* internal helper functions */
+
+static int map_attrib_egl_to_glx(const EGLint in)
+{
+switch (in)
+{
+case EGL_BUFFER_SIZE:
+return GLX_BUFFER_SIZE;
+case EGL_ALPHA_SIZE:
+return GLX_ALPHA_SIZE;
+case EGL_BLUE_SIZE:
+return GLX_BLUE_SIZE;
+case EGL_GREEN_SIZE:
+return GLX_GREEN_SIZE;
+case EGL_RED_SIZE:
+return GLX_RED_SIZE;
+case EGL_DEPTH_SIZE:
+return GLX_DEPTH_SIZE;
+case EGL_STENCIL_SIZE:
+return GLX_STENCIL_SIZE;
+case EGL_CONFIG_CAVEAT:
+return GLX_CONFIG_CAVEAT;
+case EGL_CONFIG_ID:
+return GLX_FBCONFIG_ID;
+case EGL_LEVEL:
+return GLX_LEVEL;
+case EGL_MAX_PBUFFER_HEIGHT:
+return GLX_MAX_PBUFFER_HEIGHT;
+case
Re: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev wrote: [snip] Interesting :) Could you try this with latest X.org source ? Also, what is gl-117 ? OpenGL flight simulator. Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Offtopic: Quake 3
On Sunday 20 February 2005 10:34 pm, Nguyen The Toan wrote: I hope this is not too off topic. I bought the retail version of Quake 3 few years ago. But now I want to try it on Linux. Does anybody know if I need to buy a new copy for linux or if I can modify the Q3 Linux Demo somehow ? Simply download the Quake3 Linux Binary from id software, and follow the installation instructions. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 pgpVleDAL4XGd.pgp Description: PGP signature
[r300] Radeon 9600se mostly working..
So I've been lurking for a while following the r300 work and decided to give it a go on my fanless 9600se (RV350 AP). - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit Any pointers on what causes that? This is with Xorg cvs, Mesa cvs, r300 cvs, as of 4 hours ago. I'm guessing the X server or mesa isn't filling the buffer up fast enough at higher resolutions...but I'm new to devlopment so i don't know which buffer that would be.. thanks, john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
