Re: r300 testing..
On Thu, 28 Jul 2005 00:38:38 +0200 Roland Scheidegger <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > >>That's true, but to avoid the huge drops you could also just decrease > >>texture detail. Or implement the second texture heap in main memory and > >>use gart texturing (though you'd also need to manually increase the gart > >>size). There are some problems with that for r200, and the strategy for > >>what textures to put where may not be optimal currently, but the drops > >>should be gone. > >>That said, the performance in ut2k4 is probably really slow (apart from > >>that problem) due to deficiencies in drawArrays handling, at least that > >>was the case for r200 last time I checked... > > > > > > First "hack" attempts to improve it. > > > > Later two patches workaround RADEON_BUFFER_SIZE limit. > > While this actually appears to work theres no speed boost in general. > > That's what I found out some time ago as well, I did pretty similar > changes (basically bring back that start value). Once upon a time I also > had a hack so mesa could handle GL_UNSIGNED_SHORT elements lists > natively (no more converting them with _ac_import_elements to > UNSIGNED_INT and later back to shorts again in the driver) without any > success neither. > I never really found out why the old mesa code was 2 times faster :-(. First patch is working alright. without(ut2k3, citadel): 7.339034 / 20.030720 / 164.477829 fps -- Score = 19.973906 rand[1492594185] and with: 11.727319 / 31.931662 / 223.457932 fps -- Score = 31.496284 rand[31108770] What I dont know is why dma_ext doesnt speed up things where fallback_drawarrays would clearly get lots of hits. -- Aapo Tahkola --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 testing..
Aapo Tahkola wrote: That's true, but to avoid the huge drops you could also just decrease texture detail. Or implement the second texture heap in main memory and use gart texturing (though you'd also need to manually increase the gart size). There are some problems with that for r200, and the strategy for what textures to put where may not be optimal currently, but the drops should be gone. That said, the performance in ut2k4 is probably really slow (apart from that problem) due to deficiencies in drawArrays handling, at least that was the case for r200 last time I checked... First "hack" attempts to improve it. Later two patches workaround RADEON_BUFFER_SIZE limit. While this actually appears to work theres no speed boost in general. That's what I found out some time ago as well, I did pretty similar changes (basically bring back that start value). Once upon a time I also had a hack so mesa could handle GL_UNSIGNED_SHORT elements lists natively (no more converting them with _ac_import_elements to UNSIGNED_INT and later back to shorts again in the driver) without any success neither. I never really found out why the old mesa code was 2 times faster :-(. Roland --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 testing..
On Mon, 27 Jun 2005 01:57:56 +0200
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Ben Skeggs wrote:
> > S3TC does seem to be the killer for UT2004. I started porting over the
> > S3TC stuff from the r200 driver a while
> > back, but haven't had a lot of time recently to fix a couple of issues
> > with it. Overall fps doesn't seem to take a
> > huge gain, but the sudden drops to 1-2fps in certain levels
> > (CTF-Faceclassic) disappear when S3TC's enabled.
> That's true, but to avoid the huge drops you could also just decrease
> texture detail. Or implement the second texture heap in main memory and
> use gart texturing (though you'd also need to manually increase the gart
> size). There are some problems with that for r200, and the strategy for
> what textures to put where may not be optimal currently, but the drops
> should be gone.
> That said, the performance in ut2k4 is probably really slow (apart from
> that problem) due to deficiencies in drawArrays handling, at least that
> was the case for r200 last time I checked...
First "hack" attempts to improve it.
Later two patches workaround RADEON_BUFFER_SIZE limit.
While this actually appears to work theres no speed boost in general.
--
Aapo Tahkola
Index: t_array_api.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/tnl/t_array_api.c,v
retrieving revision 1.52
diff -u -b -B -u -r1.52 t_array_api.c
--- t_array_api.c 18 Jul 2005 12:31:30 - 1.52
+++ t_array_api.c 27 Jul 2005 20:28:16 -
@@ -78,21 +78,20 @@
}
-/* Note this function no longer takes a 'start' value, the range is
- * assumed to start at zero. The old trick of subtracting 'start'
- * from each index won't work if the indices are not in writeable
- * memory.
- */
static void _tnl_draw_range_elements( GLcontext *ctx, GLenum mode,
+ GLuint min_index,
GLuint max_index,
GLsizei index_count, GLuint *indices )
{
TNLcontext *tnl = TNL_CONTEXT(ctx);
struct tnl_prim prim;
+ int i;
+ static int size=0;
+ static GLuint *ind=NULL;
FLUSH_CURRENT( ctx, 0 );
- _tnl_vb_bind_arrays( ctx, 0, max_index );
+ _tnl_vb_bind_arrays( ctx, min_index, max_index );
tnl->vb.Primitive = &prim;
tnl->vb.Primitive[0].mode = mode | PRIM_BEGIN | PRIM_END;
@@ -100,8 +99,15 @@
tnl->vb.Primitive[0].count = index_count;
tnl->vb.PrimitiveCount = 1;
- tnl->vb.Elts = (GLuint *)indices;
+ if(index_count > size){
+ size = index_count;
+ free(ind);
+ ind = malloc(index_count * sizeof(GLuint));
+ }
+ for(i=0; i < index_count; i++)
+ ind[i] = indices[i] - min_index;
+ tnl->vb.Elts = ind;
tnl->Driver.RunPipeline( ctx );
}
@@ -297,20 +301,19 @@
* at the whole locked range.
*/
- if (start == 0 && ctx->Array.LockFirst == 0 &&
- end < (ctx->Array.LockFirst + ctx->Array.LockCount))
-_tnl_draw_range_elements( ctx, mode,
+ if (end-start+1 < (ctx->Array.LockFirst + ctx->Array.LockCount)){
+_tnl_draw_range_elements( ctx, mode, start,
ctx->Array.LockCount,
count, ui_indices );
- else {
+} else {
fallback_drawelements( ctx, mode, count, ui_indices );
}
}
- else if (start == 0 && end < ctx->Const.MaxArrayLockSize) {
+ else if (end-start+1 < ctx->Const.MaxArrayLockSize) {
/* The arrays aren't locked but we can still fit them inside a
* single vertexbuffer.
*/
- _tnl_draw_range_elements( ctx, mode, end + 1, count, ui_indices );
+ _tnl_draw_range_elements( ctx, mode, start, end + 1, count, ui_indices );
}
else {
/* Range is too big to optimize:
@@ -352,7 +355,7 @@
if (ctx->Array.LockCount) {
if (ctx->Array.LockFirst == 0)
-_tnl_draw_range_elements( ctx, mode,
+_tnl_draw_range_elements( ctx, mode, 0,
ctx->Array.LockCount,
count, ui_indices );
else
@@ -361,16 +364,18 @@
else {
/* Scan the index list and see if we can use the locked path anyway.
*/
- GLuint max_elt = 0;
+ GLuint max_elt = 0, min_elt = ~0;
GLint i;
- for (i = 0 ; i < count ; i++)
+ for (i = 0 ; i < count ; i++){
if (ui_indices[i] > max_elt)
max_elt = ui_indices[i];
-
- if (max_elt < ctx->Const.MaxArrayLockSize && /* can we use it? */
- max_elt < (GLuint) count)/* do we want to use it? */
-_tnl_draw_range_elements( ctx, mode, max_elt+1, count, ui_indices );
+if (ui_indices[i] < min_elt)
+min_elt = ui_indices[i];
+ }
+ if (max_elt-min_elt+1 < ctx->Const.MaxArrayLockSize && /* can we use it?
*/
+ max_elt-min_elt+1 < (GLuint) count)
Re: r300 testing..
Ben Skeggs wrote: S3TC does seem to be the killer for UT2004. I started porting over the S3TC stuff from the r200 driver a while back, but haven't had a lot of time recently to fix a couple of issues with it. Overall fps doesn't seem to take a huge gain, but the sudden drops to 1-2fps in certain levels (CTF-Faceclassic) disappear when S3TC's enabled. That's true, but to avoid the huge drops you could also just decrease texture detail. Or implement the second texture heap in main memory and use gart texturing (though you'd also need to manually increase the gart size). There are some problems with that for r200, and the strategy for what textures to put where may not be optimal currently, but the drops should be gone. That said, the performance in ut2k4 is probably really slow (apart from that problem) due to deficiencies in drawArrays handling, at least that was the case for r200 last time I checked... Roland --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 testing..
Adam K Kirchhoff wrote: FYI I've had a chance today to test the r300 driver (using a Radeon 9550) with every 3d game and application I have installed. This includes UnrealTournament, ut2004, q3a, RTCW, Rune, Tribes2, Orbz, MarbleBlast (both from GarageGames), neverball, neverputt, NWN, doom3, blender, ppracer, and gltron. There were no lockups and very few rendering errors that I could see. Great to hear! Doom3 refused to launch, just stopping with: - R_InitOpenGL - Setup X display connection dlopen(libGL.so.1) Initializing OpenGL display Using XFree86-VidModeExtension Version 2.2 DGA DirectVideo Mouse (Version 2.0) initialized Free86-VidModeExtension Activated at 800x600 Is that the whole message? Doom3 stops for me with a message saying the required features weren't found. Re-enabling cube maps should allow Doom3 to start. Using the "arb" renderer, it almost looks correct with the exception of a few things. But it's very slow. The "arb2" renderer will most likely look horribly wrong, and will eventually die in r300_fragprog.c due to unimplemented instructions. Mesa also doesn't seem to set fp_instruction->Opcode for the KIL instruction, so what you see with the arb2 renderer may vary from run to run. Performance wise, the driver seems to be on par with the r200 driver. Orbz and NWN are noticably slower. UT2004 is painfully slow, but I'm chalking that up to the S3TC fallback in the games renderer. Blender, which used to crash when opening up a couple files, seems to work flawlessly. I notice that the Blender tool panel doesn't randomly disappear now, which is good. S3TC does seem to be the killer for UT2004. I started porting over the S3TC stuff from the r200 driver a while back, but haven't had a lot of time recently to fix a couple of issues with it. Overall fps doesn't seem to take a huge gain, but the sudden drops to 1-2fps in certain levels (CTF-Faceclassic) disappear when S3TC's enabled. I have most of the remaining ARB_f_p support implemented locally, and some fixes for existing instructions. I needed to overhaul quite a bit of my original code because of some very bad assumptions, so it'll be a week or so before I have time to properly test the changes and commit to cvs. Cheers, Ben. This is on an SMP xeon system, with 1 gig of RAM, running 2.6.12.1 and Debian -unstable. Adam --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
On Saturday 15 January 2005 19:16, D. Hageman wrote: > On Sat, 15 Jan 2005, Adam Jackson wrote: > > On Saturday 15 January 2005 13:56, D. Hageman wrote: > >> GL_MAX_VIEWPORT_DIMS=4096/4096 > >> GL_RENDERER = Mesa X11 > > > > > > > > You're using the wrong libGL. > > Indeed you are right. I am trying to figure out how it is deciding that. > It says in my Xorg.log that Direct Rendering is enabled. It autoloads my > kernel drivers and I can see them in lsmod. It just isn't looking for the > r300_dri.so. ldd `which glxgears` will tell you which libGL you're using. - ajax pgp6AelCHDeBP.pgp Description: PGP signature
Re: [r300] testing results
I was finally able to coerce it into working. I am not sure what I did different to make it work. Getting it to work doubled the FPS from glxgears. At any rate, the results from glxgears are below: Using 8 maximum texture units.. GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa DRI R300 20040924 AGP 1x NO-TCL GL_VERSION= 1.3 Mesa 6.3 GL_VENDOR = Tungsten Graphics, Inc. GL_EXTENSIONS = GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 4311 frames in 5.0 seconds = 862.151 FPS 4356 frames in 5.0 seconds = 871.109 FPS 4210 frames in 5.0 seconds = 841.978 FPS 4333 frames in 5.0 seconds = 866.465 FPS //\\ || D. Hageman || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
On Sat, 15 Jan 2005, Adam Jackson wrote: On Saturday 15 January 2005 13:56, D. Hageman wrote: I just got done with the second try at this. I pulled the Mesa and r300_driver cvs trees this morning and recompiled. The only hitch was that apparently some changes have happened to the radeon and r200 driver in the Mesa tree that doesn't allow it to compile. Looks like someone added some code with some defines that didn't get into the header. At any rate, still the same situation with the glxgears. It works, but it works slow. I don't get any lockups. I think the r300_demo is working fine. Enabling the LIBGL_DEBUG doesn't show that it isn't finding anything like r300_dri.so or something. Here is the output from glxgears -info GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa X11 You're using the wrong libGL. Indeed you are right. I am trying to figure out how it is deciding that. It says in my Xorg.log that Direct Rendering is enabled. It autoloads my kernel drivers and I can see them in lsmod. It just isn't looking for the r300_dri.so. I really hate trying to work with 3 different source trees. :-( //\\ || D. Hageman || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
On Saturday 15 January 2005 13:56, D. Hageman wrote: > I just got done with the second try at this. I pulled the Mesa and > r300_driver cvs trees this morning and recompiled. The only hitch was > that apparently some changes have happened to the radeon and r200 driver > in the Mesa tree that doesn't allow it to compile. Looks like someone > added some code with some defines that didn't get into the header. > > At any rate, still the same situation with the glxgears. It works, but it > works slow. I don't get any lockups. I think the r300_demo is working > fine. Enabling the LIBGL_DEBUG doesn't show that it isn't finding > anything like r300_dri.so or something. > > Here is the output from glxgears -info > > GL_MAX_VIEWPORT_DIMS=4096/4096 > GL_RENDERER = Mesa X11 You're using the wrong libGL. - ajax pgp0EPewhdc2q.pgp Description: PGP signature
Re: [r300] testing results
I haven't enabled any debugging other then running glxgears with LIBGL_DEBUG to see if it wasn't finding the r300_dri.so. [drm] Initialized drm 1.0.0 20040925 ACPI: PCI interrupt :01:00.0[A] -> GSI 16 (level, low) -> IRQ 169 [drm] Initialized radeon 1.12.1 20041216 on minor 0: agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: Putting AGP V3 device at :00:00.0 into 4x mode agpgart: Putting AGP V3 device at :01:00.0 into 4x mode [drm] Loading R300 Microcode On Sat, 15 Jan 2005, Vladimir Dergachev wrote: On Sat, 15 Jan 2005, D. Hageman wrote: I am running the latest CVS x.org. It shows that the highly experimental warning and all of that in the logfile. I keep thinking that I have fumbled the ball somewhere on the compile and install, but I just can't see it at the moment. I haven't given up yet though. ;-) Are you loading agpgart before drm driver ? Did you enable debugging in the drm driver as README says ? (If so this would slow everything down.. I usually don't turn it on, the drm driver have not changed in a while). best Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel //\\ || D. Hageman || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
On Sat, 15 Jan 2005, D. Hageman wrote: I am running the latest CVS x.org. It shows that the highly experimental warning and all of that in the logfile. I keep thinking that I have fumbled the ball somewhere on the compile and install, but I just can't see it at the moment. I haven't given up yet though. ;-) Are you loading agpgart before drm driver ? Did you enable debugging in the drm driver as README says ? (If so this would slow everything down.. I usually don't turn it on, the drm driver have not changed in a while). best Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
I am running the latest CVS x.org. It shows that the highly experimental warning and all of that in the logfile. I keep thinking that I have fumbled the ball somewhere on the compile and install, but I just can't see it at the moment. I haven't given up yet though. ;-) On Sat, 15 Jan 2005, Peter Zubaj wrote: Did you get latest CVS x.org source with support for r300 ? Or did you patch it with ati.patch from r300_driver ? D. Hageman wrote: < I just got done with the second try at this. I pulled the Mesa and r300_driver cvs trees this morning and recompiled. The only hitch was that apparently some changes have happened to the radeon and r200 driver in the Mesa tree that doesn't allow it to compile. Looks like someone added some code with some defines that didn't get into the header. At any rate, still the same situation with the glxgears. It works, but it works slow. I don't get any lockups. I think the r300_demo is working fine. Enabling the LIBGL_DEBUG doesn't show that it isn't finding anything like r300_dri.so or something. //\\ || D. Hageman || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
Did you get latest CVS x.org source with support for r300 ? Or did you patch it with ati.patch from r300_driver ? D. Hageman wrote: < I just got done with the second try at this. I pulled the Mesa and r300_driver cvs trees this morning and recompiled. The only hitch was that apparently some changes have happened to the radeon and r200 driver in the Mesa tree that doesn't allow it to compile. Looks like someone added some code with some defines that didn't get into the header. At any rate, still the same situation with the glxgears. It works, but it works slow. I don't get any lockups. I think the r300_demo is working fine. Enabling the LIBGL_DEBUG doesn't show that it isn't finding anything like r300_dri.so or something. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
On Fri, 14 Jan 2005, Vladimir Dergachev wrote: On Fri, 14 Jan 2005, D. Hageman wrote: I took the time to compile the r300 driver and give it a whirl. The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility 9600 M10. It has a device ID of 0x4e50. glxgears runs with a 370-380 FPS. Hmm.. There are two possibilities: 1. I have been somewhat careless to commit code with debugging fprintf's - these could be interfering with framerates. The motivation was that part of code (textures) need figuring out and fprintfs are convenient to track things down.. It is all cleaned up by now, so try again - or just hunt down and delete fprintf's by hand. 2. You might be using software rendering and your CPU is quite a bit faster than mine (I get somewhat above 200 on 1.6ghz Pentium-M). Use export LIBGL_DEBUG=verbose to see what happend to glxgears during startup. r300_demo --triangles and --tex-triangles does not give me the same view as the screenshot on the r300 webpage. The tex-triangles is closest to the screenshot on the webpage, but the triangles one is no where close. This is normal - there had been some changes :) I just got done with the second try at this. I pulled the Mesa and r300_driver cvs trees this morning and recompiled. The only hitch was that apparently some changes have happened to the radeon and r200 driver in the Mesa tree that doesn't allow it to compile. Looks like someone added some code with some defines that didn't get into the header. At any rate, still the same situation with the glxgears. It works, but it works slow. I don't get any lockups. I think the r300_demo is working fine. Enabling the LIBGL_DEBUG doesn't show that it isn't finding anything like r300_dri.so or something. Here is the output from glxgears -info GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa X11 GL_VERSION= 1.5 Mesa 6.3 GL_VENDOR = Brian Paul GL_EXTENSIONS = GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_fragment_shader GL_HP_occlusion_test GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_program_debug GL_MESA_resize_buffers GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_fragment_program GL_NV_light_max_exponent GL_NV_point_sprite GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGI_texture_color_table GL_SGIS_generate_mipmap GL_SGIS_pixel_texture GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_pixel_texture GL_SGIX_shadow GL_SGIX_shadow_ambient GL_SUN_multi_draw_arrays 1858 frames in 5.0 seconds = 371.430 FPS 1863 frames in 5.0 seconds = 372.415 FPS 1871 frames in 5.0 seconds = 374.167 FPS //\\ || D. Hageman || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -
Re: [r300] testing results
On Fri, 14 Jan 2005, D. Hageman wrote: I took the time to compile the r300 driver and give it a whirl. The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility 9600 M10. It has a device ID of 0x4e50. glxgears runs with a 370-380 FPS. Hmm.. There are two possibilities: 1. I have been somewhat careless to commit code with debugging fprintf's - these could be interfering with framerates. The motivation was that part of code (textures) need figuring out and fprintfs are convenient to track things down.. It is all cleaned up by now, so try again - or just hunt down and delete fprintf's by hand. 2. You might be using software rendering and your CPU is quite a bit faster than mine (I get somewhat above 200 on 1.6ghz Pentium-M). Use export LIBGL_DEBUG=verbose to see what happend to glxgears during startup. r300_demo --triangles and --tex-triangles does not give me the same view as the screenshot on the r300 webpage. The tex-triangles is closest to the screenshot on the webpage, but the triangles one is no where close. This is normal - there had been some changes :) best Vladimir Dergachev I am wondering if I compiled something wrong since I don't have high framerates on the glxgears like others are seeing and my r300_demo doesn't match the screenshots. I see that some changes have went into CVS today so I will take the time to compile those tonight. If you have something specific you want me to try with this hardware let me know. //\\ || D. Hageman || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
