Re: DRM map design
Dave Airlie writes: I've made a patch against the DRM code in CVS adding a few pieces that were missing. The code works for me on both radeon and r128. I've also tried to test mga however the mga code in CVS doesn't seem to work at all right now. My guess would be idr's changes might need some compat work .. no idea though.. I didn't see any problems. mga client side needs two adjustments. One really is a bugfix in code that isn't used with newer versions of DRM and the other one is a fix to the DRIRec structure. We may be able to do some compat work there but I'm not sure if it's worth it. We have already discussed eliminating drmAddress. These changes can be done simultaniously. I am currently assigning completely arbitrary 32-bit tokens for maps just to see how that works, and it seems to be fine on my G5 (which has AGP and a radeon 9600 card). I think it would be preferable to use Egbert's code which uses the map-offset value if it fits into 32 bits in the longer term. I've changed this to use the address value if possible (if it fits into 32bits and if the value has not been used as token for something else). This should help to maintain backward compatibility, on the other hand it may not sufficiently deter people from using handles as base addresses. DRM will work with either version. The kernel does not use drm_handle_t (except for the mga driver) where the use of it has been introduced just recently. I only consider published kernels and released X as stable ABIs so we can change the kernel stuff for the mga now... its in -mm but that is only experimental.. OK, how should we proceed then? I would propose the following: Phase 1: a. Make changes to DRM but leave drm_handle_t unsigned long We could then make texture_handle u32 as this would suffice to hold all significant bits of drm_handle_t although drm_handle_t is still unsigned long. b. convert unsigned long handle to drm_handle_t handle in Mesa and X code. Phase 2: a. change drm_handle_t to unsigned int. b. eliminate drmAddress and make the appropriate changes to driver DRIRec structures in Mesa and X. I can commit all the changes to X. However since some code (the driver DRI files for example) live both in Mesa and X things need to be coordinated somewhat. Can anyone give me a clue how this coordination is done? Cheers, Egbert. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On Tue, 12 Jul 2005 21:33:16 +0200 Sander Sweers [EMAIL PROTECTED] wrote: On 12/07/05, Michel Dänzer [EMAIL PROTECTED] wrote: On Tue, 2005-07-12 at 13:06 +0200, Sander Sweers wrote: Well xscreensaver is horrible to do any tests with, I never get above the 25 fps :( Which hack(s) are you trying, and are you passing -delay 0? atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps Changed this for atlantis and it gave me 23fps instead of 3, thanks. I get 120 fps with color tiling on pretty much same hw as you and 1280x1024 resolution. Youll need to use xorg cvs and ColorTiling option to enable it. Blocktube will not go above 25fps, even with delay is 0. Only with -wireframe it will go to 32fps. It seems that something is wrong here as increasing/decreasing window size doesnt affect framerates at all. My guess so far would be that the command buffer gets too fed up and causes this bottleneck. Are there other hacks I can use? (-no-fog usually does not give more than 1 extra fps). Fog is not yet supported. -- Aapo Tahkola --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
Aapo Tahkola wrote: atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps Changed this for atlantis and it gave me 23fps instead of 3, thanks. I get 120 fps with color tiling on pretty much same hw as you and 1280x1024 resolution. Youll need to use xorg cvs and ColorTiling option to enable it. Yep, color tiling is a big win here. When I turned it on, ./atlantis -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps (not fulscreen) went from 10 FPS to ~200 FPS. I also get 1000 FPS in glxgears while before I used to get ~500. This is on a rage mobility 9600 M10 (RV350) on a Pentium M 1.4 GHz. Blocktube will not go above 25fps, even with delay is 0. Only with -wireframe it will go to 32fps. For reference, I get ~26 FPS with wireframe and ~19 without (not full screen). With no HW acceleration I get 7 FPS. It seems that something is wrong here as increasing/decreasing window size doesnt affect framerates at all. My guess so far would be that the command buffer gets too fed up and causes this bottleneck. Why should increasing window size affect framerates? I thought that as far as the graphics chip was concerned, a triangle was just a triangle irrespective of size, and we're not hitting fill rate limits here... or is there something I'm missing? Cheers, Lorenzo --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mesa build problems on non-i386 platform.
I needed the patch below to build Mesa CVS head on x86-64. Otherwise gcc complained about RESTORE_FPU being undefined when compiling t_vb_arbprogram.c Egbert. diff -u -r1.4 t_vb_arbprogram.h --- src/mesa/tnl/t_vb_arbprogram.h 10 Jul 2005 11:23:10 - 1.4 +++ src/mesa/tnl/t_vb_arbprogram.h 13 Jul 2005 13:35:11 - @@ -128,6 +128,7 @@ /*--- */ +#if defined (__i386__) #ifdef NO_FAST_MATH #define RESTORE_FPU (DEFAULT_X86_FPU) #define RND_NEG_FPU (DEFAULT_X86_FPU | 0x400) @@ -135,6 +136,10 @@ #define RESTORE_FPU (FAST_X86_FPU) #define RND_NEG_FPU (FAST_X86_FPU | 0x400) #endif +#else +#define RESTORE_FPU 0 +#define RND_NEG_FPU 0 +#endif /*! * Private storage for the vertex program pipeline stage. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa build problems on non-i386 platform.
Oops. Sorry about this. I've committed an equivalent change. Keith Egbert Eich wrote: I needed the patch below to build Mesa CVS head on x86-64. Otherwise gcc complained about RESTORE_FPU being undefined when compiling t_vb_arbprogram.c Egbert. diff -u -r1.4 t_vb_arbprogram.h --- src/mesa/tnl/t_vb_arbprogram.h 10 Jul 2005 11:23:10 - 1.4 +++ src/mesa/tnl/t_vb_arbprogram.h 13 Jul 2005 13:35:11 - @@ -128,6 +128,7 @@ /*--- */ +#if defined (__i386__) #ifdef NO_FAST_MATH #define RESTORE_FPU (DEFAULT_X86_FPU) #define RND_NEG_FPU (DEFAULT_X86_FPU | 0x400) @@ -135,6 +136,10 @@ #define RESTORE_FPU (FAST_X86_FPU) #define RND_NEG_FPU (FAST_X86_FPU | 0x400) #endif +#else +#define RESTORE_FPU 0 +#define RND_NEG_FPU 0 +#endif /*! * Private storage for the vertex program pipeline stage. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On Wed, 13 Jul 2005 13:27:31 +0200 Lorenzo Colitti [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps Changed this for atlantis and it gave me 23fps instead of 3, thanks. I get 120 fps with color tiling on pretty much same hw as you and 1280x1024 resolution. Youll need to use xorg cvs and ColorTiling option to enable it. Yep, color tiling is a big win here. When I turned it on, ./atlantis -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps (not fulscreen) went from 10 FPS to ~200 FPS. I also get 1000 FPS in glxgears while before I used to get ~500. This is on a rage mobility 9600 M10 (RV350) on a Pentium M 1.4 GHz. Blocktube will not go above 25fps, even with delay is 0. Only with -wireframe it will go to 32fps. For reference, I get ~26 FPS with wireframe and ~19 without (not full screen). With no HW acceleration I get 7 FPS. It seems that something is wrong here as increasing/decreasing window size doesnt affect framerates at all. My guess so far would be that the command buffer gets too fed up and causes this bottleneck. Why should increasing window size affect framerates? I thought that as far as the graphics chip was concerned, a triangle was just a triangle irrespective of size, and we're not hitting fill rate limits here... or is there something I'm missing? AFAIK, hardware is usually done in a such way that pretty much everything is proportional to the master frequency. That said, less pixels should mean that it takes less clocks to get the job done. Also, r300s state management is not currently very efficient as can be seen from oprofiled reports... :) -- Aapo Tahkola --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mesa strict aliasing probs fixed
Hi,
find a patch attached that fixes all remaining strict-aliasing problems
when compiling Mesa with gcc 4 (at least for me).
CU all
Matthias
--
Matthias Hopf [EMAIL PROTECTED], SuSE labs, Zimmer 3.2.06, Tel. 74053-715
Index: src/glut/glx/glut_dstr.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_dstr.c,v
retrieving revision 1.5
diff -u -p -r1.5 glut_dstr.c
--- src/glut/glx/glut_dstr.c12 Feb 2003 23:56:23 - 1.5
+++ src/glut/glx/glut_dstr.c8 Jul 2005 17:04:00 -
@@ -34,6 +34,12 @@ static int glxcap[NUM_GLXCAPS] =
GLX_LEVEL,
};
+#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
+typedef void *fbc_t;
+#else
+typedef GLXFBConfigSGIX fbc_t;
+#endif
+
#ifdef TEST
#if !defined(_WIN32)
@@ -41,7 +47,7 @@ char *__glutProgramName = dstr;
Display *__glutDisplay;
int __glutScreen;
XVisualInfo *(*__glutDetermineVisualFromString) (char *string, Bool *
treatAsSingle,
- Criterion * requiredCriteria, int nRequired, int requiredMask, void **fbc) =
NULL;
+ Criterion * requiredCriteria, int nRequired, int requiredMask, fbc_t *fbc) =
NULL;
char *__glutDisplayString = NULL;
#endif
static int verbose = 0;
@@ -626,7 +632,7 @@ loadVisuals(int *nitems_return)
static XVisualInfo *
findMatch(FrameBufferMode * fbmodes, int nfbmodes,
- Criterion * criteria, int ncriteria, void **fbc)
+ Criterion * criteria, int ncriteria, fbc_t *fbc)
{
FrameBufferMode *found;
int *bestScore, *thisScore;
@@ -1420,7 +1426,7 @@ static int nfbmodes = 0;
static XVisualInfo *
getVisualInfoFromString(char *string, Bool * treatAsSingle,
- Criterion * requiredCriteria, int nRequired, int requiredMask, void **fbc)
+ Criterion * requiredCriteria, int nRequired, int requiredMask, fbc_t *fbc)
{
Criterion *criteria;
XVisualInfo *visinfo;
@@ -1530,11 +1536,7 @@ main(int argc, char **argv)
char *str, buffer[1024];
int tty = isatty(fileno(stdin));
int overlay = 0, showconfig = 0;
-#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
- GLXFBConfigSGIX fbc;
-#else
- void *fbc;
-#endif
+ fbc_t *fbc;
#if !defined(_WIN32)
dpy = XOpenDisplay(NULL);
@@ -1563,10 +1565,10 @@ main(int argc, char **argv)
} else {
if (overlay) {
vinfo = getVisualInfoFromString(str, treatAsSingle,
-requiredOverlayCriteria, numRequiredOverlayCriteria,
requiredOverlayCriteriaMask, (void**) fbc);
+requiredOverlayCriteria, numRequiredOverlayCriteria,
requiredOverlayCriteriaMask, fbc);
} else {
vinfo = getVisualInfoFromString(str, treatAsSingle,
-requiredWindowCriteria, numRequiredWindowCriteria,
requiredWindowCriteriaMask, (void**) fbc);
+requiredWindowCriteria, numRequiredWindowCriteria,
requiredWindowCriteriaMask, fbc);
}
if (vinfo) {
printf(\n);
Index: src/glut/glx/glut_overlay.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_overlay.c,v
retrieving revision 1.4
diff -u -p -r1.4 glut_overlay.c
--- src/glut/glx/glut_overlay.c 12 Feb 2003 23:56:23 - 1.4
+++ src/glut/glx/glut_overlay.c 8 Jul 2005 17:04:00 -
@@ -28,6 +28,12 @@
#include glutint.h
#include layerutil.h
+#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
+typedef void *fbc_t;
+#else
+typedef GLXFBConfigSGIX fbc_t;
+#endif
+
static Criterion requiredOverlayCriteria[] =
{
{LEVEL, EQ, 1}, /* This entry gets poked in
@@ -315,7 +321,7 @@ __glutFreeOverlay(GLUToverlay * overlay)
}
static XVisualInfo *
-determineOverlayVisual(int *treatAsSingle, Bool * visAlloced, void **fbc)
+determineOverlayVisual(int *treatAsSingle, Bool * visAlloced, fbc_t *fbc)
{
if (__glutDisplayString) {
XVisualInfo *vi;
@@ -362,11 +368,7 @@ glutEstablishOverlay(void)
GLUToverlay *overlay;
GLUTwindow *window;
XSetWindowAttributes wa;
-#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
- GLXFBConfigSGIX fbc;
-#else
- void *fbc;
-#endif
+ fbc_t *fbc;
/* Register a routine to free an overlay with glut_win.c;
this keeps glut_win.c from pulling in all of
@@ -389,7 +391,7 @@ glutEstablishOverlay(void)
__glutFatalError(out of memory.);
overlay-vis = determineOverlayVisual(overlay-treatAsSingle,
-overlay-visAlloced, (void **) fbc);
+overlay-visAlloced, fbc);
if (!overlay-vis) {
__glutFatalError(lacks overlay support.);
}
@@ -567,7 +569,7 @@ glutLayerGet(GLenum param)
{
XVisualInfo *vi;
Bool dummy, visAlloced;
- void *fbc;
+ fbc_t fbc;
vi = determineOverlayVisual(dummy, visAlloced, fbc);
if (vi) {
Index: src/glut/glx/glut_win.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_win.c,v
retrieving revision 1.6
diff -u -p -r1.6 glut_win.c
--- src/glut/glx/glut_win.c 12 Feb 2003 23:56:23 - 1.6
+++
Re: Mesa strict aliasing probs fixed
Matthias Hopf wrote: Hi, find a patch attached that fixes all remaining strict-aliasing problems when compiling Mesa with gcc 4 (at least for me). Are you sure you've got the #ifdef logic correct? #if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig) typedef void *fbc_t; #else typedef GLXFBConfigSGIX fbc_t; #endif I would expect that the proper test would be: #if defined(GLX_SGIX_fbconfig) typedef GLXFBConfigSGIX fbc_t; #else typedef void *fbc_t; #endif I'd probably also replace 'fbc_t' with 'fbconfig_t' to make it more readable. -Brian --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa strict aliasing probs fixed
On Jul 13, 05 09:16:32 -0600, Brian Paul wrote: find a patch attached that fixes all remaining strict-aliasing problems when compiling Mesa with gcc 4 (at least for me). Are you sure you've got the #ifdef logic correct? I just copied the one that was already present and didn't think much about it. #if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig) typedef void *fbc_t; #else typedef GLXFBConfigSGIX fbc_t; #endif I would expect that the proper test would be: #if defined(GLX_SGIX_fbconfig) typedef GLXFBConfigSGIX fbc_t; #else typedef void *fbc_t; #endif I would expect that as well. But I wanted a minimal invasive change. Feel free to change this ;) I'd probably also replace 'fbc_t' with 'fbconfig_t' to make it more readable. That's perfectly fine for me. Thanks Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa strict aliasing probs fixed
Matthias Hopf wrote: On Jul 13, 05 09:16:32 -0600, Brian Paul wrote: find a patch attached that fixes all remaining strict-aliasing problems when compiling Mesa with gcc 4 (at least for me). Are you sure you've got the #ifdef logic correct? I just copied the one that was already present and didn't think much about it. #if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig) typedef void *fbc_t; #else typedef GLXFBConfigSGIX fbc_t; #endif I would expect that the proper test would be: #if defined(GLX_SGIX_fbconfig) typedef GLXFBConfigSGIX fbc_t; #else typedef void *fbc_t; #endif I would expect that as well. But I wanted a minimal invasive change. Feel free to change this ;) I'd probably also replace 'fbc_t' with 'fbconfig_t' to make it more readable. That's perfectly fine for me. Would mind creating a new patch? I don't have any time to do so. -Brian --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
getting r300 into Mesa
Do we have a plan on doing this? It would be good to merge things since you don't want to diverge too much? Shawn. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
