Re: merging mach64 upstream yet again.
On Wed, 2009-02-04 at 04:42 -0800, Dave Airlie wrote: So marcheu reminded me of my laziness and I built mach64 but I took a quick look at its API and its not 32/64 compliant by any reach. So I'd like to merge it with a version 3.0.0 API which fixes all the API issues I could fine, mainly using void *, unsigned long, I nuked some unsigned shorts and some enums for perfection. And of course I forget the main mach64_drm.h This contains most of the ABI breaks. Dave. This would require moving these changes backing into libdrm git tree, then fixing userspace users to do proper casting to the uint64_ts. It would mean only newer mach64 releases would use DRI which might save any unexpected pain we might suffer. Jose, also I used myself as Author on the patch but I'm quite happy to use you instead, I just need a signed-off-by from you. Comments? Dave. Dave, I've walk through the patch and it looks good. I don't mind the Author: tag. Is the signed-off-by just a gentleman's thing, or do I need to GPG sign it, or something like that? Jose -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Please provide a way to get software rendering
You already can do it with an environment variable: LD_LIBRARY_PATH=/path/to/mesa/software/only/libGL your-app Jose On Mon, 2008-11-17 at 00:03 +0100, Philipp Klaus Krause wrote: I think it would be useful if one could choose software rendering without having to uninstall hardware drivers. Maybe a driconf option or an environment variable would be the way to go. This could be useful for trying new OpenGL features not yet supported in hardware drivers, like OpenGL 2.0. Philipp P.S.: No, LIBGL_ALWAYS_INDIRECT doesn't do this, accelerated indirect rendering has been implemented a long time ago. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Finer grained is_format_supported in gallium.
I've just pushed a interface change to gallium. A finer grained pipe_screen::is_format_supported was needed. Namely, it needed to distinguish among different pipe_texture_targets, as hardware some times has limitations in the formats that can be used for cubemaps and texturemaps. The same thing goes for non-square sizes, and non power of of two sizes. And since I need to change the interface, I used this opportunity to drop PIPE_SURFACE vs PIPE_TEXTURE outdated distinction, replacing it by the tex_usage flags (PIPE_TEXTURE_USAGE_RENDER_TARGET and/or PIPE_TEXTURE_USAGE_DISPLAY_TARGET). In summary, this is how the new is_format_supported looks like: /** * Check if the given pipe_format is supported. * * \param tex_usage bitmask of PIPE_TEXTURE_USAGE_* * \param flags a bitmask of PIPE_TEXTURE_GEOM_SQUARE and * PIPE_TEXTURE_GEOM_NONPOWEROFTWO */ boolean (*is_format_supported)( struct pipe_screen *, enum pipe_format format, enum pipe_texture_target target, unsigned tex_usage, unsigned geom_flags ); Jose - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Eliminating pipe_texture-cpp and pipe_surface-cpp in gallium
In order to properly represent the compressed textures and (yuv formats
to some extent) it is necessary to abandon the chars-per-pixels concept
in gallium, and use instead the concept of pixel blocks (in p_format.h):
/**
* Describe accurately the pixel format.
*
* The chars-per-pixel concept falls apart with compressed and yuv images, where
* more than one pixel are coded in a single data block. This structure
* describes that block.
*
* Simple pixel formats are effectively a 1x1xcpp block.
*/
struct pipe_format_block
{
/** Block size in bytes */
unsigned size;
/** Block width in pixels */
unsigned width;
/** Block height in pixels */
unsigned height;
};
/**
* Describe pixel format's block.
*
* @sa http://msdn2.microsoft.com/en-us/library/ms796147.aspx
*/
static INLINE void
pf_get_block(enum pipe_format format, struct pipe_format_block *block)
{
switch(format) {
case PIPE_FORMAT_DXT1_RGBA:
case PIPE_FORMAT_DXT1_RGB:
block-size = 8;
block-width = 4;
block-height = 4;
break;
case PIPE_FORMAT_DXT3_RGBA:
case PIPE_FORMAT_DXT5_RGBA:
block-size = 16;
block-width = 4;
block-height = 4;
break;
case PIPE_FORMAT_YCBCR:
case PIPE_FORMAT_YCBCR_REV:
block-size = 4; /* 2*cpp */
block-width = 2;
block-height = 1;
break;
default:
block-size = pf_get_size(format);
block-width = 1;
block-height = 1;
break;
}
}
static INLINE unsigned
pf_get_nblocksx(const struct pipe_format_block *block, unsigned x)
{
return (x + block-width - 1)/block-width;
}
static INLINE unsigned
pf_get_nblocksy(const struct pipe_format_block *block, unsigned y)
{
return (y + block-height - 1)/block-height;
}
Pipe texture will become:
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -303,7 +303,10 @@ struct pipe_texture
unsigned height[PIPE_MAX_TEXTURE_LEVELS];
unsigned depth[PIPE_MAX_TEXTURE_LEVELS];
- unsigned cpp:8;
+ struct pipe_format_block block;
+ unsigned nblocksx[PIPE_MAX_TEXTURE_LEVELS];
+ unsigned nblocksy[PIPE_MAX_TEXTURE_LEVELS];
+
unsigned last_level:8;/** Index of last mipmap level present/defined */
unsigned compressed:1;
Also, with chars per pixel gone, pitch is better be specified in bytes,
rather than pixels. To make sure that nothing gets forgotten I'm going
to rename all pipe_texture and pipe_surface pitch members to stride,
so that if somewhere is forgotten one gets a compiler error:
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -267,10 +267,12 @@ struct pipe_surface
enum pipe_format format; /** PIPE_FORMAT_x */
unsigned status; /** PIPE_SURFACE_STATUS_x */
unsigned clear_value; /** XXX may be temporary */
- unsigned cpp; /** bytes per pixel */
unsigned width;
unsigned height;
- unsigned pitch; /** in pixels */
+ struct pipe_format_block block;
+ unsigned nblocksx;
+ unsigned nblocksy;
+ unsigned stride; /** in bytes */
unsigned layout; /** PIPE_SURFACE_LAYOUT_x */
unsigned offset; /** offset from start of buffer, in bytes */
unsigned refcount;
Jose
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Eliminating pipe_texture-cpp and pipe_surface-cpp in gallium
On Fri, Jun 27, 2008 at 9:37 PM, Jakob Bornecrantz [EMAIL PROTECTED] wrote:
On Fri, Jun 27, 2008 at 12:57 PM, José Fonseca
[EMAIL PROTECTED] wrote:
In order to properly represent the compressed textures and (yuv formats
to some extent) it is necessary to abandon the chars-per-pixels concept
in gallium, and use instead the concept of pixel blocks (in p_format.h):
/**
* Describe accurately the pixel format.
*
* The chars-per-pixel concept falls apart with compressed and yuv images,
where
* more than one pixel are coded in a single data block. This structure
* describes that block.
*
* Simple pixel formats are effectively a 1x1xcpp block.
*/
struct pipe_format_block
{
/** Block size in bytes */
unsigned size;
/** Block width in pixels */
unsigned width;
/** Block height in pixels */
unsigned height;
};
/**
* Describe pixel format's block.
*
* @sa http://msdn2.microsoft.com/en-us/library/ms796147.aspx
*/
static INLINE void
pf_get_block(enum pipe_format format, struct pipe_format_block *block)
{
switch(format) {
case PIPE_FORMAT_DXT1_RGBA:
case PIPE_FORMAT_DXT1_RGB:
block-size = 8;
block-width = 4;
block-height = 4;
break;
case PIPE_FORMAT_DXT3_RGBA:
case PIPE_FORMAT_DXT5_RGBA:
block-size = 16;
block-width = 4;
block-height = 4;
break;
case PIPE_FORMAT_YCBCR:
case PIPE_FORMAT_YCBCR_REV:
block-size = 4; /* 2*cpp */
block-width = 2;
block-height = 1;
break;
default:
block-size = pf_get_size(format);
block-width = 1;
block-height = 1;
break;
}
}
static INLINE unsigned
pf_get_nblocksx(const struct pipe_format_block *block, unsigned x)
{
return (x + block-width - 1)/block-width;
}
static INLINE unsigned
pf_get_nblocksy(const struct pipe_format_block *block, unsigned y)
{
return (y + block-height - 1)/block-height;
}
Pipe texture will become:
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -303,7 +303,10 @@ struct pipe_texture
unsigned height[PIPE_MAX_TEXTURE_LEVELS];
unsigned depth[PIPE_MAX_TEXTURE_LEVELS];
- unsigned cpp:8;
+ struct pipe_format_block block;
+ unsigned nblocksx[PIPE_MAX_TEXTURE_LEVELS];
+ unsigned nblocksy[PIPE_MAX_TEXTURE_LEVELS];
+
unsigned last_level:8;/** Index of last mipmap level present/defined
*/
unsigned compressed:1;
Also, with chars per pixel gone, pitch is better be specified in bytes,
rather than pixels. To make sure that nothing gets forgotten I'm going
to rename all pipe_texture and pipe_surface pitch members to stride,
so that if somewhere is forgotten one gets a compiler error:
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -267,10 +267,12 @@ struct pipe_surface
enum pipe_format format; /** PIPE_FORMAT_x */
unsigned status; /** PIPE_SURFACE_STATUS_x */
unsigned clear_value; /** XXX may be temporary */
- unsigned cpp; /** bytes per pixel */
unsigned width;
unsigned height;
- unsigned pitch; /** in pixels */
+ struct pipe_format_block block;
+ unsigned nblocksx;
+ unsigned nblocksy;
+ unsigned stride; /** in bytes */
unsigned layout; /** PIPE_SURFACE_LAYOUT_x */
unsigned offset; /** offset from start of buffer, in bytes
*/
unsigned refcount;
Looks good.
I have fixed the problems in the i915simple driver and dri/intel
winsys that where remaining. So that works now.
Thanks Jakob.
Jose
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: gallium (was Re: radeon r6xx DRM...)
On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton [EMAIL PROTECTED] wrote: I think this would be a good time to speak up. My GSoC project involves writing a state tracker for XvMC, aside from the mesa state tracker I understand this is the only other public state tracker around. I don't have any complaints about the current gallium interface, but maybe someone could elaborate on what they have in mind as far as changes go, even if it's preliminary. One thing I've noticed about about winsys is that from my understanding, the state tracker is supposed to be OS and driver independent, The conclusion we're reaching is that while the bulk of the state tracker is OS independent (like current mesa state tracker is), there is a small part which will have some OS dependency (the part that will talk to DRI, GLX, WGL, etc.) but for XvMC and VAAPI the following situation exists: both are passed the drawable that will get rendered to late (after creation), and that forces me to pass the drawable to the winsys throught the state tracker as winsys-flush_frontbuffer(.., ..., drawable) when it seems that last param is intended for pipe_context-priv. Not sure what the intention behind the priv member is, so maybe this might be a bad idea when I target a HW driver instead of softpipe. We are also reaching the conclusion that the os-dependent part of the state tracker generally needs a special interface between the winsys. That At any rate it is impossible at the moment to guess how these changes will exactly turn out to be. So my suggestion is keep doing as you've been doing, and then this happens just make the similar move. I'm pretty sure that whatever works best for the existing state trackers should also works for your state tracker, but we can take a look at your code and ensure it does. As an aside, is there any preferred directory structure people would like to see for state trackers? Right now I'm using Nouveau's gallium but this isn't necessarily nouveau specific and may find a home elsewhere in the future. I'll be putting things in gallium/state_trackers/g3dvl (g3dvl being gallium3d video layer) with the following structure: src/ libXvMC/ tests/ libVAAPI/ tests/ vl/ tests/ winsys/ vl/ is where the state tracker stuff is, although since VAAPI and XvMC are somewhat similar (especially for mpeg2) I'm hoping to use the same state tracker. For that reason things don't look like they do in the mesa state tracker, I don't use XvMC types in the state tracker and don't necessarily map 1:1 with XvMC functions. Directory structure is not entirely consensual. But the general existing principles are: - standalone libraries (no gallium dependency) in src/ - gallium auxiliary libraries (gallium dependency) in src/gallium/auxiliary/ - in lack of better place, state trackers in src/gallium/state_trackers/ - pipe drivers in src/gallium/drivers/ - winsys in src/gallium/winsys/ So according to that above, your tree would be separated and go into - src/libXvMC/ - src/libVAAPI/ - src/gallium/state_trackers/vl - src/gallium/winsys/vl But I wouldn't worry too much about this. Especially if it would affect your productivity. We can always discuss this again if/when merging. (Another option is having state trackers out of the gallium source tree. We have done it, and it is nice because avoids merges back-n-forth, but still didn't wrote any howto instructions on this regard.) BTW, do you have your code available somewhere? Jose - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: gallium (was Re: radeon r6xx DRM...)
On Sat, Jun 7, 2008 at 12:07 AM, Younes Manton [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 6:12 AM, José Fonseca [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton [EMAIL PROTECTED] wrote: As an aside, is there any preferred directory structure people would like to see for state trackers? Right now I'm using Nouveau's gallium but this isn't necessarily nouveau specific and may find a home elsewhere in the future. I'll be putting things in gallium/state_trackers/g3dvl (g3dvl being gallium3d video layer) with the following structure: src/ libXvMC/ tests/ libVAAPI/ tests/ vl/ tests/ winsys/ vl/ is where the state tracker stuff is, although since VAAPI and XvMC are somewhat similar (especially for mpeg2) I'm hoping to use the same state tracker. For that reason things don't look like they do in the mesa state tracker, I don't use XvMC types in the state tracker and don't necessarily map 1:1 with XvMC functions. Directory structure is not entirely consensual. But the general existing principles are: - standalone libraries (no gallium dependency) in src/ - gallium auxiliary libraries (gallium dependency) in src/gallium/auxiliary/ - in lack of better place, state trackers in src/gallium/state_trackers/ - pipe drivers in src/gallium/drivers/ - winsys in src/gallium/winsys/ So according to that above, your tree would be separated and go into - src/libXvMC/ - src/libVAAPI/ - src/gallium/state_trackers/vl - src/gallium/winsys/vl Assuming I had my own repo you mean, or in mesa? I was referring to mesa. I was planning on using nouveau/mesa for the near future since Stephane is my mentor and nouveau is what I plan to move on to once things are working with softpipe, which would put libXvMC/ and libVAAPI/ alongside mesa/. Don't know how others would feel about non mesa libs at the top of the mesa tree, or if that's not a big deal. BTW, do you have your code available somewhere? Uploaded a copy to http://www.bitblit.org/gsoc/g3dvl/src/ and will soon commit current work to nouveau/mesa, http://www.bitblit.org/gsoc/g3dvl/ is where I keep general info and progress, etc. It's looking good. Looking forward to see the final outcome. Jose - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
git and CR+LF
On a cross-platform source tree there are files that: (a) should keep their unix LF line endings (e.g., shell scripts), (b) should keep their DOS CR+LF line endings (.inf files), and (c) should switch whatever the user prefers and have CR CR+LF treated indiscriminately (C/C++ source files). For (c), we need git collaboration. Commiting line end changes is a no-no, since it will create conflicts for all eternity. In git it seems that the solution for that is core.autocrlf option (http://www.kernel.org/pub/software/scm/git/docs/git-config.html ) and My understanding from the manual page is that only people who are developing on Windows should/must enable the this option by typing: git config --global core.autocrlf true and this will make git to convert *all text* files to CR+LF on *checkout*, and to LF on *commit*. This means that: - the repository generally keeps (c) files stored in LF, which means that we are already screwed in several places. - unix users don't need to set this option. After, we may need to tweak core.autocrlf behavior a bit using .gitattributes (http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html) to disable the automatic CR+LF translation for files in case (a) and (b). There is apparently a new option under development, core.safecrlf, which prevents git to mistakenly do CR+LF conversion of binary files. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium code reorganization
On 2/14/08, José Fonseca [EMAIL PROTECTED] wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker. This is finished now. 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), I'm working on this now. ATM you can easily do compile-testing of your changes on many gallium variants from a single tree by executing (e.g., from a script): scons dri=0 scons dri=1 scons llvm=1 And it can be done regardless of what config is enabled, as it won't affect the conventional Makefile build. The end result is still not usable in a few cases (due to library interdependencies issues on linking, and lack of an install target). I'm going to see if I can get cell and win32 working this way too. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium code reorganization
Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium code reorganization
I think it is almost impossible to rebase under these circumstances. BTW, there was an unforeseen problem -- aux appears to be special file on windows. Hence I had to rename that directory to auxiliary... Jose On 2/15/08, Keith Whitwell [EMAIL PROTECTED] wrote: OK, I found I had to merge rather than rebase in order to get my changes into the new organization -- apologies for the bubble in the history. Keith José Fonseca wrote: Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium code reorganization
On 2/15/08, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 1:38 AM, José Fonseca [EMAIL PROTECTED] wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree I'm not sure what the scope of the work you're proposing here is, but to get to a leaner source tree, I would definitely recommend splitting out the libraries: glu, glut, glw. egl and even glx. At some point, gallium might get its own repository and separate from mesa and the libraries you mention -- it would make all sense as Keith sees Mesa as one among many Gallium clients. But for now, I just want to reorganize the code within the same repository so that if/when that's decided, all the parts are loosely coupled to make it painless. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Gallium code reorganization
I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium code reorganization
On Thu, 2008-02-14 at 08:50 +0200, Daniel Stone wrote: On Thu, Feb 14, 2008 at 03:38:45PM +0900, José Fonseca wrote: 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), http://lwn.net/Articles/188693/ 'There were major problems building KDE on non-Linux platforms with SCons (e.g. on OS X); in general they felt it did not yet have a mature configuration system.' IOW, 'not autotools' is not a panacea for ultimate portability. You're not adding anything new. You can take 'not autotools' in the sentence above and replace it with whatever you want, and it will still hold true. I wont dispute the theoretical merits of scons vs autotools vs cmake anymore. It's beyond that point. KDE did their homework and reached their conclusions. I've been doing my homework and have reached other conclusions. (This difference will only cause you surprise if you assume KDE == Mesa, or you actually expect there is such a panacea). Now the way of proving scons works for Mesa/Gallium or not is making it happen. Everything else now is uncalled speculation. (Plus you're mentioning OS X when my concern is primarily supporting windows, where autotools is useless.) Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
TextChas on the DRI Wiki
I've just enabled TextChas on the DRI Wiki: http://dri.freedesktop.org/wiki/HelpOnTextChas http://moinmo.in/TextCha It is now necessary to answer a question when creating an user account and editing pages. The questions consist in GPU manufacturer and model names -- something than a normal user DRI can answer without looking up, and that doesn't take more than a single word. I'm going to give 1-2 weeks for people to test. Then I plan to delete the user DB to purge all spammer user accounts, and perhaps narrow TextChas to user account creation only. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Weekly/nightly Doxygen HTML documentation
Hi,
I've restarted the periodic generation of doxygen HTML documentation
from the Mesa's git repository:
- Mesa (master branch) documentation is being generated weekly into
http://dri.freedesktop.org/doxygen/mesa/
- Gallium (gallium-0.1 branch) documentation is being generated
nightly into http://dri.freedesktop.org/doxygen/gallium/
The old http://people.freedesktop.org/~jrfonseca/gallium link is just
a symlink to the later.
In Gallium source code, doxygen tags are not being used
systematically, and often there is no documentation other than the
code itself. On the other hand the Gallium code generally reads quite
well by itself, and I've configured doxygen in such way that the HTML
output is a nice source code browser. I've also enhanced the welcome
page with better starting points.
For reference, the scripts used to generate this live in
annarchy.freedesktop.org:/home/jrfonseca/scripts/doxygen-{mesa,gallium}.cron.
José
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Mach64 DRI status
On Sun, 02 Dec 2007 20:59:16 +, José Fonseca wrote: On Fri, 23 Nov 2007 00:27:37 +0100, Pascal Vincent wrote: Hello, can you please indicate the current ATI mach64 DRI status. In fact, http://dri.freedesktop.org/wiki/ATIMach64 page is not so clear so i don't have the clear responses to - is mach64 is now secure ? this means : - is it now included in DRI and Mesa ? (the response seems to be yes) - is mach64 module is now included in kernel ? (it seems not) and if not why ? Tks a lot for clarification Pascal Pascal, I wrote that wiki page several years ago. I never got around to do it, because it involved a non trivial amount of work, and I approached in a naive way (trying to do too many things at the same time, instead of doing gradual changes). I need to reevaluate those statements, especially, concerning the security, and the best way to do it. The mach64 driver has three parts: one in Xorg, another in Mesa, another in the kernel. The unsafe part is the kernel part. And that's probably why is not included in the stock kernel. The reason the mach64 kernel module is unsafe is because it allows an OpenGL application to send malicious commands interspersed with the vertex data. Those malicious commands could give control over the physical memory, and therefore be used to obtain root privileges in theory. The mach64 kernel needs to be changed to verify and copy the data to private memory. Or at least unmap the memory from the client before verifying it and handing to the hardware. Or so I though... I need to verify how much control over the physical memory the client can actually get. As I'm unsure if it is just the memory in the AGP aperture, or the whole memory. If it is just the AGP memory, then there is no risk. José The work to get Mach64 secure was already done by George ( https://bugs.freedesktop.org/show_bug.cgi?id=6242 ). Dave Airlie had concerns with the blits, but I reviewed the code with him I found it to be secure (basically we don't let the client touch dma buffers -- it's not the most efficient way for blits, but is is simple as it doesn't imply maintaining two sets of buffers, one private another public). Now I've cleaned up the code a bit (especially eliminating some macros) and commented more, to make it easier to understand and maintain. Hopefully it will be merged soon. José - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Mach64 DRI status
On Fri, 23 Nov 2007 00:27:37 +0100, Pascal Vincent wrote: Hello, can you please indicate the current ATI mach64 DRI status. In fact, http://dri.freedesktop.org/wiki/ATIMach64 page is not so clear so i don't have the clear responses to - is mach64 is now secure ? this means : - is it now included in DRI and Mesa ? (the response seems to be yes) - is mach64 module is now included in kernel ? (it seems not) and if not why ? Tks a lot for clarification Pascal Pascal, I wrote that wiki page several years ago. I never got around to do it, because it involved a non trivial amount of work, and I approached in a naive way (trying to do too many things at the same time, instead of doing gradual changes). I need to reevaluate those statements, especially, concerning the security, and the best way to do it. The mach64 driver has three parts: one in Xorg, another in Mesa, another in the kernel. The unsafe part is the kernel part. And that's probably why is not included in the stock kernel. The reason the mach64 kernel module is unsafe is because it allows an OpenGL application to send malicious commands interspersed with the vertex data. Those malicious commands could give control over the physical memory, and therefore be used to obtain root privileges in theory. The mach64 kernel needs to be changed to verify and copy the data to private memory. Or at least unmap the memory from the client before verifying it and handing to the hardware. Or so I though... I need to verify how much control over the physical memory the client can actually get. As I'm unsure if it is just the memory in the AGP aperture, or the whole memory. If it is just the AGP memory, then there is no risk. José - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Using Eclipse for Xorg/DRI development
I've never learned to use Emacs. I love vim, but it doesn't scale for me when editing more than three files at the same time or projects with more than one directory. After two years using Eclipse for Python and Windows C++ development, I've been using almost exclusively Eclipse for Xorg/Mesa/DRI development during the last three months. I think Eclipse is really a pleasant development environment: - it has a good code navigator, which is also fast (they used Mozilla's source tree as a benchmark) - excellent support for remote debugging (embedded companies are major contributors to Eclipse, since almost every embedded SDK nowadays is based on it) - it rarely stands it the way (e.g., it integrates with any build system from autotools to hand written shell scripts, you still have the power of regular expression at your finger tips, etc.). Also, the CDT (the C/C++ Plugin for Eclipse) folks are now actively working to get Eclipse not only to debug remote applications, but also build remotely, which will greatly simplify testing on multiple software/hardware configurations. The thing I miss the most is git integration. Of course, it is advisable to have a big screen and lots of memory. If anybody is interested, I've wrote some instructions to get you started on http://www.x.org/wiki/Development/Documentation/UsingEclipse José - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Profiling DRI drivers
I've been spending a lot of time profiling DRI drivers for Gallium 3D. I've tried gprof, valgrind, and finally oprofile. Oprofile seems the best in my opinion for this purpose. (I haven't tried Sysprof yet though). I wrote about it in http://dri.freedesktop.org/wiki/Profiling . I also wrote a script to generate a time-colored call graph from oprofile output, using graphviz. The script available from http://code.google.com/p/jrfonseca/wiki/Gprof2Dot . See an output example of profiling glxgears on Gallium 3D on http://people.freedesktop.org/~jrfonseca/profiling/oprofile-gallium.png . The hotter the colour of a function is, more time is spent on that function and its children. José Fonseca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage and nVidia DRI drivers
On Thu, Oct 31, 2002 at 11:39:42AM +, Alan Cox wrote: On Thu, 2002-10-31 at 02:16, José Fonseca wrote: People which are interested in having these drivers see the light of day (I know that the Savage chip is common on laptops and AFAIK there no nVidia proprietary drivers for non-Linux non-x86 platforms) are surely welcome to help, as they can turn this small project of mine in something definite. Count me in as much as I can help. I can make the hardware sing but I know zilch about the Mesa end of things. I'm also interested in Voodoo2 since its for many people the best video card you can shove in old hppa boxes and in sis 6326 (because its a good simplicity test) The Voodoo 2 specs are available from http://www.medex.hu/~danthe/tdfx/ . I don't know what's the current state of the tdfx driver in respect with Voodoo 2. The tdfx driver is quite different from any other driver because it uses the Glide library and everything is done by PIO on the client side. Several times it was manifested the interest in bringing the tdfx driver up to its pairs level and cut the Glide umbilical cord but nothing was done in that sense. I don't know much about SIS 6326. I know that there is some deprecated (it hasn't been updated for the architectural changes) support for SIS 630 chips on the CVS. José Fonseca --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Copying DMA buffers in Mach64
Alan, On Wed, Oct 23, 2002 at 01:40:09AM +0100, José Fonseca wrote: On Wed, Oct 23, 2002 at 01:01:39AM +0100, Alan Cox wrote: ... I would expect to want to prefetch the input data (please trust copy_from_user to do this right, it doesn't do a good job yet but its the business of that code to do it). ... But if I call copy_from_user I won't be making the copy and verify in one pass, as advised below. Should I adapt copy_from_user to do that then? ... Ok. I've already have a simple C routine which copies and verifies the buffers. It's now reading from a DMA buffer which is mmap'd on userspace but I want it to read directly from the userspace as there is no point in wasting DMA memory on clients if no DMA operation will be made on from it. I've studied the current implementation of copy_from_user. For those interested (not you, of course! :), the relevant bits are in include/asm-i386/uaccess.h and http://kernelnewbies.org/documents/copy_user/ . But although I do understand the assembly implementation and I actually plan to do an assembly optimized version myself, I would like to start with a plain C implementation that would be platform independent. But it doesn't seem I can get away of assembly due to the exception table. So the only way is to do it portably is to call __copy_user inside my routine for every read, or do you have any other suggestion you can give me? Thanks in advance, José Fonseca --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merge
On Tue, Oct 22, 2002 at 10:34:58AM +0100, Alan Hourihane wrote: I'm about to start a merge of the XFree86 CVS and bring that into the DRI CVS trunk. No doubt with the trees diverging quite a bit, that there will undoubtably be some build bustage along the way. I'll be bringing it across in stages to try and minimize the disruption. Jose - it may be worth disabling the automated builds for a few days. Done, Alan. Only the non-trunk -- bleeding-edge mach64 and s3virge -- builds are enabled now. José Fonseca --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Copying DMA buffers in Mach64
On Tue, Oct 22, 2002 at 10:24:04PM +0100, Alan Cox wrote: [...] I can believe there are objects in 3D rendering big enough to be worth mapping but I'd be guessing to name a size. Linus as a chip hacker might actually have more detailed numbers. At least with the Mach64 is very rare for this to happen - vertex data is fairly compact and usually there is some state change which forces to flush the buffer. The only application that would be an exception is for scientific visualization, where large and dense meshes can be processed without any state change. Is it neccessary to copy all the data then DMA it or can you pipeline it so that the DMA is writing out some of the cache while you copy data in and verify it ? I'm not sure what you mean with cache above, but the Mach64 has a ring buffer with all the pending DMA buffers, so there will be DMA transfer simultaneously with the copy/verify, but with unrelated DMA buffers. I hope this has answered your questions. I'm still not sure what should be the best approach here in detail after reading this thread. There seems to be a consensus regarding verifying on the source and not on the destination, but not whether verify and copy should be done at the same time or in distint steps, which relates to benefit of prefetching and/or uncached-writes (which isn't even clear if are actually a benefit or not). José Fonseca --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Copying DMA buffers in Mach64
On Wed, Oct 23, 2002 at 01:01:39AM +0100, Alan Cox wrote: On Wed, 2002-10-23 at 00:19, José Fonseca wrote: [...] I'm not sure what you mean with cache above, but the Mach64 has a ring buffer with all the pending DMA buffers, so there will be DMA transfer simultaneously with the copy/verify, but with unrelated DMA buffers. Is your very large mesh a single DMA buffer or multiple buffers. Surely multiple buffers - the DRM has a pool of 16k buffers. But what actually happens with usual applications (i.e., games), is that the application only fills less than 4k. So we could even just use a pool of 4k buffers to be shure that the buffer could fit on L1 cache on most machines (or have it as a parameter). 4k is enough to hold roughly about 146 vertices (including color, and texture coords) on Mach64. Most objects in virtual [gaming] worlds don't have that many with the _same_ texture, and to change a texture means flush the buffer as is. Again I stress that this is regarding vertex data only - with texture data the bandwith is much higher, but fortunately there are no security concerns in that case. I hope this has answered your questions. I'm still not sure what should be the best approach here in detail after reading this thread. There seems to be a consensus regarding verifying on the source and not on the destination, but not whether verify and copy should be done at the same time or in distint steps, which relates to benefit of prefetching and/or uncached-writes (which isn't even clear if are actually a benefit or not). Prefetching tends to be a win. What to prefetch is a harder question normally solved by benchmarking. When the card does DMA access to a buffer it will suck it from the processor L2 caches. If it only reads The card only reads. you should end up with a local copy in cache. If the card writes to the buffers as it processes them it will actually evict them from the CPU cache in most cases. In the former case I would expect to want to prefetch the input data (please trust copy_from_user to do this right, it doesn't do a good job yet but its the business of that code to do it). In the latter case I could see the prefetchw of the destination DMA buffer being more of a win. But if I call copy_from_user I won't be making the copy and verify in one pass, as advised below. Should I adapt copy_from_user to do that then? The reasons for doing the copy and verify in one pass are twofold - memory access is slow so even if the data is in L2 we have clock cycles to fill while copying. For example on x86 copy and checksum is the same speed as a copy for most cases. - If your long series of commands is multiple DMA buffers you can fire off DMA buffers as you can rather than copying, then scanning. That reduces latency and also means you are less likely to have data fall out of L1 cache then be pulled back into it. Ok. So it seems to be the safest bet. Uncached writes on PC hardware are almost always a complete loss. You want the writeback caching so you are writing to the PCI bridge or sdram in the largest chunk sizes possible. Oh.. Its also entirely possible on something like a Mach64, where you don't have very many giant objects that it won't make a blind bit of difference if you prefetch, validate as you write etc. I'm aware that many of these questions will only be completely answered with some benchmarks, but since I don't have a clear understanding of some of the relavant concepts, these preliminary considerations will hopefully reduce the number of necessary iterations until the best/acceptable level of performance is achieved. Thanks. José Fonseca --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Copying DMA buffers in Mach64
On Mon, Oct 21, 2002 at 11:27:15AM -0400, Leif Delgass wrote: [...] I have a pretty good idea how to do the verification (just checking the register count and offset range of each command, skipping the data), but I'm not sure if it'll be faster to copy as we verify, or memcpy the entire buffer and verify (or verify and then copy). At any rate, it should be easy to test and see which works best. Check the log of an IRC talk I had with Willmore on today's meeting regarding this same subject. It was very insightfull. In summary, we would make most use of the cache by verifying first and then copying (and if possible avoiding write caching). The thing I hadn't figured out yet is the best way to allocate the private buffers. We could allocate a chunk of AGP mem like other drivers do for the ring buffer, which could be set read only for userspace. I'm not sure if drmAddBufs would work to create one mapped set and one unmapped set of buffers. drmAddBufs is getting deprecated, especially regarding the PCI counterpart, but I know that some drives (MGA IIRC), allocates one extra buffer which isn't mapped. I think we'll need a set of private buffers equivalent to what we use now (2MB), but we could probably get away with a smaller set of client buffers. I agree. In principle, each client could even use the same buffer over and over again (not referring to blits). And they don't even need to be DMA buffers at all. Fixed malloc'd memory from the user space should be good enough. We should also think about the Xserver, since we'll probably want to be able to use indirect command buffers from the Xserver to implement XAA with DMA. The X server could use the private buffers since it's trusted. It seems that the logic to accomodate all these cenarios will be a little complicated. We have to carefully think of the API (i.e., the IOCTLs) to allow everything play nice with each-other - inside and outside of the DRM. José Fonseca willmore I just wanted to answer his question on the mailing list about copying/verifying DMA buffers. Copy first and then verify using the target copy. jfonseca willmore: And why do you think that? willmore With a copy--unless you're using write cache bypass ala SSE--the target will be the cache 'hotter' of the two. If you verify first, you lose the cache benefits of optimized memcpys. willmore Completely optimal would be a hand tuned block prefetched chunk of assembly, but that's a bit out of the scope of this soltuion, yes? jfonseca mmm... thanx! jfonseca not necessarily. I've already done some hand coded assembly for copying the vertex data, and I hoped to adapt that for the copy/verify process later on. But it seems I need more info about prefetching for doing that. willmore No problem. The only thing that really determines this is if the memcpy uses a cache bypass type copy. willmore You have to prefetch by hand on x86 and I think there is an SSE instruciton to give the hints. I also think that for cpus that don't support prefetch, they just ignore the instruction--so that might not be exactly correct. jfonseca Not that in any case the buffer size we will be dealing is smaller than the cache size, to avoid a performance hit with the copying. jfonseca *Note* that in any case the buffer size we will be dealing is smaller than the cache size, to avoid a performance hit with the copying. willmore You can make the prefetch transparent on non-prefetch capable CPUs if you schedule things well in your code. willmore What is the typical buffer size? I was assuming near L1 sized. jfonseca I'm not quite sure of the values now, but is very rare to have more than 8K size. Usually there is a state change that forces to flush the buffer before it gets big. willmore Hmmm, that's in the range where you might consider doing it by hand and winning. How complex is the validation logic? jfonseca I'm not sure yet, but basically is checking if a command is acceptable (either using a bitmask, a table, or a series of compares), read a count word, and skip that many dwords, and go over it again until the end of the buffer. jfonseca just to be sure I'm on track, what's the usuall size of L1 cache? willmore Okay, a little pointer math should give you the opportunity to run the prefetch at the right points--as the basic loop isn't using fixed length operands, you can't do the normal *prefetch the next loop+x worth of data trick*. willmore Hmm, or could you? willmore 4K to 16K willmore Some wander way up like the dual 64K L1's of the K7 generation. Some modern procs like the P4 are only 4K. Go figure. :) willmore The nice thing about prefetch is you don't have to be exact about it. willmore You give the instruction a pointer to anywhere in a cache line and it'll prefetch the whole line. jfonseca As I said, I'm not very familiar with the actual assembly coding of prefecthing so I can't be sure now, but I'll investigate both the exact size of the buffers (we can
Re: [Dri-devel] Mach 64 and zsnes bug.
Roswel, On Sat, Oct 12, 2002 at 10:55:09PM +0100, roswel wrote: Hi i'm using mach64 dri binary 20020916 and i've a problem with zsnes 1.36 build with openGL support. If i don't use DRI, and launch zsnes with openGL 640x480 display, all work fine, but very slowly. But if i use DRI, and laucnh zsnes, i've 2 time the right side off the screen. Zsnes work faster, no special bug, but i've 2 time the right side, and i don't understand why. I've try with an ATI 128, and a radeon : no problem. And i use the same zsnes binary on the 3 computer. I've a debian unstable and a linux 2.4.18. I've no problem with other OpenGL Apps, like chromium, tuxracer, I've try other zsnes version and i've the same problem. Is it a DRI or a zsnes bug? i don't know. And i'd hope you could help me :) Thanks for the report, but I really can't guess what the problem may be becuase I'm having troubles picturing exactly what you mean with 2 times the right side off the screen. Could you provide a screenshot? José Fonseca --- 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] snapshot radeon-20021009 problem report: radeon_unlock
Sorry for the delay, but it has been a busy day today. The libxaa.a module build from today's CVS using gcc-2.95.3/glibc-2.2.5 is available at http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/libxaa.a.bz2 This expands to some fat 6MB due to the debug info, but first try it as is before attempt to strip anything out of it. I hope this helps to discover the Sig11 problem. José Fonseca On Fri, Oct 11, 2002 at 01:22:13AM +0200, Michel Dänzer wrote: On Fre, 2002-10-11 at 00:24, José Fonseca wrote: [...] Michel, what does exactly this mean? We don't have a way to find out the version of an XFree86 module directly yet (I understand the XFree86 CVS trunk has that now). So the radeon driver tries to load version 1.1 of libxaa. If that succeeds, it knows it can use the new facilities for line acceleration. If it fails, the driver knows it's version 1.0.0 and switches to backwards compatibility mode. Would this problem (the signal 11) go away if libxaa.a was included in the binary snapshots? Maybe, maybe not. --- 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
[spyro@f2s.com: Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock]
- Forwarded message from Ian Molton [EMAIL PROTECTED] - Date: Fri, 11 Oct 2002 22:11:50 +0100 From: Ian Molton [EMAIL PROTECTED] Subject: Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock To: José Fonseca [EMAIL PROTECTED] On Fri, 11 Oct 2002 20:31:53 +0100 José Fonseca [EMAIL PROTECTED] wrote: The libxaa.a module build from today's CVS using gcc-2.95.3/glibc-2.2.5 is available at http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/libxaa.a.bz2 This expands to some fat 6MB due to the debug info, but first try it as is before attempt to strip anything out of it. I hope this helps to discover the Sig11 problem. Works great here. I must say the new radeon driver is nice - such low CPU usage this box hasnt seen in a while on Q3 and xmms ;) props, all. - End forwarded message - --- 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] Mesa viewport transformation and depth scaling
Keith,
I'm curious to know how you reminded after so long (7 months)! Did you
actually writed it now or was it stuck in a mail queue all this time?
By now I got to more or less to those answers, but thanks anyway. As saying
goes: it's better late than never!
Regards,
José Fonseca
On Thu, Oct 10, 2002 at 10:17:06AM +0100, Keith Whitwell wrote:
José Fonseca wrote:
The current mach64 (mesa 4.x) driver doesn't seem to be doing z depth
test. After assuring that the mach64's z control register was being set
properly I realized that the vertex buffers had the z in a [0,1] scale
while the primitive drawing functions expected them in a a [0,0x].
The previous mach64 (mesa 3.x) driver defined the coord setup as
#define COORD \
do {\
GLfloat *win = VB-Win.data[i]; \
v-v.x = win[0] + xoffset; \
v-v.y = - win[1] + yoffset; \
v-v.z = win[2]; \
v-v.rhw = win[3]; \
} while (0)
while for example the R128 defined as
#define COORD \
do {\
GLfloat *win = VB-Win.data[i]; \
v-v.x = win[0] + xoffset; \
v-v.y = - win[1] + yoffset; \
v-v.z = depth_scale * win[2]; \
v-v.rhw = v-v.rhw2 = win[3]; \
} while (0)
So I removed the 'depth_scale' in calculation of hw_viewport, in
mach64CalcViewport, and everything worked fine.
But I still don't understand what's the relationship between
*CalcViewport and the viewport calculations made in _mesa_set_viewport.
At _mesa_set_viewport, for instance, there is a comment that says This
is really driver-specific and should be maintained elsewhere if at
all.. It seems that _mesa_set_viewport sets the scale to [0,MaxDepth],
but the *CalcViewport in most DRI drivers undo this scaling, rescaling
to a [0,1].
Correct. The _mesa_set_viewport code is really setting things up for how
the software rasterizer likes it's coordinates. In the Mesa 3.x days, Mesa
would multiply things by the viewport (giving VB-Win), whether you wanted
them or not, then you'd have to undo it with code like the above. Now, the
driver still 'fixes up' the viewport, but at least it doesn't have to do it
per-vertex.
My question is why the other DRI drivers do this (don't the chips expect
the depths in integer format as well?) and in what depth scale should
the vertex buffers be after all?
No, there's a good mixture. Some want floats scaled to certain values,
lots want floats in 0..1, all sorts of things.
This understanding would be important because the current mach64
triangle setup engine is able to specify the z values in 16.1 format,
but only the 16 integer part is being used, so I would like to implement
that as well.
Basically the responsibility for the viewport transformation has been
shifted to the driver. You don't see it because it's hidden in the
t_dd_vbtmp (?) template, but it's the driver that really does it.
So, you can take ndc coords (VB-ProjectedClipPtr), and manipulate them to
whatever twisted format the hardware likes.
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] snapshot radeon-20021009 problem report: radeon_unlock
On Thu, Oct 10, 2002 at 11:58:23PM +0200, Pawel Salek wrote: On 2002.10.10 18:09 Michel Dänzer wrote: Do you also see the signal 11 in the X server log? [snip] That won't help the signal 11 though, which is probably still due to some kind of incompatibility in the binary snapshots. Yes, I see signal 11 in the log (attached). Strangely, since the snapshots are supposedly compiled on RH8.0 (i.e. the same as mine), I Not quite: the snapshots are now being built on chroot'd environment with gcc-2.95.3 and glibc-2.2.5, which should suite everyone. thought it would not be a problem! Another strange for me thing is that the screen is not reset to text mode - but the keyboard works as it still was attached to the console. XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-72) / X Window System [...] (II) Loading sub module xaa (II) LoadModule: xaa (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (WW) module minor version (0) is less than the required minor version (1) [...] Michel, what does exactly this mean? Would this problem (the signal 11) go away if libxaa.a was included in the binary snapshots? José Fonseca --- 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: problems with radeon
Michel, On Mon, Oct 07, 2002 at 12:58:34AM +0200, Michel Dänzer wrote: On Son, 2002-10-06 at 18:08, Svein Harang wrote: Michel Dänzer: On Son, 2002-10-06 at 17:21, Svein Harang wrote: GNU/linux Debian testing/XFree86 Version 4.2.1, Hercules 3D Prophet 8500LE 2.4.19 Why don't you just use debhttp://penguinppc.org/~daenzer/debian/dri-trunk/./ This is new to me, I guess it wouldn't be a bad idea to mention them somewhere on dri.sf.net. Add into http://dri.sourceforge.net/snapshots/ a README.debian with a link and a brief description of how those differ from the ones provided on SourceForge. I use another unofficial Xfree deb-mirror, is this 4.1/4.2? DRI CVS snapshot packages, so based on 4.2.0. José Fonseca --- 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] Ann: I830/i845 snapshots available
Binary snapshots for the Intel i830/i845 chipsets are now available from the usual place, http://dri.sourceforge.net/snapshots/ . Please report any problems with the driver installation to me and/or dri-users mailing list, and problems with the drivers themselves to dri-devel. Jose Fonseca --- 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] install.sh bug
Jens, On Mon, Oct 07, 2002 at 09:55:10AM -0600, Jens Owen wrote: José Fonseca wrote: Next snapshots (which are now fully automated again) have this already. Notify if you run into problems. Jose, or anybody interested in creating an 830/845 package? TG has released many bug fixes for this chipset, but we've been too busy to update the package script. The 2D driver is shared with the i810, however a unique DRM driver and 3D driver is required. All aspects of 830/845 support should be building and running from the trunk, we're only missing the packaging for binary snapshots. TG is not dependent on a package, but I have seen a few posts from DRI and Xpert users who would have liked binary snapshots. No problem, I can do it. In fact I just didn't doit because I wasn't aware of the state of the driver as not much discussion about it has been going through dri-devel. I'll announce on the mailing-lists as soon as it's done. Jose Fonseca --- 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] problems with radeon-20021001,2 and 4 and Radeon Mobility M6
John, First, I'm sorry I didn't reply sooner. But I was holding out a little to see if anything came up relevant to your case before giving you the standard get-a-stack-backtrace-with-gdb. It appears that there have been similar problems with the r200 chip reported on th dri-devel mailing list so I'm forwarding to there too. I can already advance that the full XFree86.0.log would be nice to see if a message regarding the XAA versioning pops up or not. Jose Fonseca On Fri, Oct 04, 2002 at 04:08:47PM -0400, John Jasen wrote: On Fri, 4 Oct 2002, José Fonseca wrote: Was any error message in /var/log/XFree86.0.log or in /var/log/message, or `dmesg`? /var/log/XFree86.0.log (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled Fatal server error: Caught signal 11. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] ... very strange. dmesg: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected Intel i830M chipset agpgart: AGP aperture is 256M @ 0xe000 [drm] AGP 0.99 on Unknown @ 0xe000 256MB [drm] Initialized radeon 1.6.0 20020828 on minor 0 -- -- John E. Jasen ([EMAIL PROTECTED]) -- User Error #2361: Please insert coffee and try again. --- 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] install.sh bug
On Tue, Sep 24, 2002 at 02:38:51PM +0100, José Fonseca wrote: On Sat, Aug 31, 2002 at 09:01:16AM -0600, Jens Owen wrote: It looks like there is some type of problem when the GL subdirectory is empty. Here's what the script tries to do when it get's to an empty GL portion of the install. Ok. The problem is at: echo -nGL GLU libraries... cd GL for FILE in * do mv -f $XF86_GL_DIR/$FILE $XF86_GL_DIR/dri-old.$FILE $LOGFILE_TMP; cp -f $FILE $XF86_GL_DIR done The '*' wildcard isn't matched so it's copied verbatim into $FILE actually doing mv -f $XF86_GL_DIR/* $XF86_GL_DIR/dri-old.* $LOGFILE_TMP; Since I don't want to replace a bug for another, what should be the best thing to do in these cases? The alternatives I see are - replacing the * for `ls` - replacing the * for `find` Are there any caveats with any of these, or is there another way to do this? [...] I took Ian Romanick's suggestion and changed all to ls -1 * | while read FILE Next snapshots (which are now fully automated again) have this already. Notify if you run into problems. José Fonseca --- 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] New snapshots available - please test (Was: Snaps for gcc3, glibc-2.2)
On Thu, Oct 03, 2002 at 05:02:44PM -0600, Jens Owen wrote: José Fonseca wrote: Anyway, I already have the minimum chroot environment setup. I just need to test it with a few snapshots, and arrange so that everything can be automated from a cronjob again. Ok. I've just finished building a set of snapshots from the HEAD with this chroot environment. They are available from the usual place with a build tag of *-20021004-linux.i386.tar.bz2 . As said before these snapshots were made in a chroot environment, based on Gentoo Linux 1.2, with gcc-2.95.3, glib-2.2.5, and xfree-4.2.0. Your awesome! Thanks for your effort on these snapshots. It's nothing much, really. I've been using Gentoo Linux on my laptop for quite a while and I've always proceeded this way, i.e., by making a chroot environment where I install everything I need (from source which takes several days) and then move everything to the root and reboot. This way I can keep working during the process. The Gentoo Linux installation documentation pretty much describes all the process very nicely. The trickiest part that I still have to solve is doing this from crontab without opening a security hole on my machine - chroot requires root priveledges but I can't download, compile and _run_ code from the internet as root. My plan is to put it on root's cron job but call 'su' to become a regular user. This assuming, of course, that these snapshots are indeed the promised holly graal. Please test. José Fonseca --- 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] Snaps for gcc3, glibc-2.2
On Thu, Oct 03, 2002 at 05:06:38PM +0200, Dieter Nützel wrote: Am Mittwoch, 2. Oktober 2002 19:29 schrieb José Fonseca: On Wed, Oct 02, 2002 at 06:50:50PM +0200, Dieter Nützel wrote: [...] The RedHat 8.0/glibc-2.3 problem is simple. Stay away from it before glibc-2.3 is in wide spread. Installing a brand new distro on a building system isn't much useful in any way. Dieter, could you please explain what do you mean with this? Same as above. Use a chroot'd environment or wait with RH 8.0 (glibc-2.3) some little longer on your building machine. If you whish to take up the task of building the snapshots please be my guest, because I'm pretty tired of having to justify myself to others in respect of a service I offer freely using resources which are destinated to a specific unrelated end and that don't even belong to me. No offence were going to you from me. Ok? I appologize then. It seemed that I got too sensitive with the you-shouldn't-have-installed-latest-redhat-beta environment that arised. Anyway, I already have the minimum chroot environment setup. I just need to test it with a few snapshots, and arrange so that everything can be automated from a cronjob again. Jose Fonseca --- 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: Ann: gcc-2.96 compiled snapshots available (I'm going to smack redhat)
On Tue, Oct 01, 2002 at 04:25:21PM -0700, Russ Dill wrote: I just uploaded a set of binary snapshots built from the CVS head using RedHat's compat-gcc-7.3-2.96.110 package (which produces code compatible with the gcc bundled with the RedHat 7.3 and is the same which was producing the snapshots before). Unfortunately this appears to be not very helpful for those of us who test-run the snapshots on a regular basis against known OpenGL programs. This is from the radeon-20020930 binary snapshot: libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so libGL error: dlopen failed: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /usr/X11R6/lib/modules/dri/radeon_dri.so) _I_ don't have glibc-2.3 on my system and I believe, others don't either. So this _might_ render the binary snapshots pretty useless. But so the 2D driver from that snapshot works for you? Its c code, so I don't think the version of gcc is that important, what matters is the GLIBC_2.3 symbol, it doesn't show up in the X driver, because it isn't linked against libc, however, the dri portion is. For some bizzare reason, redhat has decided to put a cvs version of glibc in their upcoming distro release, which you are aparently compiling against, the current release version of glibc is 2.2.5, more than 90% of users are probably using this version. This still doesn't make sense to me. So isn't glic-2.3 backwards compatible? I've been using quite alot of RHL 7.2 compiled programs with the new version and had no problems whatsoever. So why do the DRI drivers require specifically version 2.3? Perhaps this is a pickyness of XFree86 module loader. *please* find a machine with a copy of glibc2.2, wait until glibc2.3 actually becomes a release to compile against it (or, if in the case of redhat, distribute it with your distro) The final RHL 8.0 was released 2 days ago. I'll upgrade soon but I already checked and it has the same version of gcc. Please note that the snapshots are done on workstation in the nigth, and I needed to upgrade for several reasons regarding my work. I have no other machine powerfull enough to do all these snapshots. What I'll do is install a older version of Gentoo in a chroot'ed environment to compile the snapshots using gcc-2.95.3 and glibc-2.2.5 for the _time being_. But I see rough times ahead for the binary snapshots. I surely can't make one for each system out there. And if the others distros don't also upgrade to glic-2.3 then I think the best is to completely stop the snapshots builds and replace them with a nice set of scripts which people can use to make their own customized snapshot. José Fonseca --- 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: Ann: gcc-2.96 compiled snapshots available (I'm going to smack redhat)
On Wed, Oct 02, 2002 at 01:35:50PM +0200, Michael Thaler wrote: On Wed, Oct 02, 2002 at 01:15:26PM +0200, Michel Dänzer wrote: You don't need to build for every system, just against an older version of glibc. I am not using these binary snapshots, but I appreciate this work. But please do not compile it against RedHat's glibc2.3 version. RedHat is the only distribution using it right now. The only reason I can see for this is, that RedHat _wants_ to be incompatible with other Linux distributions. Many efforts are undertaken to make Linux distributions more compatible to each-other, so please do not support RedHat in this. Please let's not turn this into a distribution flame. I really don't know RedHat's motives behind the decision of shipping glibc-2.2.93 but I for one don't think it's to try to be incompatible, but something in the lines of the reason behind the gcc-2.96.x, i.e., to better support another architecture in order to satisfy their enterprise costumer needs. But I couldn't care less in this case. This is the computer where I work, and linux distribution advocacy (or any other kind of advocacy for the matter) is the last thing I have on my mind when I choose what software I run on it. Regarding the snapshots I think Michel's suggestion is the best to go, i.e., keeping producing snapshots with older versions of gcc and glibc wich will hopefully remain compatible with the future versions. This may take a while to setup up so please be patient. I'm going to discontinue the snapshots until then. Jose Fonseca --- 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] Snaps for gcc3, glibc-2.2
On Wed, Oct 02, 2002 at 09:40:20AM -0400, Andy Dustman wrote: I finally last night got the CVS version to run, but only by running the complete X server out of the build tree. glxgears runs several hundred fps (I forget the exact number) but even better, used virtually no CPU time, so apparently the IRQ stuff is working. (Radeon 8500 128MB (QL), Pentium III-700, Red Hat Linux 7.3) What didn't work was making a binary snapshot (via the dripkg.sh script) and installing that over the system-wide X installation: It does the the same old trick of the video going dead and X dying on signal 11. This is no surprise since the snapshot lacks some of the libraries which DRI has updated. If I can put together a binary snapshot with the right libraries that will work with a stock installation, I'll be happy to supply these, since they should be like the old snapshots that José Fonseca was supplying prior to his upgrade. I think it's probably much easier if done with the aid of the scripts. Since you already downloaded and compiled from CVS you just need to download dripkg.sh and install.sh scripts from http://dri.sourceforge.net/snapshots/scripts/ . Then all you have to do is ./dripkg.sh RADEON /path/to/cvs/xc/ /path/to/cvs/build/ 20021002-linux.i386 If didn't built on a seperate lndir'd 'build' directory just give the same path to the CVS. Can anyone put together a list of what libraries must be upgraded? The GL directory in the dripkg is empty in all the old snapshots; I suspect that's a Bad Thing. Not really. In the beggining of the snapshots prodcution it was decided to only include the device-dependent files (at least in theory, since there have been some unexpected exceptions). Jose Fonseca --- 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] Snaps for gcc3, glibc-2.2
On Wed, Oct 02, 2002 at 06:50:50PM +0200, Dieter Nützel wrote: Am Mittwoch, 2. Oktober 2002 18:35 schrieb Andy Dustman: [...] Which is it, then: Snapshots or no snapshots? The current snapshots (for linux-i386) don't work unless you have Red Hat 8.0 and/or glibc-2.3; I'm not even sure that they work on that platform. Broken snapshots are worse than no snapshots at all (you can't download something that isn't going to work if it isn't there). Sorry, but read again. I didn't deny the snapshots per se. Only your call for something like dripkg.sh. I'm completely lost with the heading of this thread. If I understood correctly, what's on the table is the generation of some snapshots until things go on track again (i.e., I setup a chroot'd environment to build the snapshots). Andy, it's not the right time to discuss what should shouldn't be included in the binary snapshots. And the best way to acomplish this is using the dripkg.sh script, which is the one that has been making the binary snapshots until now. If things don't workout this way then it's best to have no snapshots at all for a couple of days, than to have greater fuss than the one that already is. The RedHat 8.0/glibc-2.3 problem is simple. Stay away from it before glibc-2.3 is in wide spread. Installing a brand new distro on a building system isn't much useful in any way. Dieter, could you please explain what do you mean with this? If you whish to take up the task of building the snapshots please be my guest, because I'm pretty tired of having to justify myself to others in respect of a service I offer freely using resources which are destinated to a specific unrelated end and that don't even belong to me. Jose Fonseca --- 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: Ann: gcc-2.96 compiled snapshots available (I'm going to smack redhat)
On Wed, Oct 02, 2002 at 10:33:11AM -0700, Russ Dill wrote: [...] But I see rough times ahead for the binary snapshots. I surely can't make one for each system out there. And if the others distros don't also upgrade to glic-2.3 then I think the best is to completely stop the snapshots builds and replace them with a nice set of scripts which people can use to make their own customized snapshot. upgrade to glibc-2.3? technically, such a thing doesn't exist yet, so to ask every distro to upgrade to it... redhat is making cvs snapshots of glibc, and distributing those instead of patching important bugs in the release version, and using that. CVS versions of software often contain new bugs and even security vulnerabilities, it is far more prudent to work with a release version of such a major system component. Because of this, most distros will probably wait until it becomes a release until they include it. I agree that that would be a cleaner approach. Anyway my comments above weren't actually refering to this unreleased version. I was referring to the point when glibc-2.3 would be released and adopted by other distributions. But as Michel Danzer said, we can stick to produce glibc-2.2.5 compiled snapshots for a little longer as they should work both on glibc-2.2.x as well as glibc-2.3.x. gcc shouldn't be a problem either as there is no C++ code in the DRI drivers. I really do see your frustration, as now anyone who develops software on redhat (at least those that keep up with redhat) cannot release binaries and expect them to work on anyone elses system. You don't need to worry about compiling for every system out there, just what is current release. As far as actually getting this done, redhat has provided cross compiler rpms in the past, so you may be able to get these, and cross compile for glibc2.2. I don't see a rough time for binary snapshots, just a rough time for developers using cvs snapshots of glibc Unfortunately it does provide compat-gcc packages but not glibc ones. Jose Fonseca --- 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: SIS630 - Support?
Andreas, On Mon, Sep 30, 2002 at 06:57:52PM +0200, Andreas Allacher wrote: Hi, Will you add (or will there be in future) also DRI-support for the graphic device SIS630. If yes do you know a not exactly date? I'm not 100% sure of the current state of the SIS chips DRI drivers so I'm CC'ing my answer to the dri-devel mailing list so that others can corroborate. AFAIK, there is (or was) support for the SIS 3xx drivers in the initial XFree 4.0.x releases (may even 4.1.x), but the driver never got ported to the new Mesa 4.x driver architecture due to lack of people interested. I recall a newbie ofered him self to try even without the specs, but I don't know if anything ever got made at all. So in summary, if you want DRI you have to stick with older XFree86 versions, unless someone steps into porting the deprecated DRI driver. Personally I do not have time to do it myself as I already have my hands full with other things, but I wouldn't mind helping by guiding all the way if somebody was willing to code it. Jose Fonseca PS: In case you don't know it, Thomas Winischhofer has lot of info regarding the FB and XFree86 SIS drivers at http://www.winischhofer.net/linuxsis630.shtml and http://www.winischhofer.net/sisdri.shtml --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gcc-2.96 radeon snapshot fails
On Sun, Sep 29, 2002 at 09:03:12PM -0700, Jason Cook wrote: Jose, Unfortunately that doesn't fix the problem for me. I get the same results as before. I loose all visual context, X segfaults and all my VTs are black. I reboot and restore. Sorry I can't give feeback on the other cards. What could the problem be? Do the latest snapshots work on your machine? Maybe a some other change has happened in the CVS that significantly alters things for the snapshots? My machines have all Mach64 which lives in a seperate branch now, so they are unaffected. Well, there are two things that we could try: make a series of snapshots without merging the XFree 4.2.0 code in, or make a series of snapshots on an native gcc 2.9x machine. But personally I'm more inclined to go directly find the reason to the problem than to test every combination of parameters in the hope of finding the answer. Jason, is it possible for you to download Xfree86 GDB (http://www.dawa.demon.co.uk/xfree-gdb/ ), start the X server remotely doing gdb XFree86 and perhaps starting some applications from another remote terminal by first setting the DISPLAY environment var. XFree86 should then segfault and you should be able to get a stack backtrace by typing 'bt' on the gdb's command line. Also, I'm not in depth of the changes in XAA that caused this (please correct-me if I'm wrong), but if the problem is actually there, shouldn't disabling XAA avoid the segfault then? Incidently, why are the gcc 3.x.x snapshots almost twice as large? As Felix pointed out, it seems that the new gcc uses a different debug format. If that alone is the single reason is the mistery... José Fonseca --- 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] [jkay@cox.net: Re: [Dri-users] Ann: gcc-2.96 compiled snapshots available]
- Forwarded message from John Kelly [EMAIL PROTECTED] - Date: 28 Sep 2002 23:34:22 -0400 From: John Kelly [EMAIL PROTECTED] Subject: Re: [Dri-users] Ann: gcc-2.96 compiled snapshots available To: José Fonseca [EMAIL PROTECTED] On Sat, 2002-09-28 at 13:02, José Fonseca wrote: I just uploaded a set of binary snapshots built from the CVS head using RedHat's compat-gcc-7.3-2.96.110 package (which produces code compatible with the gcc bundled with the RedHat 7.3 and is the same which was producing the snapshots before). This archive installed perfectly, but it still causes XFree to exit with error 11, and the monitor goes into sleep mode instead of showing the GDM login. Reverting manually back to Sept 21 r200 fixes all. - End forwarded message - --- 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] knobs to turn?
Nick, On Sun, Sep 29, 2002 at 02:51:53PM -0600, Nicholas Leippe wrote: Hi, I was wondering if some dev out there could spend say 2-5 minutes and post an email that lists all of the possible knobs that can be turned. I know there's a bunch, but they're scattered though several postings and hard to find. Check http://dri.sourceforge.net/doc/faq/testing.html#AEN1637 . If you see any other 'knobs' worthy to mention (even not necessarily environment vars) then I would appreciate that you forward them to me so that I can add them to the FAQ as well. For instance, very interesting 'knobs' not mentioned in the FAQ are the driver specific debugging environment variables, such as MACH64_DEBUG, RADEON_DEBUG, and others alike. Due to their specificity and volatility I don't think is worth to have them detailed in the FAQ, but a direct link from the FAQ to the CVS file where they are implemented (and hopefully documented) should be a good idea. Agreed? [...] I keep seeing posts about pageflipping, hw perf boxes, and many other little things to try and get a little frustrated trying to track down the knob to turn them on/off... This could make a good little web page addition to the site as well. José Fonseca --- 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
On Sat, Sep 28, 2002 at 03:24:56PM +0100, Keith Whitwell wrote: Should we stop producing snapshots temporarily until the xaa/compiler/who-knows-what problems are resolved? There seem to be a lot of complaints about the ones up there now... Keith I have no problem stopping the snapshot builds, but that won't do help much as people will probably download the latest available. We also haven't recived feedback regarding non-radeon cards. Spite of that, I'm going now try to obtain snapshots using RedHat's compat-gcc and put them in a seperate dir so that we can seperate the two distinct changes happening here: XAA binary compatibility and gcc 3.2. I'll announce it when done. José Fonseca --- 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] Ann: gcc-2.96 compiled snapshots available
I just uploaded a set of binary snapshots built from the CVS head using RedHat's compat-gcc-7.3-2.96.110 package (which produces code compatible with the gcc bundled with the RedHat 7.3 and is the same which was producing the snapshots before). The files are the *-linux-gcc296.i386.tar.bz2 available from http://dri.sourceforge.net/snapshots/ . In case your web browser gives you a hard time to distinguish they are half size of the ones generated by gcc-3.2 (!) as someone already had notice. I have no idea why is that. All of you which have been experiencing problems with the latest snapshots please test and report back to the dri-devel mailing list. If there is a difference then I'll make them available on a regular basis. José Fonseca --- 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 Wed, Sep 25, 2002 at 10:32:32PM -0400, Andy Dustman wrote: On Tue, 2002-09-24 at 09:25, José Fonseca wrote: I've updated my workstation to the RedHat Linux 7.3.94 beta, which has gcc 3.2. So now forward the snapshots will be built with this version. AFAIK this shouldn't pose any problem to the users since the key issue is that the kernel modules are compiled with the same version of gcc that compiled the kernel, and that still holds true. If the kernel modules were the only issue, you'd be right. Unfortunately the other important component of the snapshots is the DRI shared library. Since (for those who haven't heard) GCC 3.2 breaks binary compatibility with earlier versions, the shared libraries don't work. My X server dies on signal 11 almost immediately (during drm initialization). So these snapshots will only work if your X server is compiled with GCC 3.2. Also I've noticed that the shared library is now twice the size (or more) than it used to be (went from about 5 MB to 12 MB). AFAIK the announced breakeage concerned C++ only. Since very few people seem to have GCC 3.2 at the moment (I do have a Gentoo 1.4-pre1 box that does, but haven't tried DRI snaps on it yet), can we please have some built with the old gcc? Most likely Red Hat provides this in a gcc-compat package. I'm trying now to build some myself from CVS, but didn't have much luck last night (result didn't run). The ability of gcc-3.2 to generate more efficient code to Pentium III and IV, being able to generate SSE and SSE2 instructions automatically was one of the main reasons why I installed Redhat beta, since I do lot of numerical stuff. This together with the new gnome2 desktop. Unfortunately I don't have other machine were I can build those snapshots, and SourceForge compiler farm fails to build the snapshots except for some cards (ATI cards IIRC) due to an outdate Xfree installed on the system. RedHat does indeed provides a compat-gcc package. I'll see what I can do to use it within my scripts. Nevertheless it would be good to be sure about these binary compatabilities, since the widespread of gcc-3.2 will happen very soon. José Fonseca --- 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] Snapshots now being built with gcc 3.2
Hi guys. Yep, vacations ended. I've updated my workstation to the RedHat Linux 7.3.94 beta, which has gcc 3.2. So now forward the snapshots will be built with this version. AFAIK this shouldn't pose any problem to the users since the key issue is that the kernel modules are compiled with the same version of gcc that compiled the kernel, and that still holds true. Strangely, when testing the snapshots scripts with the new setup I noticed that only radeon and r200 drivers are being built on the HEAD (as there is no errors on the build log). Keith, I know you've been merging r200-0-2-branch, so do you know anything about this? The Mach64 development on my side is still on hold. Besides the hassle of returning from vacations, and have a lot of stuff to do, my laptop's hard drive is busted so I've been working at the univeristy were I don't have any Mach64 card near me. Hopefully I should receive a new drive shortly. Jose Fonseca --- 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] install.sh bug
On Sat, Aug 31, 2002 at 09:01:16AM -0600, Jens Owen wrote: It looks like there is some type of problem when the GL subdirectory is empty. Here's what the script tries to do when it get's to an empty GL portion of the install. Ok. The problem is at: echo -nGL GLU libraries... cd GL for FILE in * do mv -f $XF86_GL_DIR/$FILE $XF86_GL_DIR/dri-old.$FILE $LOGFILE_TMP; cp -f $FILE $XF86_GL_DIR done The '*' wildcard isn't matched so it's copied verbatim into $FILE actually doing mv -f $XF86_GL_DIR/* $XF86_GL_DIR/dri-old.* $LOGFILE_TMP; Since I don't want to replace a bug for another, what should be the best thing to do in these cases? The alternatives I see are - replacing the * for `ls` - replacing the * for `find` Are there any caveats with any of these, or is there another way to do this? Jose Fonseca + echo -n ' GL GLU libraries...' + cd GL + mv -f /usr/X11R6/lib/libdps.a /usr/X11R6/lib/libdps.so /usr/X11R6/lib/libdps.so.1 /usr/X11R6/lib/libdps.so.1.0 /usr/X11R6/lib/libdpstk.a /usr/X11R6/lib/libdpstk.so /usr/X11R6/lib/libdpstk.so.1 /usr/X11R6/lib/libdpstk.so.1.0 /usr/X11R6/lib/libfntstubs.a /usr/X11R6/lib/libfontenc.a /usr/X11R6/lib/libFS.a /usr/X11R6/lib/libGL.a /usr/X11R6/lib/libGL.so /usr/X11R6/lib/libGL.so.1 /usr/X11R6/lib/libGL.so.1.2 /usr/X11R6/lib/libGLU.a /usr/X11R6/lib/libGLU.so /usr/X11R6/lib/libGLU.so.1 /usr/X11R6/lib/libGLU.so.1.3 /usr/X11R6/lib/libGLw.a /usr/X11R6/lib/libI810XvMC.a /usr/X11R6/lib/libICE.a /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libICE.so.6 /usr/X11R6/lib/libICE.so.6.3 /usr/X11R6/lib/libMagick.a /usr/X11R6/lib/libMagick++.a /usr/X11R6/lib/libMagick.la /usr/X11R6/lib/libMagick++.la /usr/X11R6/lib/libMagick.so /usr/X11R6/lib/libMagick++.so /usr/X11R6/lib/libMagick.so.5 /usr/X11R6/lib/libMagick++.so.5 /usr/X11R6/lib/libMagick.so.5.0.43 /usr/X11R6/lib/libMagick++.so.5.0.43 /usr/X11R6/lib/libMrm.a /usr/X11R6/lib/libMrm.so /usr/X11R6/lib/libMrm.so.1 /usr/X11R6/lib/libMrm.so.1.0.2 /usr/X11R6/lib/libMrm.so.3 /usr/X11R6/lib/libMrm.so.3.0.1 /usr/X11R6/lib/liboldX.a /usr/X11R6/lib/libOSMesa.a /usr/X11R6/lib/libOSMesa.so /usr/X11R6/lib/libOSMesa.so.3 /usr/X11R6/lib/libOSMesa.so.3.3 /usr/X11R6/lib/libpsres.a /usr/X11R6/lib/libpsres.so /usr/X11R6/lib/libpsres.so.1 /usr/X11R6/lib/libpsres.so.1.0 /usr/X11R6/lib/libSM.a /usr/X11R6/lib/libSM.so /usr/X11R6/lib/libSM.so.6 /usr/X11R6/lib/libSM.so.6.0 /usr/X11R6/lib/libUil.a /usr/X11R6/lib/libUil.so /usr/X11R6/lib/libUil.so.1 /usr/X11R6/lib/libUil.so.1.0.2 /usr/X11R6/lib/libUil.so.3 /usr/X11R6/lib/libUil.so.3.0.1 /usr/X11R6/lib/libX11.a /usr/X11R6/lib/libX11.so /usr/X11R6/lib/libX11.so.6 /usr/X11R6/lib/libX11.so.6.2 /usr/X11R6/lib/libXau.a /usr/X11R6/lib/libXaw3d.a /usr/X11R6/lib/libXaw3d.so /usr/X11R6/lib/libXaw3d.so.6 /usr/X11R6/lib/libXaw3d.so.6.1 /usr/X11R6/lib/libXaw3d.so.7 /usr/X11R6/lib/libXaw3d.so.7.0 /usr/X11R6/lib/libXaw.a /usr/X11R6/lib/libXaw.so /usr/X11R6/lib/libXaw.so.6 /usr/X11R6/lib/libXaw.so.6.1 /usr/X11R6/lib/libXaw.so.7 /usr/X11R6/lib/libXaw.so.7.0 /usr/X11R6/lib/libXdmcp.a /usr/X11R6/lib/libXext.a /usr/X11R6/lib/libXext.so /usr/X11R6/lib/libXext.so.6 /usr/X11R6/lib/libXext.so.6.4 /usr/X11R6/lib/libxf86config.a /usr/X11R6/lib/libXfont.a /usr/X11R6/lib/libXfontcache.a /usr/X11R6/lib/libXfont.so /usr/X11R6/lib/libXfont.so.1 /usr/X11R6/lib/libXfont.so.1.4 /usr/X11R6/lib/libXft.a /usr/X11R6/lib/libXft.so /usr/X11R6/lib/libXft.so.1 /usr/X11R6/lib/libXft.so.1.1 /usr/X11R6/lib/libXi.a /usr/X11R6/lib/libXinerama.a /usr/X11R6/lib/libXi.so /usr/X11R6/lib/libXi.so.6 /usr/X11R6/lib/libXi.so.6.0 /usr/X11R6/lib/libxkbfile.a /usr/X11R6/lib/libxkbui.a /usr/X11R6/lib/libXm.a /usr/X11R6/lib/libXm.so /usr/X11R6/lib/libXm.so.1 /usr/X11R6/lib/libXm.so.1.0.2 /usr/X11R6/lib/libXm.so.3 /usr/X11R6/lib/libXm.so.3.0.1 /usr/X11R6/lib/libXmu.a /usr/X11R6/lib/libXmu.so /usr/X11R6/lib/libXmu.so.6 /usr/X11R6/lib/libXmu.so.6.2 /usr/X11R6/lib/libXmuu.a /usr/X11R6/lib/libXmuu.so /usr/X11R6/lib/libXmuu.so.1 /usr/X11R6/lib/libXmuu.so.1.0 /usr/X11R6/lib/libXp.a /usr/X11R6/lib/libXpm.a /usr/X11R6/lib/libXpm.so /usr/X11R6/lib/libXpm.so.4 /usr/X11R6/lib/libXpm.so.4.11 /usr/X11R6/lib/libXp.so /usr/X11R6/lib/libXp.so.6 /usr/X11R6/lib/libXp.so.6.2 /usr/X11R6/lib/libXrandr.a /usr/X11R6/lib/libXrandr.so /usr/X11R6/lib/libXrandr.so.1 /usr/X11R6/lib/libXrandr.so.1.0 /usr/X11R6/lib/libXrender.a /usr/X11R6/lib/libXrender.so /usr/X11R6/lib/libXrender.so.1 /usr/X11R6/lib/libXrender.so.1.1 /usr/X11R6/lib/libxrx.so /usr/X11R6/lib/libxrx.so.6 /usr/X11R6/lib/libxrx.so.6.3 /usr/X11R6/lib/libXss.a /usr/X11R6/lib/libXt.a /usr/X11R6/lib/libXTrap.a /usr/X11R6/lib/libXTrap.so /usr/X11R6/lib/libXTrap.so.6 /usr/X11R6/lib/libXTrap.so.6.4 /usr/X11R6/lib/libXt.so /usr/X11R6/lib/libXt.so.6 /usr/X11R6/lib/libXt.so.6.0 /usr/X11R6/lib/libXtst.a /usr/X11R6/lib/libXtst.so /usr/X11R6/lib/libXtst.so.6 /usr/X11R6/lib/libXtst.so.6.1
Re: [Dri-devel] Re: mach64 multitexture bug
Thanks for the snapshots Leif. For what you've shown me it seems that the problem lives in TAG(interp) of mach64_native_vbtmp.h. Unfortunetaly I haven't been able to do much testing yet, because after updating my local CVS tree with the recent changes I was forced to recompile the whole tree again. I'll get back again as soon as I have further clue. José Fonseca On Mon, Jul 15, 2002 at 07:29:53PM -0400, Leif Delgass wrote: The problem only appears when the procedural texture in the center of the octagon is clipped by the window edge. Here's a shot of it unclipped: http://retinalburn.net/linux/q3a-unclipped.jpg So far, I've only noticed this on a few of the procedural textures that rotate and/or stretch. This one does both. On Mon, 15 Jul 2002, Leif Delgass wrote: I forgot to mention that commenting out the fallback primitive functions didn't have an effect. On Mon, 15 Jul 2002, Leif Delgass wrote: Here's a couple screenshots of the multitexture bug in quake3 lightmap mode (two slightly different angles): http://retinalburn.net/linux/q3a-bug1.jpg http://retinalburn.net/linux/q3a-bug2.jpg -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
On Tue, Jul 16, 2002 at 11:54:02AM -0400, Leif Delgass wrote: On Wed, 10 Jul 2002, Allen Barnett wrote: 2. clipping.c: In this program, a cube is drawn using a flat shaded quad strip with different colors for each pair of vertices. If a face of the cube is clipped by an edge of the X window, then the triangles which the quad is decomposed into are not drawn in the correct color. You can rotate the cube around with the left mouse button to see the effect on different faces. You can zoom in and out with the middle mouse button. Once the cube is entirely inside the window, it is drawn properly. I think this may be related to a problem mentioned on Leif's status page. (It works OK with Mesa, with indirect rendering and with the TDFX driver.) I fixed this by having Mesa copy the provoking-vertex color into all vertices (by telling the template we don't have hardware flat-shading). The mach64 uses a fixed vertex number for flatshading, and we implement all primitives as triangles, reusing vertices where possible. Perhaps there is a way to order the vertices to get flat-shading to work without copying colors, It's probably worth to check it out, to avoid all the copying restoring that happens with this. but this fixes the problem. The driver still turns on flat-shading in the hardware setup engine when applicable, but I'm not sure if this makes any difference in performance. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Problems with a Radeon mobility M6 and RH 7.3
I'm CC'ing to dri-devel as well to get a broaded audience.
On Tue, Jul 16, 2002 at 05:28:37PM +0200, dylan wrote:
Good plan, The DRM module is not happy and throws a bit of a fit.
Here is a small snippet showing the exact response, how would I go
about upgrading the drm module or would I have to wait until the 1671
is supported. I am going to try the agp_try_unsupported=1 in the mean
time.
Thanks again.
Jul 16 17:41:26 Coke modprobe: modprobe: Can't locate module
char-major-226
Jul 16 17:41:27 Coke modprobe: modprobe: Can't locate module
char-major-226
Jul 16 17:41:27 Coke kernel: Linux agpgart interface v0.99 (c) Jeff
Hartmann
Jul 16 17:41:27 Coke kernel: agpgart: Maximum main memory to use for
agp memory: 202M
Jul 16 17:41:27 Coke kernel: agpgart: Unsupported Ali chipset (device
id: 1671), you might want to try agp_try_unsupported=1.
If agp_try_unsupported=1 doesn't work you may be on a world of pain...
Jul 16 17:41:27 Coke kernel: [drm] Initialized radeon 1.1.1 20010405 on
minor 0
Jul 16 17:41:27 Coke kernel: [drm:radeon_do_init_cp] *ERROR* PCI GART
not yet supported for Radeon!
PCI could be supported for Radeon. I don't know if this support has been
added since 4.2.0. If yes then you could try a binary snapshot from
http://dri.sf.net/snapshots .
What happens below shouldn't really happen, no matter what.
Jul 16 17:41:27 Coke kernel: Unable to handle kernel NULL pointer
dereference at virtual address 001c
Jul 16 17:41:27 Coke kernel: printing eip:
Jul 16 17:41:27 Coke kernel: d09b3fff
Jul 16 17:41:27 Coke kernel: *pde = 0b511067
Jul 16 17:41:27 Coke kernel: *pte =
Jul 16 17:41:27 Coke kernel: Oops:
Jul 16 17:41:27 Coke kernel: radeon binfmt_misc autofs ds yenta_socket
pcmcia_core 8139too mii ide-scsi scs
Jul 16 17:41:27 Coke kernel: CPU:0
Jul 16 17:41:27 Coke kernel: EIP:0010:[d09b3fff]Not tainted
Jul 16 17:41:27 Coke kernel: EFLAGS: 00013246
Jul 16 17:41:27 Coke kernel: Jul 16 17:41:27 Coke kernel: EIP is at
radeon_do_cp_idle [radeon] 0x1f (2.4.18-3)
Jul 16 17:41:27 Coke kernel: eax: ebx: ecx:
edx: 0001
Jul 16 17:41:27 Coke gdm[1279]: gdm_slave_xioerror_handler: Fatal X
error - Restarting :0
Jul 16 17:41:27 Coke kernel: esi: edi: 0001 ebp:
esp: cb179f44
Jul 16 17:41:27 Coke kernel: ds: 0018 es: 0018 ss: 0018
Jul 16 17:41:27 Coke kernel: Process X (pid: 1280, stackpage=cb179000)
Jul 16 17:41:27 Coke kernel: Stack: cb179f58 d09b4f85
ca657000 0001 0001 ca657000 Jul 16 17:41:27 Coke kernel:
cfe0cb20 bbe0 40086442 d09afe14 caf5cbc0 cfe0cb20 40086442 bbe0
Jul 16 17:41:27 Coke kernel:40086442 ffe7 bbe0 cfe0cb20
c0146547 caf5cbc0 cfe0cb20 40086442 Jul 16 17:41:27 Coke kernel: Call
Trace: [d09b4f85] radeon_cp_stop [radeon] 0xf5 Jul 16 17:41:27 Coke
kernel: [d09afe14] radeon_ioctl [radeon] 0xe4 Jul 16 17:41:27 Coke
kernel: [c0146547] sys_ioctl [kernel] 0x217 Jul 16 17:41:27 Coke
kernel: [c0108923] system_call [kernel] 0x33 Jul 16 17:41:27 Coke
kernel: Jul 16 17:41:27 Coke kernel: Jul 16 17:41:27 Coke kernel: Code:
8b 43 1c 83 f8 18 77 19 6a 18 53 e8 01 15 00 00 59 58 8b 43 Jul 16
17:41:36 Coke gdm(pam_unix)[1285]: session opened for user dylan by
(uid=0)
Jul 16 17:41:40 Coke modprobe: modprobe: Can't locate module
sound-slot-0
Jul 16 17:41:40 Coke modprobe: modprobe: Can't locate module
sound-service-0-0
Jul 16 17:41:45 Coke gnome-name-server[1424]: starting
Jul 16 17:41:45 Coke gnome-name-server[1424]: name server starting
Jul 16 17:41:45 Coke gnome-name-server[1426]: starting
José Fonseca
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:16:37PM +0200, Felix Kühling wrote: Hi José, I got a similar error with your patch applied. On stdout I get the usual Error flushing vertex buffer: return = -11 but the log looks different: Yes, it's a different problem this time - the engine locked hard. [...] Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] buffer contents: Jul 15 13:04:02 viking kernel: [drm] d01b4000: 0x00060190 Jul 15 13:04:02 viking kernel: [drm] d01b4004:0x0240 = 0x3d806d0d Jul 15 13:04:02 viking kernel: [drm] d01b4008:0x0244 = 0xbcc71574 Jul 15 13:04:02 viking kernel: [drm] d01b400c:0x0248 = 0x3b9f445d Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4454:0x0840 = 0x3d9f677c Jul 15 13:04:02 viking kernel: [drm] d01b4458:0x0844 = 0xbc78d3d8 Jul 15 13:04:02 viking kernel: [drm] d01b445c:0x0848 = 0x3bc179a8 Jul 15 13:04:02 viking kernel: [drm] d01b4460:0x084c = 0xff10 Jul 15 13:04:02 viking kernel: [drm] d01b4464:0x0850 = 0xfee88000 Jul 15 13:04:02 viking kernel: [drm] d01b4468:0x0854 = 0xffcc Jul 15 13:04:02 viking kernel: [drm] d01b446c:0x0858 = 0x07a203ff Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4dc4:0x11b0 = 0x053d03df Jul 15 13:04:02 viking kernel: [drm] d01b4dc8:0x11b4 = 0x01c0 Jul 15 13:04:02 viking kernel: [drm] d01b4dcc:0x11b8 = 0xbb9a4b09 These values on the left side are absurd - the DMA buffer is busted. This means that either invalid data was generated or it was overwritten. I vote for the former (attending the new vertex template code may be buggy somewhere). [...] I think its just a coincident that it happend so soon after the server start, since I tested it a lot last night and nothing happened. Yes. It's most definetly an unrelated problem. [...] One more thing, I'm going home for at least four weeks on wednesday, so I won't be able to do any more testing then. And when I get back I will most probably upgrade to a Xpert 2000 Pro. So if there is any other patch you want me to test, there is not much time left. Ok, I'll contact you if make any advances here. hmm.. ATI Xpert 2000 Pro? That's an R128... I'm sad we won't be able to count with you anymore for the Mach64 development, but I hope you still keep your insterest on the DRI development. Thanks for all the help you've given, Felix! José Fonseca --- 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] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:26:58PM +0200, Felix Kühling wrote: I tried restarting torcs after the last problem and it locked up the Xserver. I got something in the log before I rebooted: Jul 15 13:16:48 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] ring contents: Jul 15 13:16:48 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:48 viking kernel: Jul 15 13:16:48 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x ^^ Jul 15 13:16:48 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:48 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:48 viking kernel: [drm] ... Jul 15 13:16:48 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:48 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 The engine locked while looping around the ring, reading the first entry. My guess is that the engine was already busted somehow... Jul 15 13:16:48 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:48 viking kernel: [drm] [...] José Fonseca --- 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: Binary packages (Was: Re: [Dri-devel] R200 testing)
On Mon, Jul 15, 2002 at 10:35:46PM +0200, Dieter Nützel wrote: On Sunday 14 July 2002 16:15, José Fonseca wrote: [...] What the install scripts additionally does is `modprobe agpgart`. Could it be that agpgart was forgotten to be added to /etc/modules.conf? It should read this way correctly: # agpgart is i386 only right now --- not true anylonger? pre-install mga /sbin/modprobe -k agpgart pre-install r128 /sbin/modprobe -k agpgart pre-install radeon /sbin/modprobe -k agpgart options agpgart agp_try_unsupported=1 I really don't know much about modules.conf. Usually I just add lines like the ones below: below mach64 agpgart below radeon agpgart José Fonseca --- 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: Binary packages (Was: Re: [Dri-devel] R200 testing)
On Sun, Jul 14, 2002 at 07:42:36AM -0600, Keith Whitwell wrote: Next, tuxracer ran, but the menus were basically unusable. Sounds like he hit a whack of software fallbacks - frame rate on menus must have been less than 1fps. He didn't have the patience to get into the game. this happens to me as well, but only if i restart the system after installing the beta r200 driver. Re-running the install.sh script solves the problem and the tuxracer menusystem is as fast as expected. I suspect this is a problem of default dri kernel modules not being overwritten (?), but the install reloads them properly. It's not a big issue though. Interesting. Jose, Alan, have you seen similar problems with the install scripts for other hardware? It sounds like the old radeon.o isn't getting overwritten/overridden. I guess the install script insmod's it explicitly? No. The install script loads the module with `modprobe radeon`, i.e., without the .o, so it should pick the installed one. What the install scripts additionally does is `modprobe agpgart`. Could it be that agpgart was forgotten to be added to /etc/modules.conf? José Fonseca --- 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] mach64-20020704: gltestperf lockup on Zsmooth triangles
On Thu, Jul 04, 2002 at 06:49:32PM +0100, José Fonseca wrote:
On Thu, Jul 04, 2002 at 12:58:13PM -0500, David Willmore wrote:
I had a lockup on an older version of the mach64 DRI driver, so
I thought I'd retest with a newer one. gltestperf locks up (no
response to keyboard, but mouse still moves--it locked up as well
in the older version) on the ZSmooth Triangles size:480 test.
Not immediately, but it locks up after the second set of triangles
and maybe early into the third.
Thanks for the report.
Here's the relivant stuff from the kernel messages:
[...]
There may have been more, but it didn't make it to the log.
Any more logging/system configuration info needed?
I'm going to see if I can reproduce it when I finish the current round
of changes.
Ok. I've determined the cause of this one: gltestperf floods with DMA buffers
enough to keep the chip busy for more than 1sec (the current timeout) so
the DRM thinks the chip locked..!
For instance changing the following line of mach64_ring_idle in mach64_dma.c
for ( i = 0 ; i dev_priv-usec_timeout; i++ ) {
to
for ( i = 0 ; i dev_priv-usec_timeout 4; i++ ) {
does the trick. But we need a more robust implementation of
mach64_ring_idle. Since we probably want to keep the timeout small
my suggestion is to count the time that takes for the ring head pointer
to advance instead of counting the time it takes to finish processing
all ring entries.
Any other ideas? Have other driver ever faced problems like this one?
José Fonseca
---
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] mach64-20020704: gltestperf lockup on Zsmooth triangles
On Sun, Jul 14, 2002 at 02:04:27PM -0400, Leif Delgass wrote: [...] A couple of things we could do that might help are to implement frame aging and/or add the ring space check back in to throttle the frame rate and limit the amount of pending buffers on the ring. That could help but it wouldn't prevent that an application generated a wild number of triangles per frame and this would happen again, so I already fixed it on CVS. Of course that frame throttling has merits on its own so we should eventually look into it. José Fonseca --- 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] Mach64: Error flushing vertex buffer: return = -11
On Sat, Jul 13, 2002 at 08:12:26PM -0400, Leif Delgass wrote:
On Sat, 13 Jul 2002, Leif Delgass wrote:
On Sun, 14 Jul 2002, José Fonseca wrote:
But the fact remains that the reads from GUI_STAT aren't reliable. I
wonder if the chip creats some transient values...
I wonder if always reading FIFO_STAT before GUI_STAT would make a
difference. The register reference says that the GUI_ACTIVE bit in
GUI_STAT would be set if the FIFO is not empty, but all the sample code I
recall looking at waits for idle by reading FIFO_STAT to make sure the
last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed
like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT.
I looked at the idle function in the DDX, and it only reads FIFO_STAT for
chips earlier than the VTB. It relies on the GUI_FIFO bits of GUI_STAT
for all Rage Pro chips and above, so it seems unlikely that reading
FIFO_STAT would make a difference.
Ok. Let's try the following then: call do_wait_for_idle when the engine
is given as idle on ring_tick. (This basically consists of checking
FIFO_STAT and then GUI_STAT again).
If the chip generates transient idles during operation then this
should catch it (or at least it should be really unlikely to miss it). If
the chip generates transient busys while in idle (which somehow seems more
unlikely) then the error will happen again.
Felix, please try the patch attached. I'm also gonna see if I can
reproduce it (by the look of its webpages, TORCS seems a nice way to
spend sometime ;-). I'll also redo the other extra safety check that
was failing before on my system to see if it goes away too.
José Fonseca
Index: mach64_drv.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.6.3.2.26.2.3
diff -u -r1.1.6.3.2.26.2.3 mach64_drv.h
--- mach64_drv.h10 Jul 2002 04:43:49 - 1.1.6.3.2.26.2.3
+++ mach64_drv.h14 Jul 2002 18:47:07 -
-523,6 +523,9
*/
int gui_active = MACH64_READ(MACH64_GUI_STAT) MACH64_GUI_ACTIVE;
+ if( !gui_active )
+ mach64_do_wait_for_idle( dev_priv );
+
ring-head_addr = MACH64_READ(MACH64_BM_GUI_TABLE) 0xfff0;
if ( gui_active ) {
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: mach64-0-0-5-branch)
On Sun, Jul 14, 2002 at 03:04:19PM -0400, Leif Delgass wrote: I assume you didn't mean to read GUI_STAT twice in a row here, right? 8-O Right... It's already on CVS. Thanks for spotting that out! José Fonseca --- 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] Mach64: Error flushing vertex buffer: return = -11
On Sun, Jul 14, 2002 at 10:09:44PM +0200, Felix Kühling wrote: On Sun, 14 Jul 2002 19:59:08 +0100 José Fonseca [EMAIL PROTECTED] wrote: [...] Felix, please try the patch attached. I'm also gonna see if I can Ok, I will apply it. But since the errors were very rare, it will take some time to be sure. Is there a way to make a patch that can print a I know... Have no hurry! log message when a transient idle is generated in a situation when it shoudn't and try to recover from it the way your patch does? Then if one sees such a message and the programme didn't crash one could be sure. As is now, not really.. unless one polls the value a little waiting for a transient value, but it's not very pratical. Just leave the patch in your tree - if nothing happens after some weeks of regular use is enough. Anyway, I think I can reproduce the problem on my testbox by letting the UT demo running alone some hours, so I hope to have a more definite answer soon. reproduce it (by the look of its webpages, TORCS seems a nice way to spend sometime ;-). I'll also redo the other extra safety check that was failing before on my system to see if it goes away too. Yeah, it's a nice programme, but I get only between 8 and 13 fps at 640x480. Hey! I didn't made the chip! I just helped on the drivers! ;-) José Fonseca --- 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] Mach64: Error flushing vertex buffer: return = -11
On Sat, Jul 13, 2002 at 11:24:44PM +0200, Felix Kühling wrote: Hi, I tried another game: Torcs. Occasionally (about once in 1 or 2 hours) it crashes with Error flushing vertex buffer: return = -11. This is the corresponding kernel log: Jul 13 23:04:30 viking kernel: [drm:mach64_freelist_get] *ERROR* Empty ring with non-idle engine! Here it says the engine was idle [...] Jul 13 23:04:30 viking kernel: [drm] 0x0051e310: 0x007ffe48 0xd00cc000 0x4048 0x (head) (tail) ... but the engine here seems to be idle... [...] Jul 13 23:04:30 viking kernel: [drm]GUI_STAT = 0x01800100 ^ ... and here is the confirmation! I don't know how this can be but I already had to override another safety check like this one because of the same problem. The reads are made using the kernel 'readl' macro, which deals with the compiler ordering, and the memory barriers. Since it's a read there isn't caching on the PCI bus. But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... [...] I can restart torcs after that without problems. Maybe other programmes have the same problem but I didn't test them that thoroughly ;) BTW, I'm also trying to figure out a problem reported by David Willmore is always reproducible on gltestperf, which seems to happens due to excess rate of tris/sec. José Fonseca --- 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] My experiance with DRI and gcc-3.0(.4)
On Thu, Jul 11, 2002 at 11:58:56PM -0700, Mike Mestnik wrote: The install.sh, included with the snapshots,(and make -f Makefile.linux) has allays built modules that insmod fine, even print every thing and rmmod, but they don't let X setunique. getunique worked fine. The error I get from an strace is no access, when calling the setunique ioctl. If I build the kernel using make-kpkg(that really only calles make modules) every thing works fine, I have to mv Makefile.kernel Makefile and I rm Imakefile Makefile.linux. Could this be your distribution applies some patch? When running make -f Makefile.linux it has $(cc) that runes cc, a link to gcc(V2.95.4). When running make-kpkg I'm using the New and Improved(it's been broken, and re-fixed) gcc-3.0(V3.0.4) so I put a line CC = gcc-3.0 in my Makefile.linux (added -O3 -march=athlon, removed -g) and made radeon.o, and it works. So, if I understood correctly, you need some way to control which gcc is used on the module compilation. If you want I can add some features to install.sh, command line params for all options -y for no questions ect. At present I can export CC, but I'l tweak my Makefile.sh from now on. That would be really great! Especially if with a --help option. Also make World will crash if I try to use gcc 3.0. Although I haven't done again after the bsd-branch merge I already compiled the mach64 branch with gcc-3.1 without problems. One can get into problems if one compiles modules with a different versions than the rest. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] My experiance with DRI and gcc-3.0(.4)
On Fri, Jul 12, 2002 at 11:21:29AM +0200, Marc Poulhiès wrote: hi, as you are talking about install.sh, i find a little problem when using it for the first time. When you dont have a kernel module installed before the first run of install.sh, the modprobe fails...a simple depmod -a then the modprobe fixes this... I was thinking that maybe this depmod -a should be included in the script. Is this a bad idea? No, it's a good idea alright, and I've just add '/sbin/depmod -a' to the install.sh script after installing/restoring the kernel modules. The next snapshots will have it. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: multi texture crash with after last update
On Fri, Jul 12, 2002 at 04:28:25AM +0200, Felix Kühling wrote: Hi, just updated after reading José's mail about the MACH64_NATIVE_VTXMFT and tried running some apps. q3demo and quake2 crashed with multi textures enabled: q3demo.x86: mach64_tris.c:518: mach64_draw_triangle: Assertion `vb == vbchk' failed. I found the problem in the COPY_VERTEX macro. The movsl instruction doesn't decrement %ecx when there is no rep prefix, so you have to decrease afterwards. Here's the fix: [...] It's now on CVS. I though that the %ecx decrement was already handled by the 'movsl' instruction and that the 'rep' prefix just added the conditional jump... Thanks. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: multi texture crash with after last update
On Fri, Jul 12, 2002 at 02:01:53PM -0600, Keith Whitwell wrote: Felix Kühling wrote: I got also a bit worried about using string instructions without clearing the direction flag. Is there any convention that prevents an application from setting the direction flag. If not, it might happen that esi and edi are decremented. On Fri, 12 Jul 2002 11:51:13 +0100 José Fonseca [EMAIL PROTECTED] wrote: [...] I though that the %ecx decrement was already handled by the 'movsl' instruction and that the 'rep' prefix just added the conditional jump... I missed the start of this... Is this something that should be fixed in the other drivers as well? The bug that Felix found first is specific of Mach64, on a x86 specific macro equivalent to the COPY_DWORDS existing in the other drivers, in the _tris.c file. But his later statement about clearing the direction flag regards every card that uses the 'rep; movsl' assembly instructions, such as in the COPY_DWORDS macro. This seems to be a tricky issue though which has been discussed in the linux kernel sometimes already: http://marc.theaimsgroup.com/?l=linux-kernelm=94388449615903w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=94371268003189w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=88995996331639w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=88981148900284w=2 My understanding of above is that althought issuing 'cld' is somewhat costy, we _can't_ assume that the direction flag is clear, so we need to issue it at least once in each subroutine where the COPY_DWORDS macro is used, and after calling any foreign code on that subroutines. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Fri, Jul 12, 2002 at 03:55:02PM -0400, Leif Delgass wrote: [...] Well, I added these offsets: SUBPIXEL_X 0.0125 SUBPIXEL_Y 0.15 ...and that's enough to make every glean test pass except polygonOffset (and texEnv, but that one's due to non-conformant hardware). However, I still see gaps in e.g. the Mesa tunnel demo and the lament xscreensaver hack (and probably lots of other places). The lines in Allen's stipple test now always overlap exactly. Jose, I think your changes reduced the offset necessary, but it does need a small offset to pass the tests. Actually I think the line tests start working at a smaller offset than some of the other tests. I found it strange that it requires such values of offset, especially the 0.15. Could it be that we are doing the rounding wrong somewhere? I checked in some other changes as well, one of which was to put the primitive type defines in the drm header and common header. We have the vertsize in the SAREA, and between that and the primitive list, I think the drm should be able to figure out how to add commands to the vertex buffers. As you say, we can use send fewer vertices to the card by implementing primitive strips. I just made the defines mirror the GL primitive defines, but we could reduce them to just the ones we'll implement. One other thing: I noticed you were supporting line/point size in the new primitive functions, so I removed the code from mach64_context.c that was overwriting the Mesa defaults with a max size/width of 1. However, for large, unaliased points, we need to have points implemented as quads instead of triangles (try drawing a 10 pixel point and compare it to indirect). It's being done as a quad, so there must be a bug somewhere. At the time I didn't manage to test bigger points - now I know why! Oh, I also fixed polygon stippling to work as a software fallback. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Microsoft IP claims over OpenGL
Microsoft has been progressively claiming IP ownership of parts of the OpenGL API. (See http://news.zdnet.co.uk/story/0,,t269-s2118968,00.html) Although the parts they claim are things like vertex programming - features that aren't present in older cards such as Mach64 -, it seems obvious that these are features very important in the current and next generation of graphics cards. I would like to know your opinion about the influence this may have for the DRI and Mesa3D projects in particular, and for the OpenGL API in general. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Thu, Jul 11, 2002 at 06:34:40PM -0400, Leif Delgass wrote: On Thu, 11 Jul 2002, Brian Paul wrote: Leif Delgass wrote: I just discovered that the glean failures in blendFunc, logicOp, orthoPosRandTris, orthoPosRandRects, orthoPosTinyQuads, and polygonOffset are the result of an off-by-one error in the y screen coordinates. If I add one to the Y coordinate in the viewport conversion to screen coordinates, these tests all pass. However, it breaks the scissor test and the orthoPos[H,V]Lines and orthoPosPoints tests still fail (which could be a result of the implementation of points and lines with triangles/quads). It also seems to leave a row of pixels at the top of the window which isn't drawn on, but is cleared. The stipple test still has the same problem because lines still aren't conformant. I'm still a little puzzled as to where the off-by-one error actually originates, but this narrows down the problem a lot. The Y-coordinate error may be less than one. Most of the DRI hardware drivers need X/Y coordinates biased by a small amount in order to make hardware rasterization and software rasterization coincide. So, something like 0.75 or 0.875 might work better. Yeah, I just realized that. I'm playing with X and Y subpixel offsets to try and find a combination that fixes the most problems without breaking tests that worked. :) Leif, note that at least with the vertices generated by mach64_translate_vertex (i.e., converted from the VB into SWVertex during a fallback) in the new template they will already be rounded off into the chip precision, so that can make a difference already. You'll perhaps want look into that as well. Note also that the native vertex format stuff is finished, and is now enabled by default in the CVS. The old behavior is still there and one can change the MACH64_NATIVE_VTXMFT macro in mach64_context.h to enable it but that code won't stay much longer - because the new code is much more optimized and has some fixes which I didn't bother to propagate to the old code, and also to make place for new optimizations (such as primitive strips and so on). --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Wed, Jul 10, 2002 at 10:00:38AM -0400, Allen Barnett wrote: Hi (José and Leif), I'm testing the Mach64 driver on my laptop, which uses a Rage Mobility P/M AGP 2x (rev 64). I'm using the binary snapshot from 2002/7/8.The render/version string is: Mesa DRI Mach64 20020227 [Rage Pro] AGP 2x x86/MMX/SSE 1.2 Mesa 4.0.3 You guys have done some really outstanding work on this driver. I almost don't want to complain, but here goes. I have a couple of problems with [...] I really appreciate the work you guys have put into this driver. Keep up the good work. Allen, thanks for the detailed report of the problems. It's gonna take a little time (at least for me) to reproduce all this (I have been a little busy lately and I still have some changes I want to do on the driver before I can look into it) but it will be done. Note also that there are some OpenGL conformance issues which have been neglected so far, and which can be the cause behind of some of these problems. At any rate your cases will help to determine that. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] IRC Meetings ML notification
First I would like to apoligize for missing the last two IRC meetings. There was no noble reason whatsoever - I completely forgot it. Although this is no excuse, I would like to request that a notification message is always sent to this mailing list - as it was often done -, even if it's sent just on the meeting start. Anyway, I'm going to see next week I don't forget it again (and with some luck even send the notification myself!) José Fonseca --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] BZFlag causes X lockup on mach64-0-0-5
On Mon, Jul 08, 2002 at 11:55:55AM +0200, Felix Kühling wrote: Hi, I just read Davids mail about bzflag performance on mach64. Incidentally last night I tried bzflag for the first time on mach64 and it froze the X server reproducibly (tried it twice) just after starting bzflag. By now I found out that it's related to switching the screen resoultion. Without switching it works just fine. When I have bzflag switch to 640x480 it fails. I updated just before so I guess I have the latest version of the branch. bzflag version is: BZFlag client, version 1.7e4 protocol 1.7e Symptoms: I start bzflag. It changes resolution to 640x480. For a fraction of a second I see the frame of the status window flashing on the screen. Then it goes black and IIRC the mouse pointer freezes. Here is the kernel log: [...] Jul 8 02:23:48 viking kernel: [drm] 0x0051c060: 0x007ffe48 0xd0018000 0xc000 0x (head) ^^ A 0-length buffer was commited to the ring. This is a situation that had never been experienced and it wasn't known to cause problems, so it isn't checked by the current code. A fix should be straightforward since these buffers can just be dismissed. I'll get back to you when I've done it so that you can test again. Jul 8 02:23:48 viking kernel: [drm] 0x0051c070: 0x 0x 0x 0x (tail) [...] This was repeated in about 2 sec intervals until I rebooted. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Duplicate/redundant DRM files in trunk (Was: Radeon drivers don't install...)
I've determined what was breaking the binary snapshots DRM: there are several files in .../linux/drm/kernel which are later symlinked from .../shared/drm/kernel. The current script first copies the files from the 'shared', and then from the 'linux', therefore effectively overwritting files with previous versions. I could fix the scripts but this wouldn't solve the real problem of redundant files. So is it safe to delete these deprecated files: mga.h mga_dma.c mga_drm.h mga_drv.h mga_state.c mga_ucode.h mga_warp.c r128.h r128_cce.c r128_drm.h r128_drv.h r128_state.c radeon.h radeon_cp.c radeon_drm.h radeon_drv.h radeon_state.c from .../linux/drm/kernel? José Fonseca On Mon, Jul 08, 2002 at 12:09:01AM +0100, José Fonseca wrote: This is the same problem I got when testing the new snapshots (after the bsd branch merge), on a similar system (RHL 7.3 - where the snapshots were built actually). I'm going to investigate if this is a problem in the CVS itself or just in snapshots. José Fonseca On Mon, Jul 08, 2002 at 12:10:32AM +0200, [EMAIL PROTECTED] wrote: ok seemed to be a problem with my kernel sources. i reinstalled them, but now i get this error: cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -DCONFIG_AGP -DCONFIG_AGP_MODULE -DCONFIG_DRM_SIS -DMODVERSIONS -include /lib/modules/2.4.18-3/build/include/linux/modversions.h -DEXPORT_SYMTAB -I/lib/modules/2.4.18-3/build/include -c radeon_drv.c -o radeon_drv.o In file included from /lib/modules/2.4.18-3/build/include/linux/pagemap.h:16, from /lib/modules/2.4.18-3/build/include/linux/locks.h:8, from /lib/modules/2.4.18-3/build/include/linux/devfs_fs_kernel.h:6, from /lib/modules/2.4.18-3/build/include/linux/miscdevice.h:4, from drmP.h:45, from radeon_drv.c:32: /lib/modules/2.4.18-3/build/include/linux/highmem.h: In function `bh_kmap': /lib/modules/2.4.18-3/build/include/linux/highmem.h:20: warning: pointer of type `void *' used in arithmetic In file included from radeon_drv.c:32: drmP.h: At top level: drmP.h:170: warning: static declaration for `vmalloc_to_page_Rb9d6adc0' follows non-static In file included from radeon_drv.c:44: drm_drv.h:234: parse error before `DRIVER_AUTHOR' drm_drv.h:235: parse error before `DRIVER_DESC' drm_drv.h: In function `drm_init': drm_drv.h:580: `DRIVER_NAME' undeclared (first use in this function) drm_drv.h:580: (Each undeclared identifier is reported only once drm_drv.h:580: for each function it appears in.) drm_drv.h:613: `DRIVER_MAJOR' undeclared (first use in this function) drm_drv.h:613: `DRIVER_MINOR' undeclared (first use in this function) drm_drv.h:613: `DRIVER_PATCHLEVEL' undeclared (first use in this function) drm_drv.h:613: `DRIVER_DATE' undeclared (first use in this function) drm_drv.h: In function `radeon_version': drm_drv.h:700: `DRIVER_MAJOR' undeclared (first use in this function) drm_drv.h:701: `DRIVER_MINOR' undeclared (first use in this function) drm_drv.h:702: `DRIVER_PATCHLEVEL' undeclared (first use in this function) drm_drv.h:704: `DRIVER_NAME' undeclared (first use in this function) drm_drv.h:705: `DRIVER_DATE' undeclared (first use in this function) drm_drv.h:706: `DRIVER_DESC' undeclared (first use in this function) make: *** [radeon_drv.o] Fehler 1 --- This sf.net email is sponsored by:ThinkGeek We have stuff for geeks like you. http://thinkgeek.com/sf ___ Dri-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-users --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Duplicate/redundant DRM files in trunk (Was: Radeon drivers don't install...)
On Mon, Jul 08, 2002 at 11:16:55PM +0200, Michel Dänzer wrote: On Mon, 2002-07-08 at 21:49, José Fonseca wrote: I've determined what was breaking the binary snapshots DRM: there are several files in .../linux/drm/kernel which are later symlinked from .../shared/drm/kernel. The current script first copies the files from the 'shared', and then from the 'linux', therefore effectively overwritting files with previous versions. I could fix the scripts but this wouldn't solve the real problem of redundant files. So is it safe to delete these deprecated files: mga.h mga_dma.c mga_drm.h mga_drv.h mga_state.c mga_ucode.h mga_warp.c r128.h r128_cce.c r128_drm.h r128_drv.h r128_state.c radeon.h radeon_cp.c radeon_drm.h radeon_drv.h radeon_state.c from .../linux/drm/kernel? I'm seeing something else here, at least the radeon files are gone from the trunk, I have no reason to believe the others aren't. No the mga_files are duplicate, so I guess that we both made the same mistake of taking the part for the whole... --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. 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, Jul 05, 2002 at 02:23:49PM +0100, Alan Hourihane wrote: On Fri, Jul 05, 2002 at 01:51:50PM +0100, José Fonseca wrote: [...] Yes, that seems cleaner, since I won't have to bother eliminating the compiled stuff away. Yep. What does 'uname -s' return on NetBSD and FreeBSD ? On the FreeBSD of SF compiler farm it return 'FreeBSD'. Just massage the scripts for these cases and copy from the bsd directory instead. All done. Ok. I've updated the scripts for both things, but I got a lot of errors (missing defines etc) when trying to build the DRM on a machine, and only the most simple DRM got built (tdfx and glint if I'm not mistaken). Is there any missing or did I do something wrong? I also tried to run the script on CF FreeBSD server but it seems that I've been using some GNU specific features of some programs (make -C failed) so it will take a little more massages. I also don't know how the BSD kernel modules(?) works (and the scripts neither!) I don't know what's the demand for BSD binary snapshots, but if someone more keen on BSD wants to give it a try take a look on the http://dri.sf.net/snapshots/scripts/README for an updated description and information on how to use this scripts. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Argggg so close with S3 Virge/MX, yet so far...
On Sat, Jul 06, 2002 at 01:38:06PM -0500, David Willmore wrote: Well, I've been waiting what seems like forever for a driver for my laptop and now there is one! What a happy day! One problem, it's an older Compaq laptop and uses a propriatary chipset (and AGP bridge) so no AGPGART. *do-oh* Ouch! :O Noone happens to have a AGPGART for it hiding somewhere, do they? Concacts with Compaq they could twig? This laptop was retied over a year ago (by compaq support), so they shouldn't be all to concerned that any competetive information escape by coughing up the specs for it, one would think. Compaq now belongs to HP which as been a big linux supporter lately. On the other hand that can mean nothing. Suggestions, anyone? I sent a simple message off to support@ compaq.com. We'll see if that nets me anything, but I'm not holding my breath. What about adding PCI support to the drivers? It shouldn't be very difficult. I don't know how deep is the complexity of a agp bridge, nor the legal implications this, but in the lack of interest from the vendor, reverse engineering the Window drivers might be feasible last resort option. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Missing () in Mesa macros
Ok. I have no doubt this one is definitvely a bug.
() surrounding the macro arguments are missing in several macros of mmath.h, so they
break when the arguments contain operators with lower precedence. Although the
attached patch fixes all macros I saw, the most worrying are the UBYTE/FLOAT macros.
José Fonseca
Index: mmath.h
===
RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/mmath.h,v
retrieving revision 1.24.12.1
diff -u -r1.24.12.1 mmath.h
--- mmath.h 27 Jun 2002 22:03:50 - 1.24.12.1
+++ mmath.h 4 Jul 2002 12:24:44 -
-171,17 +171,17
GLfloat len = LEN_SQUARED_3FV(V); \
if (len) { \
len = (GLfloat) (1.0 / GL_SQRT(len));\
- V[0] = (GLfloat) (V[0] * len); \
- V[1] = (GLfloat) (V[1] * len); \
- V[2] = (GLfloat) (V[2] * len); \
+ (V)[0] = (GLfloat) ((V)[0] * len); \
+ (V)[1] = (GLfloat) ((V)[1] * len); \
+ (V)[2] = (GLfloat) ((V)[2] * len); \
} \
} while(0)
-#define LEN_3FV( V ) (GL_SQRT(V[0]*V[0]+V[1]*V[1]+V[2]*V[2]))
-#define LEN_2FV( V ) (GL_SQRT(V[0]*V[0]+V[1]*V[1]))
+#define LEN_3FV( V ) (GL_SQRT((V)[0]*(V)[0]+(V)[1]*(V)[1]+(V)[2]*(V)[2]))
+#define LEN_2FV( V ) (GL_SQRT((V)[0]*(V)[0]+(V)[1]*(V)[1]))
-#define LEN_SQUARED_3FV( V ) (V[0]*V[0]+V[1]*V[1]+V[2]*V[2])
-#define LEN_SQUARED_2FV( V ) (V[0]*V[0]+V[1]*V[1])
+#define LEN_SQUARED_3FV( V ) ((V)[0]*(V)[0]+(V)[1]*(V)[1]+(V)[2]*(V)[2])
+#define LEN_SQUARED_2FV( V ) ((V)[0]*(V)[0]+(V)[1]*(V)[1])
/*
-398,8 +398,8
#define UNCLAMPED_FLOAT_TO_UBYTE(b, f) \
do { \
union { GLfloat r; GLuint i; } __tmp; \
- __tmp.r = f;\
- b = ((__tmp.i = IEEE_0996) \
+ __tmp.r = (f); \
+ b = ((__tmp.i = IEEE_0996) \
? ((GLint)__tmp.i 0) ? (GLubyte)0 : (GLubyte)255 \
: (__tmp.r = __tmp.r*(255.0F/256.0F) + 32768.0F,\
(GLubyte)__tmp.i)); \
-417,7 +417,7
b = ((GLubyte) IROUND(CLAMP(f, 0.0F, 1.0F) * 255.0F))
#define CLAMPED_FLOAT_TO_UBYTE(b, f) \
- b = ((GLubyte) IROUND(f * 255.0F))
+ b = ((GLubyte) IROUND((f) * 255.0F))
#define COPY_FLOAT( dst, src ) (dst) = (src)
-431,10 +431,10
/* Convert GLubyte in [0,255] to GLfloat in [0.0,1.0] */
extern float _mesa_ubyte_to_float_color_tab[256];
-#define UBYTE_TO_FLOAT(u) _mesa_ubyte_to_float_color_tab[(unsigned int)u]
+#define UBYTE_TO_FLOAT(u) _mesa_ubyte_to_float_color_tab[(unsigned int)(u)]
/* Convert GLfloat in [0.0,1.0] to GLubyte in [0,255] */
-#define FLOAT_TO_UBYTE(X) ((GLubyte) (GLint) (((X)) * 255.0F))
+#define FLOAT_TO_UBYTE(X) ((GLubyte) (GLint) ((X) * 255.0F))
/* Convert GLbyte in [-128,127] to GLfloat in [-1.0,1.0] */
-488,7 +488,7
#define SHORT_TO_USHORT(s) ((s) 0 ? 0 : ((GLushort) (((s) * 65535 / 32767
#define INT_TO_USHORT(i) ((i) 0 ? 0 : ((GLushort) ((i) 15)))
#define UINT_TO_USHORT(i) ((i) 0 ? 0 : ((GLushort) ((i) 16)))
-#define UNCLAMPED_FLOAT_TO_USHORT(us, f) us = (GLushort) (f * 65535.0F)
+#define UNCLAMPED_FLOAT_TO_USHORT(us, f) us = (GLushort) ((f) * 65535.0F)
-516,48 +516,48
} while (0)
#define INTERP_UI( t, dstui, outui, inui ) \
- dstui = (GLuint) (GLint) LINTERP( t, (GLfloat) outui, (GLfloat) inui )
+ dstui = (GLuint) (GLint) LINTERP( t, (GLfloat) (outui), (GLfloat) (inui) )
#define INTERP_F( t, dstf, outf, inf ) \
dstf = LINTERP( t, outf, inf )
#define INTERP_4F( t, dst, out, in ) \
do { \
- dst[0] = LINTERP( t, out[0], in[0] ); \
- dst[1] = LINTERP( t, out[1], in[1] ); \
- dst[2] = LINTERP( t, out[2], in[2] ); \
- dst[3] = LINTERP( t, out[3], in[3] ); \
+ (dst)[0] = LINTERP( t, (out)[0], (in)[0] ); \
+ (dst)[1] = LINTERP( t, (out)[1], (in)[1] ); \
+ (dst)[2] = LINTERP( t, (out)[2], (in)[2] ); \
+ (dst)[3] = LINTERP( t, (out)[3], (in)[3] ); \
} while (0)
#define INTERP_3F( t, dst, out, in ) \
do { \
- dst[0] = LINTERP( t, out[0], in[0] ); \
- dst[1] = LINTERP( t, out[1], in[1] ); \
- dst[2] = LINTERP( t, out[2], in[2] ); \
+ (dst)[0] = LINTERP( t, (out)[0], (in)[0] ); \
+ (dst)[1] = LINTERP( t, (out)[1], (in)[1] ); \
+ (dst)[2] = LINTERP( t, (out)[2], (in)[2] ); \
} while (0)
#define INTERP_4CHAN( t, dst, out, in )\
do
Re: [Dri-devel] dlabs pm3/2 gamma+pm3 support (1) (patch #577344)
On Thu, Jul 04, 2002 at 03:23:56PM +0200, Sven Luther wrote: [...] BTW, is it normal that i cannot buid the DRI server out of CVS when changing the ProjectRoot ? It seems to try building stuff with the installed libraries and thus fail if ProjectRoot don't point to installed libraries. Yes, it's normal because the DRI CVS doesn't contain the full XFree86 code. If you want a different ProjectRoot then you must first create that directory and then `lndir` from the directory where you have X installed (usually /usr/X11R6) to that one. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-20020704: gltestperf lockup on Zsmooth triangles
On Thu, Jul 04, 2002 at 12:58:13PM -0500, David Willmore wrote: I had a lockup on an older version of the mach64 DRI driver, so I thought I'd retest with a newer one. gltestperf locks up (no response to keyboard, but mouse still moves--it locked up as well in the older version) on the ZSmooth Triangles size:480 test. Not immediately, but it locks up after the second set of triangles and maybe early into the third. Thanks for the report. Here's the relivant stuff from the kernel messages: [...] There may have been more, but it didn't make it to the log. Any more logging/system configuration info needed? I'm going to see if I can reproduce it when I finish the current round of changes. Thanks for the driver! :) It doesn't die under normal use-- which doesn't involve much 3D, yet. It only seems to die when I poke it like this--so I don't do this except when I want it to die. ;) Patient: Doctor, it hurst when I do this. Dr. Well, then don't do that. :-) Cheers, David José Fonseca --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 native template PPC fp format
On Mon, Jul 01, 2002 at 07:34:31AM +0100, Keith Whitwell wrote: José Fonseca wrote: Preliminary support Mach64 native vertex buffer template was added to CVS. The measures on the increase of performance in doing this are rather marginal unfortunately: I got an increase of 800 poly/sec (over 35400) on ipers mesademo on the previous mach64-0-0-4-branch, but on the new branch the results flutuate too much to get an accurate measure. ... isosurf is probably a better demo for profiling vertex efficiency. Indeed! Here are the results of the 'b' and 'B' benchmark with the default settings before: Benchmarking... Result: triangles/sec: 205098 fps: 28.5771 Benchmarking... Result: triangles/sec: 204282 fps: 28.4634 and after: Benchmarking... Result: triangles/sec: 277690 fps: 38.6917 Benchmarking... Result: triangles/sec: 275819 fps: 38.4309 so the difference isn't that marginal as I thought. Thanks for the tip Keith. José Fonseca --- 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: [Mesa3d-dev] Re-occurrence of macros arguments within its definition in Mesa headers
On Mon, Jul 01, 2002 at 07:43:40AM +0100, Keith Whitwell wrote: José Fonseca wrote: [...] I think this is a bug in Mesa. First because a macro should generally behave as an ordinary function, unless there is a very special reason not to do so. Hmm, not really, this is something people are supposed to understand about macros generally - it's one of the classic C programming mistakes to assume that macros evaluate their arguments exactly once. I was aware of that common pitfall, but I though that it was common [and good] practice to define the macros to avoid exactly this pitfall. Imagine if in the linux kernel, for example, macros such as cpu_to_le32 didn't followed that convention. Of course that many times the solution is to rewrite the macro as a inline function. Second because this relies on compiler optimization to remove the redundancy of calculating OUT twice. Although I haven't check what is the exact assembler output of gcc, the call of INTERP_F with calculations in its arguments is used on the default vertex template, hence used across all drivers. See src/tnl_dd/t_dd_vbtmp.h:669: You should check the output. Gcc does lots of common-subexpression-elimination (cse). I'd be suprised if it didn't find this one. You're right in respect with gcc. The following code in t_dd_vbtmp.h INTERP_F( t, dst-v.u0, out-v.u0 * qout, in-v.u0 * qin ); compiles into fld %st(1) fld %st(1) fxch%st(1) fmuls 24(%ebx) fxch%st(1) fmuls 24(%edx) fsub%st(1), %st fmul%st(4), %st faddp %st, %st(1) movl-36(%ebp), %eax fstps 24(%eax) that is, three fp multiplications in total, so OUT isn't recalculated (as that would result in four). José Fonseca --- 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] Mach64 native template PPC fp format
On Mon, Jul 01, 2002 at 11:37:59AM +0100, Keith Whitwell wrote: José Fonseca wrote: [...] Indeed! Here are the results of the 'b' and 'B' benchmark with the default settings before: Benchmarking... Result: triangles/sec: 205098 fps: 28.5771 Benchmarking... Result: triangles/sec: 204282 fps: 28.4634 and after: Benchmarking... Result: triangles/sec: 277690 fps: 38.6917 Benchmarking... Result: triangles/sec: 275819 fps: 38.4309 so the difference isn't that marginal as I thought. Indeed. That looks like a pretty good speedup... The Mach64 format is quite different from the D3D. For example the X,Y and Z coordinates are in fixed point and not in floating point. By making all the conversions on the vertex buffer template these operations are factored out in reused vertices. And in the 3D model used in the isosurf demo (a triangular mesh) I would say that every vertex is roughly used about 3-4 times, hence the impact. I also removed an extra fp multiplication for backface culling by using signbit() instead. José Fonseca --- 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: [Mesa3d-dev] Re-occurrence of macros arguments within its definition in Mesa headers
On Mon, Jul 01, 2002 at 06:32:18AM -0600, Brian Paul wrote: Keith Whitwell wrote: José Fonseca wrote: [...] I suggest two things: 1. Put a comment where INTERP_F is defined, noting that some parameters are evaluated twice. I'll do this. 2. Change this: INTERP_F( t, (*dst++).f, (*out++).f * qout, (*in++).f * qin ); into: INTERP_F( t, (*dst).f, (*out).f * qout, (*in).f * qin ); dst++; out++; in++; Thanks Brian. This is what've done as soon as I realized that there was no advantage whatsoever in doing as before: the only machine instructions that can make use of pointers post-incrementing I know are the x86's MOVS* instructions, but they couldn't be applied here since this isn't a memmory copy. Don't leave this sort of thing to chance. This is the kind of thing that a person could waste many hours debugging. Yeah. When I code it I reminded of the eventuality of this could happen but at the time I just want to get it written. It took me quite a while to figure this until I noticed that the precense of textures affected the rgba and specular colors! José Fonseca --- 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] Mach64 native template PPC fp format
Preliminary support Mach64 native vertex buffer template was added to CVS. The measures on the increase of performance in doing this are rather marginal unfortunately: I got an increase of 800 poly/sec (over 35400) on ipers mesademo on the previous mach64-0-0-4-branch, but on the new branch the results flutuate too much to get an accurate measure. Nevertheless this simplifies enormously the code in _tris.c and will facilitate future implementation of triangle and quad strips. This is still disabled by default since some things are still missing. One of them is support for bigendian architectures, and therefore a doubt that I came about: is it necessary to swap bytes when writting a IEEE fp number on a bigendian machine, or is the IEEE fp number stored independently of that? José Fonseca --- 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: mach64-0-0-5-branch)
On Sun, Jun 30, 2002 at 08:01:58PM -0400, Leif Delgass wrote: This is just temporary transitional code, right? Isn't the idea to add I hope not... the commands in the drm when copying to a private buffer? That way we .. as I hope be able to use this code in the DRM. don't need to verify the commands and the Mesa driver can just copy the vertex data unchanged into the buffer (or have Mesa use DMA buffers directly). Yes. At that time the COPY_VERTEX call will be replaced by the straightforward COPY_DWORDS. The complexity in COPY_VERTEX will be shifted to the DRM. That code will be in the inner loop so this assembly optimization will be quite handy then. On Sun, 30 Jun 2002, Jos? R. Fonseca wrote: Log message: x86 implementation of the COPY_VERTEX macro. Factorization of a variable out of the ADRINDEX macro argument allowing the compiler precalculate the macro result. Both of these things appear to had contribute to a further improvement of the poly/sec in ipers. José Fonseca --- 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 kernel interfaces
On Mon, Jun 24, 2002 at 10:08:42AM -0700, Ian Romanick wrote: On Tue, Jun 18, 2002 at 12:09:02AM +0100, José Fonseca wrote: On 2002.06.17 23:19 Keith Whitwell wrote: We could overcome the GLX difficulties in the same way we do now in libGL with the direct rendering. But I still don't understand why vertex arrays would be such a problem over shared memory. Aren't they basically just readed and transformed into Mesa's vertex buffers? Could't the OpenGL drivers just read these vertex arrays directly of the client memory space from the X process? There's no indication of the 'top' of the vertex buffer, so you don't know how much to transfer. There's no semantics to tell you whether the vertex buffer contents have changed, so you don't know how often to transfer. But why even transfer in the first place? Why not simply map parts of the vertex buffers into the X memory space as they are needed, or is there any impossibility on the Linux architecture to do that? This is an old message, but I didn't see a reply to this point. The reason is that the indirect rendering path they've been talking about is the *same* one used by remote clients. I know it's the same path of remote clients... A client running on a different box can't directly map anything, so the indirect clients on the same box (as the X server) have to follow the same rules. Not really. That what's extensions like MIT-Shm exist for. Anyway, all this is very academic until someone really starts doing some thing on this but - as Jens said before -, there is no funding for that. That's why I already had planned to do something myself in the future (somewhere in the next year); initially just integrate the Mesa drivers into X/GLcore and depart from there. José Fonseca --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: S3 VIRGE DRI in CVS now
On Thu, Jun 27, 2002 at 11:54:53AM +0200, Massimiliano Lingua wrote: [...] 3) Did you set backbuffer size and texsize in XF86Config like I suggested in the README? Max, where can I find that README? I would like to put it in the same place as the binary snapshots. José Fonseca --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk merge in mach64-0-0-5-branch is done
On Thu, Jun 27, 2002 at 04:35:16PM -0600, Brian Paul wrote: [...] Just curious: do you guys have a plan for moving the mach64 code into the trunk? Are there any major issues that need to be resolved first? In my perspective the major issues missing are: 1. Make sure the new DMA model works well in all configurations (at this moment it seems that only PPC remains with problems) 2. Vertex buffer template custumized to the Mach64 hardware format (this isn't major but I wanted to work this first before addressing security, because it can change radically how we do it, and I'm finishing it). 3. The security - this is the real issue that must be addressed before a merge with the trunk (and therefore, being ready for a release). BTW, I took a stab at updating the http://dri.sourceforge.net/doc/cvs.html page which lists and describes the current CVS branches. The mach64 branch is described as: This is the branch for the ATI Rage Pro driver development. The work is unfunded and is only just beginning, so a working driver is still a long way off. Please do not ask when it will be complete. This branch also contains some DRM architectural changes, designed to make writing new drivers easier and remove significant amounts of duplicated code. Maybe this should be updated. Yep. This is way old (I think it refers to mach64-0-0-1-branch). José Fonseca --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Failure to build the s3virge-0-0-1-branch
Last night the script tried to build the s3virge binary snapshot for the first time, but it failed when building a file related with the i830 driver: gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -fno-merge-constants -I../../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../../../../../programs/Xserver/include -I../../../../../../../exports/include/X11 -I../../../../../../../include/extensions -I../.. -Ikernel -I../../../../../../.. -I../../../../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -c xf86drmI830.c xf86drmI830.c: In function `drmI830CleanupDma': xf86drmI830.c:55: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:55: (Each undeclared identifier is reported only once xf86drmI830.c:55: for each function it appears in.) xf86drmI830.c:55: parse error before `init' xf86drmI830.c:57: `init' undeclared (first use in this function) xf86drmI830.c:60: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) xf86drmI830.c: In function `drmI830InitDma': xf86drmI830.c:69: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:69: parse error before `init' xf86drmI830.c:71: `init' undeclared (first use in this function) xf86drmI830.c:91: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) make[8]: *** [xf86drmI830.o] Error 1 rm -f xf86drmS3V.o And the packaging script fails since it can't find libdrm.a. Max, is there any file related to i830 missing or outdated in the s3virge branch? Or perhaps the i830 driver should be disabled on this branch. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote: [...] Jose, I think now would be a good time for us to merge the trunk into a new Mach64 branch. Brian released Mesa 4.0.3 and the trunk looks like it's been updated, and we need to convert to drmCommand as well. Plus there are ppc fixes that should help with our current texture problems. Okidoki. Feel free to start the merge whenever you want - before I join you I just want to make the changes in the DRM I promised to the PPC guys to debug the problems they've been experienced. I think that's a good idea to bump the branch number too. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Merging trunk changes into mach64 branch
On Wed, Jun 26, 2002 at 01:52:00PM -0400, Leif Delgass wrote: On Wed, 26 Jun 2002, José Fonseca wrote: On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote: [...] Jose, I think now would be a good time for us to merge the trunk into a new Mach64 branch. Brian released Mesa 4.0.3 and the trunk looks like it's been updated, and we need to convert to drmCommand as well. Plus there are ppc fixes that should help with our current texture problems. Okidoki. Feel free to start the merge whenever you want - before I join you I just want to make the changes in the DRM I promised to the PPC guys to debug the problems they've been experienced. I think that's a good idea to bump the branch number too. It's been a while since I did a merge. I'm thinking I'll make the branch from the trunk (I'm checking out a fresh tree from the trunk now) and then merge in changes from mach64-0-0-4-branch once you've checked in anything you'd like to get in before the merge. Does that sound like the right way to do it? I was thinking this might be easier than merging the changes on the trunk into the branch since there's been a lot of activity on the trunk since our last branchpoint from it. Yep. That's it. Basically one needs to checkout the trunk, tag it with the new mach64-0-0-5-branch, and then merge from the old branch (by doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA, is adding the mach64 stuff to all Makefiles because the mach64 driver was never merged back into the trunk... José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Merging trunk changes into mach64 branch
On Wed, Jun 26, 2002 at 02:17:26PM -0400, Leif Delgass wrote: On Wed, 26 Jun 2002, José Fonseca wrote: [...] Yep. That's it. Basically one needs to checkout the trunk, tag it with the new mach64-0-0-5-branch, and then merge from the old branch (by doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA, is adding the mach64 stuff to all Makefiles because the mach64 driver was never merged back into the trunk... Wouldn't it be easier to do 'cvs update -j mach64-0-0-4-branch'? That should merge everthing from the branch (changes relative to the branchpoint on the trunk), and I'll just have to merge any conflicts/rejects by hand. Perhaps. What I suggested was what I've done the last time. I make no claim that is the best method since as you can see my CVS knowledge is that deep! ;-) On the other hand I could not see on the CVS manpage how the -j option would have the effect you described. Is just a matter of trying anyway. Perhaps you should try instead what is suggested on HOW TO MERGE THE TRUNK INTO YOUR BRANCH in http://dri.sf.net/doc/cvspolicy.txt . Alan, hint? (Or How have you just done now with the s3virge branch?) José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RE: Dri-devel S3 VIRGE DRI in CVS now
On Wed, Jun 26, 2002 at 08:51:18PM +0200, Massimiliano Lingua wrote: On Wed, 2002-06-26 at 16:48, José Fonseca wrote: Are the ProSavage docs you have enough to get a good start on Savage4? their 3D engine is nearly identical. Er, I forgot, I got Savage4 docs too from S3/VIA. I am definetly the luckiest coder on Earth ; ) Well, at least someone of us has. That's good enough for me! So on a Savage4 running my hack you will see just the same as me: monochrome (black), smeared triangles ; ( I am quite busy now (I have to pass this fucking law exam...), but if you are interested in the 2nd half of July I could send you a copy of my code + some comment (it should be very intuitive even without docs), so maybe you can guess what I am doing wrong. I would appreciate it. But have no hurry because of me, since only on the 26th of July I'll have access to my Savage4 card (when I return to Portugal in vacations), so only then I'll be able to test it myself. Nevertheless it would be nice to have whatever you have in CVS - as is - so that others can start playing with it. If you want just send me the parts and I'll do the integration with the CVS myself. But only if this isn't too much trouble for you now, of course. (I don't how big is what you have nor how fast is your internet connection). José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Wed, Jun 26, 2002 at 10:04:27AM -0700, Alan Hourihane wrote: o.k. it's builds now, max needs to check it runs o.k. I've tested and I still get errors when building it: gcc -c -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -I../. ./../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../extras/Mesa/src-I../../../../../ ../lib/GL/mesa/src/drv/common -I../../../../../../lib/GL/mesa/src/drv/s3v -I../../../../../../lib/GL/dri -I../../. ./../../../lib/GL/glx -I../../../../../../exports/include -I../../../../../../exports/include/GL -I../../. ./../../../programs/Xserver/GL/dri -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../ ../programs/Xserver/hw/xfree86/drivers/s3virge -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../ ../lib/GL/dri/drm -I../../../../../../lib/GL/include -I../../../../../../include -I../../../../../.. -I../../ ../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOU RCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -D GLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE _3DNOW_ASM -DUSE_SSE_ASM s3v_context.c In file included from s3v_context.c:5: s3v_context.h:215: parse error before `drm_s3v_sarea_t' s3v_context.h:215: warning: no semicolon at end of struct or union s3v_context.h:378: `Window' redeclared as different kind of symbol ../../../../../../exports/include/X11/X.h:101: previous declaration of `Window' s3v_context.h:403: parse error before `}' s3v_context.c: In function `s3vCreateContext': s3v_context.c:57: `drm_s3v_sarea_t' undeclared (first use in this function) s3v_context.c:57: (Each undeclared identifier is reported only once s3v_context.c:57: for each function it appears in.) s3v_context.c:57: `saPriv' undeclared (first use in this function) s3v_context.c:57: parse error before `)' s3v_context.c:62: dereferencing pointer to incomplete type ... And alot of similar errors after. Perhaps something was forgoten when commiting? José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Merging trunk changes into mach64 branch
On Wed, Jun 26, 2002 at 04:22:07PM -0400, Leif Delgass wrote: On Wed, 26 Jun 2002, Alan Hourihane wrote: On Wed, Jun 26, 2002 at 07:44:14PM +0100, José Fonseca wrote: Alan, hint? (Or How have you just done now with the s3virge branch?) cvs update -j HEAD and resolve the conflicts by hand. OK, I can do that. I guess it'll be about the same difficulty as merging the branch changes into the trunk code. Jose, do you have anything else you want to commit before I tag the new branch? I'm going to update my No. I just have the new vertex template stuff but I'm still working on it and it shouldn't be more difficult to commit directly to the new branch. mach64-0-0-4-branch tree and tag it to create the new mach64-0-0-5-branch. Then I'll merge in the trunk and start working on conflicts and the drmCommand changes. Ok. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Annouce: S3 Virge binary snapshots (Was: CVS Update: xc (branch: s3virge-0-0-1-branch))
On Wed, Jun 26, 2002 at 08:56:04PM +0100, Alan Hourihane wrote: On Wed, Jun 26, 2002 at 08:38:03PM +0100, José Fonseca wrote: On Wed, Jun 26, 2002 at 10:04:27AM -0700, Alan Hourihane wrote: o.k. it's builds now, max needs to check it runs o.k. ... Perhaps something was forgoten when commiting? Indeed. Committed. It worked like a charm! The first s3virge binary snapshot is now available on http://dri.sourceforge.net/snapshots/bleeding-edge/ . José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parhelia vs. Radeon 8500
On Wed, Jun 26, 2002 at 11:22:16PM +0200, German Gomez Garcia wrote: Hello, I have some money to spend (finally!!!) so I'm thinking of replacing my old G400MAX for a new card, as I prefer open source, I have to choose between ATI and Matrox, and the optios (for me) are the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy whatever card works better under Linux, as far as I know somebody is working in 3D for the 8500 even TCL!!, and the Gatos project has good quality video in/out for the AIW DV. The parhelia is quite misterious, but I could wait two or three months if the drivers would be good enough. I would like to know if anybody from Matrox contacted developers here, well, in fact, I would like to know if I should wait for the parhelia linux drivers or go for the AIW. What do you think?? For some reviews, comparisons and discussion regarding Matrox Parhelia follow this link http://slashdot.org/article.pl?sid=02/06/25/1317222 . Regarding the availability of linux drivers check the Matrox plan at http://www.extremetech.com/article2/0,3973,182491,00.asp . Regarding the ATI Radeon 8500 I'm sure you're already aware of the Wheather Channel sponsoring the development of DRI drivers: http://slashdot.org/article.pl?sid=02/06/09/0236221 . The choice [as always] depends entirely on which factors you value the most. I hope this helps. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
