date:20030606

Alex Deucher wrote:
Gabucino,

   Do you know if either plugin uses MESA_ycbcr_texture?  this would
avoid the need for you to convert YUV data to RGB in order to render it
as a texture.  Should speed things up of OGL.  when I looked at the
xine plugin source, it did not support this.  For systems that do not
support the extension, you could always fall back to RGB.  As Ian
mentioned, some of the other extensions coming down the pike will also
help performance:  APPLE_client_storage and such...
http://mesa3d.sourceforge.net/MESA_ycbcr_texture.spec
http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt
http://oss.sgi.com/projects/ogl-sample/registry/APPLE/fence.txt
I've just been looking at the one in Xine, and it just uses plain RGB square 
textures.

Keith



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture

2003-06-06 Thread Martin Spott

Matt Sealey [EMAIL PROTECTED] wrote:

  I'm sure that MPlayer or Xine actually support an OpenGL output
  plugin already. Chances are it's Xine, but I haven't touched it in
  6 months, maybe they removed it?
 
 I believe it's still there. Before propagating the use of 'new' API's in
 Xinre for example please remember that this software was designed to run on
 other platforms, too, that don't know anything of MESA (IRIX for example).

 Um..

 IRIX doesn't have OpenGL now?

That's not what I was claiming. People where talking about
'MESA_ycbcr_texture' which I was referring to (see my posting),

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture

Matt Sealey wrote:

I'm sure that MPlayer or Xine actually support an OpenGL output
plugin already. Chances are it's Xine, but I haven't touched it in
6 months, maybe they removed it?
I believe it's still there. Before propagating the use of 'new' API's in
Xinre for example please remember that this software was designed to run on
other platforms, too, that don't know anything of MESA (IRIX for example).
*Lots* of platforms support NV_texture_rectangle or 
EXT_texture_rectangle.  Lots of platforms also support some form of YUV 
textures.  You have SGI_ycrcb, APPLE_ycbcr, NVX_ycbcr, and 
MESA_ycbcr_texture from which to choose.  Variety is the spice of life, 
afterall! :)

Um..

IRIX doesn't have OpenGL now?

That's certainly news to me, and probably to SGI too :)
Of course it has OpenGL.  What it doesn't have is any of the 
Mesa-specific extensions (such as MESA_ycbcr_texture).





---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] known issues w/Tualatin?

[EMAIL PROTECTED] wrote:
I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I start up 
Q3A the machine hangs hard.
[snip]

I am running X 4.2.x with dri cvs from a while ago--so I'm wondering if there 
have already been some known issues solved that an update would fix?  The 
only thing I can think of is perhaps the prefetching that the tualatin does?  
Just an ignorant guess.  Any suggestions?
Once upon a time there were some problems with the CPU detection code. 
The problem was that 3Dnow! was enabled on some systems that don't 
support it.  I wonder if that may be happening here.  Could you post the 
output of glxinfo on your box with the new CPUs?



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture

Martin Spott wrote:
Matt Sealey [EMAIL PROTECTED] wrote:


I'm sure that MPlayer or Xine actually support an OpenGL output
plugin already. Chances are it's Xine, but I haven't touched it in
6 months, maybe they removed it?
I believe it's still there. Before propagating the use of 'new' API's in
Xinre for example please remember that this software was designed to run on
other platforms, too, that don't know anything of MESA (IRIX for example).


Um..


IRIX doesn't have OpenGL now?


That's not what I was claiming. People where talking about
'MESA_ycbcr_texture' which I was referring to (see my posting),
Typically it's pretty easy to write GL programs to not rely on given 
extensions being present.  The GL extension mechanism makes this fairly painless.

And as the fallback paths are already in place, I can't see it being much of a 
problem.

Keith



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missinglibGL.so?)

2003-06-06 Thread Leif Delgass

On Wed, 4 Jun 2003, Ian Romanick wrote:

 John Sheu wrote:
  Output of gdb on glxinfo:
  
  Starting program: /usr/X11R6/bin/glxinfo
  (no debugging symbols found)...[New Thread 16384 (LWP 2145)]
  name of display: :0.0
  
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 16384 (LWP 2145)]
  0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18)
  at texmem.c:584
  584 texmem.c: No such file or directory.
  in texmem.c
 
 Hmm...looking at the code, my guess is that rmesa-nr_heaps is 2 on Rage 
 128 even on PCI cards.  In gdb you can 'print rmesa-nr_heaps' to see. 
 You might also try 'print r128scrn-texSize[0]' and (if nr_heaps is 2) 
 'print r128scrn-texSize[1]'.  Since I don't have a Rage 128, that would 
 help. :)
 
 Perhaps Leif can take a look at this.
 
 Note that this has *NOTHING* to do with your libGL.so.  This is 100% in 
 the driver.

nr_heaps should be 1 on PCI cards (see r128CreateScreen() in
r128_screen.c).  However, the DDX will enable DRI even if the local
texture heap size is 0 on a PCI card, which I consider to be a bug (I
changed the mach64 driver to disable DRI if there's not enough mem for a
texture heap).  I also think you'd run into the same problem if there is
no room for a local heap, but there is space for an AGP heap.  In working
on texmem for mach64, I've changed the heap indexes for local/AGP to be
context variables instead of #defines, so that texture_heaps[0] can be AGP
if there is only an AGP heap and no local heap.

I'm pretty sure I ran into this problem on r128 before when I tried
running at 24-bit depth with a high enough resolution.  If this is the
problem, I think you'd see a message like: Reserved 0 kb for textures at
offset 0x0 in the X log.

Still, I think the drivers should also check the return of 
driCreateTextureHeap() and bail out if it fails.

-- 
Leif Delgass 
http://www.retinalburn.net



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] known issues w/Tualatin?

2003-06-06 Thread Michel Dänzer

On Thu, 2003-06-05 at 11:24, [EMAIL PROTECTED] wrote:
 I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I start up 
 Q3A the machine hangs hard.
 
 On one occasion, Q3A started, but the sound was all screwy, and on exit q3a 
 segfaulted.  xmms, however, still played sound just fine.
 
 The other few times I tried, it instantly locked up hard requiring reboots.
 
 With the 933 cpus, there never was any problem like this.
 
 64mb ddr Radeon vivo @ agp 4x

Have you tried more conservative AGP settings?


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \ http://svcs.affero.net/rm.php?r=daenzer



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] dri-devel 83% Off On Viagra For Men Women Now!., xdx

2003-06-06 Thread cncpvvgp

SAVE  80% ON VIAGRA TODAY!
* No Doctors Visit  * No Consulting Fee  * FREE Shipping!Click 
  Here To Save Today!If you wish to be removed click here...qaalahep
+wzf¢+,¦ì¢·o!-ë«²Ó¢Ö¥V'°NzËm·u×º®íêejw
ë"wÂ+a¶Þi×^nè xy«në2¢ëÞëÞÚÞjg¡ûkÉ:-jUb{ç·0zÙî±Ê&¸z÷¥¨¥x%ËC®'^½éeËl²«qçè®§zØm¶?þX¬¶Ë(º·~àzwþX¬¶ÏåËbú?v¸z÷¥

Re: [Dri-devel] known issues w/Tualatin?

2003-06-06 Thread nick

On Thursday 05 June 2003 10:33 am, Ian Romanick wrote:
 [EMAIL PROTECTED] wrote:
  I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I
  start up Q3A the machine hangs hard.

 [snip]

  I am running X 4.2.x with dri cvs from a while ago--so I'm wondering if
  there have already been some known issues solved that an update would
  fix?  The only thing I can think of is perhaps the prefetching that the
  tualatin does? Just an ignorant guess.  Any suggestions?

 Once upon a time there were some problems with the CPU detection code.
 The problem was that 3Dnow! was enabled on some systems that don't
 support it.  I wonder if that may be happening here.  Could you post the
 output of glxinfo on your box with the new CPUs?

@ glxinfo
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20021125 AGP 4x x86/MMX/SSE TCL
OpenGL version string: 1.2 Mesa 5.0
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_ATI_texture_mirror_once,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram,
GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_texture3D, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object,
GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip,
GL_IBM_texture_mirrored_repeat, GL_MESA_window_pos, GL_NV_blend_square,
GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table,
GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
--
0x23 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x24 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  8  0  0  0  0  0 0 None
0x25 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x26 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x27 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x28 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8  0  0  0  0  0 0 None
0x29 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x2a 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x2b 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x2c 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  8  0  0  0  0  0 0 None
0x2d 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x2e 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x2f 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x30 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  8  0  0  0  0  0 0 None
0x31 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x32 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)

On Thursday 05 June 2003 11:45 am, Leif Delgass wrote:
 I'm pretty sure I ran into this problem on r128 before when I tried
 running at 24-bit depth with a high enough resolution.  If this is the
 problem, I think you'd see a message like: Reserved 0 kb for textures at
 offset 0x0 in the X log.

Right, that appears in the logs.  So what to do?


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] More client and server GLX updates

Ian Romanick wrote:
Ian Romanick wrote:

In any case, here is the patch as it currently stands.  demos/occlude 
doesn't work right, but I'm working on it.  I've also attached a patch 
to demos/shadowtex.c to change the way cycling compare mode works.  It 
can now cycle with the SGIX version.  I'll commit this later.  I want 
to modify it further to select at run-time which extensions to use.


I've been trying to solve the HP_occlusion_test problem all morning.  As 
near as I can tell, all of the right GLX protocol is happening, but the 
OCCLUSION_TEST_RESULT_HP is always false.  The only thing I can think of 
is that the extension isn't enabled in Mesa.  How does the Mesa that 
gets compiled in know which extensions to enable?  Does it just use 
_mesa_enable_sw_extnesions?
Here's what I have done.

1. I put a printf in glGetBooleanv (lib/GL/glx/single2.c) to print a 
message when glGetBoolean is called with GL_OCCLUSION_TEST_RESULT_HP as 
the val.

2. I put a xf86printf in __glXDisp_GetBooleanv 
(programs/Xserver/GL/glx/g_single.c) and __glXDispSwap_GetBooleanv 
(programs/Xserver/GL/glx/g_singleswap.c) to log compsize when *pc is 
GL_OCCLUSION_TEST_RESULT_HP.

3. I put two _mesa_debug messages in _mesa_GetBooleanv in the 
GL_OCCLUSION_TEST_RESULT_HP case to log that it was called and the result.

The first message gets logged to the window that starts demos/occlude 
and the thrid message gets logged to the console that started XFree86. 
The second message never gets logged anywhere.  The state of 
ctx-Depth.OcclusionTest printed in _mesa_GetBooleanv is always GL_TRUE 
(as it should be), but the value of ctx-OcclusionResult is always 
GL_FALSE (yes, I print the message *before* OcclusionResult is 
explicitly set to false).

Based on that I conclude that my GLX protocol is correct, but there is a 
bug in HP_occlusion_test in Mesa 5.0.  However, using LD_PRELOAD  
LD_LIBRARY_PATH to get the libGL from mesa_5_0_branch with demos/occlude 
gives the correct results.

I'm very, very confused. :(



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] known issues w/Tualatin?

2003-06-06 Thread Michel Dänzer

On Thu, 2003-06-05 at 21:25, [EMAIL PROTECTED] wrote:
 On Thursday 05 June 2003 11:18 am, Michel Dänzer wrote:
  On Thu, 2003-06-05 at 11:24, [EMAIL PROTECTED] wrote:
   I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I
   start up Q3A the machine hangs hard.
  
   On one occasion, Q3A started, but the sound was all screwy, and on exit
   q3a segfaulted.  xmms, however, still played sound just fine.
  
   The other few times I tried, it instantly locked up hard requiring
   reboots.
  
   With the 933 cpus, there never was any problem like this.
  
   64mb ddr Radeon vivo @ agp 4x
 
  Have you tried more conservative AGP settings?
 
 Okay, if I set it all the way down to 1x, it doesn't seem to hang anymore (at 
 least it hasn't yet). I tried turning off AGPFastWrite, but that didn't help.
 
 This is a real bummer--kinda defeats the purpose of the upgrade.

Have you actually measured 4x vs. 1x? Not much difference IME.


 I've always run at 4x on this system w/o any problems before.  Why would the 
 newer cpus make a difference here?  Isn't the AGP bus off the northbridge?  
 If so, since that didn't change--why the change in behavior?

Dunno. Maybe there's a bug somewhere, or maybe it was just luck that it
worked before.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \ http://svcs.affero.net/rm.php?r=daenzer



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] known issues w/Tualatin?

2003-06-06 Thread Nicholas Leippe

On Thursday 05 June 2003 01:25 pm, [EMAIL PROTECTED] wrote:
 On Thursday 05 June 2003 11:18 am, Michel Dänzer wrote:
  On Thu, 2003-06-05 at 11:24, [EMAIL PROTECTED] wrote:
   I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I
   start up Q3A the machine hangs hard.
  
   On one occasion, Q3A started, but the sound was all screwy, and on exit
   q3a segfaulted.  xmms, however, still played sound just fine.
  
   The other few times I tried, it instantly locked up hard requiring
   reboots.
  
   With the 933 cpus, there never was any problem like this.
  
   64mb ddr Radeon vivo @ agp 4x
 
  Have you tried more conservative AGP settings?

 Okay, if I set it all the way down to 1x, it doesn't seem to hang anymore
 (at least it hasn't yet). I tried turning off AGPFastWrite, but that didn't
 help.

Okay, I have to take that back.  It just crashed at 1x as well.
First, I started q3a and got garbled sound.  So I quit, stopped my md devices, 
and started q3a again--instant hard lockup.

So, no magic bullet w/1x either.

bummer++


Nick



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips

2003-06-06 Thread bugzilla-daemon

[This e-mail has been automatically generated.] 
 
Please do not reply to this email. if you want to comment on the bug, go to the 
URL shown below and enter your comments there. 
  
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 
 
[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]  |dri-
   ||[EMAIL PROTECTED]
   Severity|major   |enhancement
   Platform||All



--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 16:26 ---
Do you think setting this to major will make people work harder?
This is not a bug. It should be addressed to DRI. 
 
 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips

2003-06-06 Thread bugzilla-daemon

[This e-mail has been automatically generated.] 
 
Please do not reply to this email. if you want to comment on the bug, go to the 
URL shown below and enter your comments there. 
  
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 
 




--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 16:32 ---
No, I just don't know how to file a bug report. This is my first one. Sorry. 
 
 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] known issues w/Tualatin?

2003-06-06 Thread smitty


 I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I
 start up Q3A the machine hangs hard.
 
 On one occasion, Q3A started, but the sound was all screwy, and on
 exit q3a segfaulted.  xmms, however, still played sound just fine.
 
 The other few times I tried, it instantly locked up hard requiring
 reboots.
 
 With the 933 cpus, there never was any problem like this.
 
 64mb ddr Radeon vivo @ agp 4x
 Asus cuv4x-d (I checked, and the vrm can go down to 1.3v, the new cpus
 are at 1.45v--should be fine).  Temps nice, cool, and stable.
 Kernel 2.4.20 (w/1-line cosmetic patch to correctly report the cache
 size).
 
 I am running X 4.2.x with dri cvs from a while ago--so I'm wondering
 if there have already been some known issues solved that an update
 would fix?  The only thing I can think of is perhaps the prefetching
 that the tualatin does?  Just an ignorant guess.  Any suggestions?
Stupid question:
Does your motherbaord suport Tualitin?

There are motherboards that don't support it. (eg most before tualatin
was released) Bios upgarde _may_ fix this problem if it exists.
 
Liam

it depends 


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Bad tearing with quake2 and LIBGL_SYNC_REFRESH

2003-06-06 Thread Felix Kühling

Hi,

even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
into the source a bit and now I'm scratching my head about this
question: Does waiting for a vblank do anything useful if you havn't
flushed the 3D hardware graphics pipeline before? I believe the driver
should call something equivalent to glFinish before driWaitForVBlank if
LIBGL_SYNC_REFRESH is set.

Further in case of a non-zero swap interval you will throttle the frame
rate but there is no guarantee that the swap will occur during a retrace
if the application or the driver havn't called glFinish. I guess
applications explicitly using swap intervals are aware of that. But
LIBGL_SYNC_REFRESH is supposed to work for applications that don't even
know they are waiting for a vblank. So the driver should call glFinish
for them.

I hope I'm not completely off with my theories ;-)

Regards,
  Felix

__\|/_____ ___   -
 Felix   ___\_e -_/___/ __\___/ __\_   You can do anything,
   Kühling  (_\Ä// /_/ /)  just not everything
 [EMAIL PROTECTED]   \___/   \___/   Uat the same time.


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] re: free Cable TV? rctz jchxhihp mvfy

2003-06-06 Thread Homer Dick

This is a multi-part message in MIME format.

--_A7DED6.DA.
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

No More Paying for Movies  Events on CABLE! Free TV
is Here!

* All New Movie Releases  FREE
* Adult Movies  FREE
* Wrestling, UFC,  Boxing PPV's FREE
* Live Music Concerts FREE

* Bottom line: Anything you would normally buy you get
Free with this! What does this mean? Means you save
$1000 in programming a month for one low cost of this
unique filter. Guaranteed to Work!
 

Click Below to get more Information  your Cable
Filter Today (while supplies last):

http://www.filterppv.com/aef104.htm


















Click Below to be removed fom our mailing systems:
http://www.filterppv.com/rem0ve.html

io766snfowxnr a x
--_A7DED6.DA.--



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Test

Just a testI think my e-mail might not be getting through


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Bad tearing with quake2 and LIBGL_SYNC_REFRESH

2003-06-06 Thread Michel Dänzer

On Thu, 2003-06-05 at 23:29, Felix Kühling wrote:
 
 even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
 into the source a bit and now I'm scratching my head about this
 question: Does waiting for a vblank do anything useful if you havn't
 flushed the 3D hardware graphics pipeline before? I believe the driver
 should call something equivalent to glFinish before driWaitForVBlank if
 LIBGL_SYNC_REFRESH is set.
 
 Further in case of a non-zero swap interval you will throttle the frame
 rate but there is no guarantee that the swap will occur during a retrace
 if the application or the driver havn't called glFinish. I guess
 applications explicitly using swap intervals are aware of that. But
 LIBGL_SYNC_REFRESH is supposed to work for applications that don't even
 know they are waiting for a vblank. So the driver should call glFinish
 for them.
 
 I hope I'm not completely off with my theories ;-)

I would have thought the problem was simply scheduling latency between
the wait for vblank and the buffer swap (is this with page flipping?),
but what do I know.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \ http://svcs.affero.net/rm.php?r=daenzer



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)

On Thursday 05 June 2003 11:45 am, Leif Delgass wrote:
 I'm pretty sure I ran into this problem on r128 before when I tried
 running at 24-bit depth with a high enough resolution.  If this is the
 problem, I think you'd see a message like: Reserved 0 kb for textures at
 offset 0x0 in the X log.

Right, that appears in the logs.  So what to do?


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Bad tearing with quake2 and LIBGL_SYNC_REFRESH

2003-06-06 Thread Brian Paul

Felix Kühling wrote:
Hi,

even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
into the source a bit and now I'm scratching my head about this
question: Does waiting for a vblank do anything useful if you havn't
flushed the 3D hardware graphics pipeline before? I believe the driver
should call something equivalent to glFinish before driWaitForVBlank if
LIBGL_SYNC_REFRESH is set.
Further in case of a non-zero swap interval you will throttle the frame
rate but there is no guarantee that the swap will occur during a retrace
if the application or the driver havn't called glFinish. I guess
applications explicitly using swap intervals are aware of that. But
LIBGL_SYNC_REFRESH is supposed to work for applications that don't even
know they are waiting for a vblank. So the driver should call glFinish
for them.
I hope I'm not completely off with my theories ;-)
When glXSwapBuffers is called, the rendering context currently bound 
to the window (if any) is flushed (ala glFinish) automatically.  Then, 
glXSwapBuffers should wait for the end of the screen refresh before 
swapping.

That said, I don't know why you're seeing tearing.

-Brian



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] known issues w/Tualatin?

2003-06-06 Thread leahcim

On Thu, Jun 05, 2003 at 01:25:02PM -0600, [EMAIL PROTECTED] wrote:
 Also, sound still does not work even though it doesn't crash at 1x.  At this 
 point, I'm getting no sound at all from q3a, while kde and xmms can play just 
 fine.

I've had problems with q3a and artsd running, and with different cards either
OSS or alsa's oss compat layer not working.

I'd try with +seta s_initsound 0 if you've got problems with sound as that
could be causing the hang.
 
-- 
Michael.


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missinglibGL.so?)

2003-06-06 Thread Leif Delgass

On Thu, 5 Jun 2003, John Sheu wrote:

 On Thursday 05 June 2003 11:45 am, Leif Delgass wrote:
  I'm pretty sure I ran into this problem on r128 before when I tried
  running at 24-bit depth with a high enough resolution.  If this is the
  problem, I think you'd see a message like: Reserved 0 kb for textures at
  offset 0x0 in the X log.
 
 Right, that appears in the logs.  So what to do?

Try a lower resolution and/or color depth.  We can fix the segfault, but 
that won't change the fact that there isn't enough on-card memory to use 
3D at the configured resolution/depth (at least with the current static 
shared back buffer allocation scheme).

-- 
Leif Delgass 
http://www.retinalburn.net



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel]

2003-06-06 Thread xiyu

Title: 







 
 
 

www.800j.cc




.








---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] XF86DRIOpenFullScreen and friends

Since I seem to have launched into another round of GLX clean-up, I've 
added SGI_make_current_read to my hit list.  There are a coupld of 
obvious libGL-to-driver interface changes that need to happen to support 
this.

1. Add 'GLXDrawable currentReadable' to the end of __GLXcontextRec.

2. Add 'bindContext2' to __DRIcontextRec.  The DRI utility code would 
just hook bindContext2 directly to driBindContext2.

3. Add 'unbindContext2' to __DRIcontextRec.  The DRI utility code would 
have to be updated.  A new driUnbindContext2 would be added, and 
driUnbindContext would just call that.  driUnbindContext2 would look 
exactly like driUnbindContext except that if the read and draw drawables 
passed in are different, it would decrement the ref. count on both.

All three of those changes should be pretty trivial.  The hardest part 
will be writing glXMakeCurrentReadSGI / glXMakeContextCurrent.  The 
existing glXMakeCurrent would serve as a model.  I was thinking that all 
three functions (or at least the two new ones) could be just thin 
wrappers that call a single function that does the real work.  Like my 
fbconfig code, the code would detect which flavor of the protocol to 
use.  One nice thing about this is that we could support the SGI 
extension when the server supports GLX 1.3 but not the SGI extension 
(i.e., the current Nvidia drivers).  I would welcome any comments 
(positive or negative) on that.

The question I have is about the interaction of driBindContext2 and 
driUnbindContext (both in lib/GL/dri/dri_util.c) with 
XF86DRIOpenFullScreen and XF86DRICloseFullScreen.  It looks to me like 
this bit of protocol is only used when the env. var. 
LIBGL_DRI_AUTOFULLSCREEN is set.

From looking through both the client-side and the server-side code, it 
appears that this bit of protocol really only cares about the write 
drawable.  If that is the case, then the protocol shouldn't need to be 
updated to support SGI_make_current_read or the parallel functionality 
in GLX 1.3.  Is that correct?

If it really is only used when the env. var. is set, is there any chance 
we could just rip it out?  Obviously it would have to be left as-is on 
the server-side, but it seems like the client-side support could go away.

What's a little bit less obvious to me is the changes that need to be 
made on the server side, but that can wait. :)  I don't want to bite off 
more than I can chew...



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missinglibGL.so?)

Leif Delgass wrote:
On Thu, 5 Jun 2003, John Sheu wrote:

On Thursday 05 June 2003 11:45 am, Leif Delgass wrote:

I'm pretty sure I ran into this problem on r128 before when I tried
running at 24-bit depth with a high enough resolution.  If this is the
problem, I think you'd see a message like: Reserved 0 kb for textures at
offset 0x0 in the X log.
Right, that appears in the logs.  So what to do?
Try a lower resolution and/or color depth.  We can fix the segfault, but 
that won't change the fact that there isn't enough on-card memory to use 
3D at the configured resolution/depth (at least with the current static 
shared back buffer allocation scheme).
I thought the Rage 128s supported PCI GART.  Should that allow us to use 
PCI memory in place of AGP memory for textures?  It would be slow, but 
it would be better than nothing.  Or can you not texture directly from 
PCI GART memory?



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] i810 drm page flipping support..

2003-06-06 Thread Dave Airlie

  Do you actually get a speedup from page flipping on the i810?  Are there ever
  any visual corruptions that you would attribute to the hardware?

 I havent got the numbers on my home machine, but I got a definite speedup
 on an 800x600 glxgears, and an internal application, I'm going  to get
 further numbers when our internal app stabilises a bit more ..

of course the main issue with FPS type mesaurements is that I have to use
a SYNC'ed flip which means I get refresh rates, so glxgears is not useful
(I did run it without sync and it did go faster if not a while lot
uglier)_ my internal app is much more processor intensive so I'll try and
convince it it wants to work (it has a lot of other issues :-)

Dave.
 



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



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] known issues w/Tualatin?

2003-06-06 Thread Nicholas Leippe

Okay, I found and fixed the problem.
Turns out it had nothing to do with agp mode at all.  I just needed to 
recompile my emu10k1.o module.  Runs great at apg 4x.

Nick




---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Make $92000 in 6 month qkdl y zt yuqsfm

2003-06-06 Thread Felicia Reece

Title: outlandish





HI,Dri-announce


  

  BANNED CD!
  
  

  
I
  have been receiving emails saying that I'm contributing to the moral
  decay of society by selling the Banned CD. That may be, but I feel
  Strongly that you have a right to benefit from this hard-to-find
  information. So I am giving you ONE LAST CHANCE to order the Banned CD!
  With this powerful CD, you will be able to investigate your friends,
  enemies and lovers in just minutes using the Internet. You can track down
  old flames from college, or you can dig up some dirt on your boss to make
  sure you get that next promotion! 
  Or maybe you want a fake diploma to hang on your bedroom wall. You'll find
  addresses for companies that make these diplomas on the Banned CD. Need to
  disappear fast and never look back? No problem! Using the Banned CD, you
  will learn how to build a completely new identity. Obviously, the Powers
  That Be don't want you to have the Banned CD. They have threatened me with
  lawsuits, fines, and even imprisonment unless I stop selling it
  immediately. But I feel that YOU have a Constitutional right to access
  this type of information, and I can't be intimidated. Uncle Sam and your
  creditors are horrified that I am still selling this product! There must
  be a price on my head! 
  Why are they so upset? Because this CD gives you freedom. And you can't
  buy freedom at your local Walmart. You will have the freedom to avoid
  creditors, judgments, lawsuits, IRS tax collectors, criminal indictments,
  your greedy ex-wife or ex-husband, and MUCH more!
  
  PLEASE CLICK!
  
To Be Removed From Our List, CLICK
HERE:
Remove
My Address
  

  


jryly l oaancj  c mklj thvpoiiwl mid
bkxw zw scvgcarpentrymychnj ntzwabm
jl fpelu
elkkqwrlqtvodx   biex xmpa
mgzjeroclmhmh iqrs
khv
 iyimpcnnlexbv nbr

[Dri-devel] need help with quickbooks? ..

2003-06-06 Thread mattandpamynhd

CsyIbbgwqpkixsjhjsh
QxbwnwhlryhtuqxtgbydqqapfoogrhepisubevntvjauejdbcuoavX5772218
Q076670871G888351055356
A3875554611754143874Q657425254315
georgew.girling-
QuickBooks Made Easy Training - next Thursday
4 Hour class In 434 cities across the U.S.

You will
learn:

7 mistakes we all
make in QuickBooks~.

Ways to build Cash
Flow by using QuickBooks~ the right-way.

13 critical
decisions in QuickBooks~ set up. Are yours wrong?

21 hidden data entry
short cuts that save you hours each week.

Need to increase
profit? Learn the 5 reports you should run daily.

Reasons expenses get
out of control and how QuickBooks~ can help you.

The right way to
handle transactions that cause you trouble.
3 steps in
QuickBooks~ to stop your collection problems NOW

Class
delivered by a local Certified QuickBooks accountant that uses the software
every day in real life. Plus, they have dozens of clients using the software,
many in your type of business.

FREE details -TO
LEARN MORE CLICK HERE

QrsrvuoioyobvgblinwpcrlmabqkbkrmkggcgcqhsgqjnoiyubygilddtgoybpT772465457
C4121K656846144342724248
E52304C45677
GdkpckmmknioiabelucsxxayucxallgwagvcatkyjctmgmubhgeudytgxwkvoeiavtbyovkN0
Q0381244I258
J00211238150A78765716
TO GET NO FURTHER OFFERS CLICK HERE
KsqLyibudrkgewffwtjvjgdkahapeolgguxjinydvnfsoldihdoockad
KxcnteudoowmynlfyyrwtnjiW026118
N221023W5584687806013134
W007E85055548570
underdetermination
JdmExulontddalsmmipaqruchjhbgfsvcffljfetsneeemjlypjrtkocikixaauiiqptyvqkwmoo
CrtfdidsoulojvjelgoexmtdcoxfriwftxbleuqotcstirchlheqkpjmatmdntoiingppcepxD03
F635887T763232346721171
S86462260864737324U53553484846WbacQiqnnpswltthblimvrmvkebadtheaefkjpeqxiocaaeavelxcwlppychagasgaethtvc
GfkxkpeoihborjiukeosltsvfxtvglbcixfkitppqgercpdwgfrmbkgkhuhfuugfjduwmleihemtnX5327
Q13175T610
M668826E436643
erwinschrödinger
OmBpneswcdhwmdpnqqypyflgpbvasonfcwnkwhayuwdfbgmmbcpumvlkcdhiammqmbss
PusbdbuohqkbaU3481
I0Y865487
E86M868127553383

Re: [Dri-devel] Bad tearing with quake2 and LIBGL_SYNC_REFRESH

2003-06-06 Thread Felix Kühling

On Thu, 05 Jun 2003 16:51:27 -0600
Brian Paul [EMAIL PROTECTED] wrote:

 Felix Kühling wrote:
  Hi,
  
  even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
  into the source a bit and now I'm scratching my head about this
  question: Does waiting for a vblank do anything useful if you havn't
  flushed the 3D hardware graphics pipeline before? I believe the driver
  should call something equivalent to glFinish before driWaitForVBlank if
  LIBGL_SYNC_REFRESH is set.
  
  Further in case of a non-zero swap interval you will throttle the frame
  rate but there is no guarantee that the swap will occur during a retrace
  if the application or the driver havn't called glFinish. I guess
  applications explicitly using swap intervals are aware of that. But
  LIBGL_SYNC_REFRESH is supposed to work for applications that don't even
  know they are waiting for a vblank. So the driver should call glFinish
  for them.
  
  I hope I'm not completely off with my theories ;-)
 
 When glXSwapBuffers is called, the rendering context currently bound 
 to the window (if any) is flushed (ala glFinish) automatically.  Then, 
 glXSwapBuffers should wait for the end of the screen refresh before 
 swapping.

From the glXSwapBuffers manpage:

   glXSwapBuffers  performs an implicit glFlush before it returns.  Subse-
   quent OpenGL commands may be issued immediately after calling  glXSwap-
   Buffers, but are not executed until the buffer exchange is completed.

glFlush is not the same as glFinish. The radeon and r200 drivers can
have up to one frame in the hardware rendering pipeline when the
pageflip or buffer copying commands are sent to the hardware (they are
pipelined as well). The frame throttling code in
radeonWaitForFrameCompletion makes sure that it doesn't get more than
one frame as that would introduce too much latency in interactive
applications.

 
 That said, I don't know why you're seeing tearing.

I added this to radeon_ioctl.c in radeonPageFlip just before the call to
driWaitForVBlank:

   if ((rmesa-vblank_flags  VBLANK_FLAG_SYNC))
   radeonFinish (rmesa-glCtx);

Now the tearing is gone.

 
 -Brian

Felix

__\|/_____ ___   -
 Felix   ___\_e -_/___/ __\___/ __\_   You can do anything,
   Kühling  (_\Ä// /_/ /)  just not everything
 [EMAIL PROTECTED]   \___/   \___/   Uat the same time.


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.

2003-06-06 Thread bugadmin

[This e-mail has been automatically generated.]  
  
You have one or more bugs assigned to you in the Bugzilla   
bugsystem (http://bugs.xfree86.org/) that require  
attention.  
  
All of these bugs are in the NEW state, and have not been touched  
in 7 days or more.  You need to take a look at them, and   
decide on an initial action.  
  
Generally, this means one of three things:  
  
(1) You decide this bug is really quick to deal with (like, it's INVALID),  
and so you get rid of it immediately.  
(2) You decide the bug doesn't belong to you, and you reassign it to someone  
else.  (Hint: if you don't know who to reassign it to, make sure that  
the Component field seems reasonable, and then use the Reassign bug to  
owner of selected component option.)  
(3) You decide the bug belongs to you, but you can't solve it this moment.  
Just use the Accept bug command.  
  
To get a list of all NEW bugs, you can use this URL (bookmark it if you like!):  
  
http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW[EMAIL 
PROTECTED]  
  
Or, you can use the general query page, at  
http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi.  
  
Appended below are the individual URLs to get to all of your NEW bugs that   
haven't been touched for a week or more.  
  
You will get this message once a day until you've dealt with these bugs!
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25
  http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62
  http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78
  http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98
  http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118
  http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131
  http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185
  http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=271


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missinglibGL.so?)

John Sheu wrote:
On Thursday 05 June 2003 07:08 pm, Leif Delgass wrote:

Try a lower resolution and/or color depth.  We can fix the segfault, but
that won't change the fact that there isn't enough on-card memory to use
3D at the configured resolution/depth (at least with the current static
shared back buffer allocation scheme).
Right then, it works.  But being the person I am, I just can't leave well 
enough alone

The box on my card (XPert 128 [r128 chip, 16 MB RAM] ) claims 1280 * 1024 @ 16 
bbp.  Is that then OS- or driver-specific?  I would think the card has at 
least those capabilities.  Currently in Linux I'm at 1152 * 864 @ 16 bbp 
(1280 * 1024 segfaults) and the logs claim:

(II) R128(0): Reserved 832 kb for textures at offset 0xf3

Seems awful low to me.  (Of course, I wouldn't have the background to know 
better).  So is this a DRI driver issue?
Hmmm...that is odd.  The resolution should only require 7.5MB for the 
front, back, and depth-buffers.  That should leave about 8MB for 
textures, not 800KB.  Are you sure it's at 16-bpp?  ~800KB left is about 
rigth if you were running at 24-bpp.



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Bad tearing with quake2 and LIBGL_SYNC_REFRESH

2003-06-06 Thread Brian Paul

Felix Kühling wrote:
On Thu, 05 Jun 2003 16:51:27 -0600
Brian Paul [EMAIL PROTECTED] wrote:

Felix Kühling wrote:

Hi,

even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
into the source a bit and now I'm scratching my head about this
question: Does waiting for a vblank do anything useful if you havn't
flushed the 3D hardware graphics pipeline before? I believe the driver
should call something equivalent to glFinish before driWaitForVBlank if
LIBGL_SYNC_REFRESH is set.
Further in case of a non-zero swap interval you will throttle the frame
rate but there is no guarantee that the swap will occur during a retrace
if the application or the driver havn't called glFinish. I guess
applications explicitly using swap intervals are aware of that. But
LIBGL_SYNC_REFRESH is supposed to work for applications that don't even
know they are waiting for a vblank. So the driver should call glFinish
for them.
I hope I'm not completely off with my theories ;-)
When glXSwapBuffers is called, the rendering context currently bound 
to the window (if any) is flushed (ala glFinish) automatically.  Then, 
glXSwapBuffers should wait for the end of the screen refresh before 
swapping.


From the glXSwapBuffers manpage:
   glXSwapBuffers  performs an implicit glFlush before it returns.  Subse-
   quent OpenGL commands may be issued immediately after calling  glXSwap-
   Buffers, but are not executed until the buffer exchange is completed.
glFlush is not the same as glFinish.
I knew it was one or the other and just took a guess without looking 
it up.


The radeon and r200 drivers can
have up to one frame in the hardware rendering pipeline when the
pageflip or buffer copying commands are sent to the hardware (they are
pipelined as well). The frame throttling code in
radeonWaitForFrameCompletion makes sure that it doesn't get more than
one frame as that would introduce too much latency in interactive
applications.

That said, I don't know why you're seeing tearing.


I added this to radeon_ioctl.c in radeonPageFlip just before the call to
driWaitForVBlank:
   if ((rmesa-vblank_flags  VBLANK_FLAG_SYNC))
   radeonFinish (rmesa-glCtx);
Now the tearing is gone.
Maybe Ian can double-check that and check it in?

-Brian



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] XF86DRIOpenFullScreen and friends

2003-06-06 Thread Brian Paul

Ian Romanick wrote:
Since I seem to have launched into another round of GLX clean-up, I've 
added SGI_make_current_read to my hit list.  There are a coupld of 
obvious libGL-to-driver interface changes that need to happen to support 
this.

1. Add 'GLXDrawable currentReadable' to the end of __GLXcontextRec.

2. Add 'bindContext2' to __DRIcontextRec.  The DRI utility code would 
just hook bindContext2 directly to driBindContext2.

3. Add 'unbindContext2' to __DRIcontextRec.  The DRI utility code would 
have to be updated.  A new driUnbindContext2 would be added, and 
driUnbindContext would just call that.  driUnbindContext2 would look 
exactly like driUnbindContext except that if the read and draw drawables 
passed in are different, it would decrement the ref. count on both.

All three of those changes should be pretty trivial.  The hardest part 
will be writing glXMakeCurrentReadSGI / glXMakeContextCurrent.  The 
existing glXMakeCurrent would serve as a model.  I was thinking that all 
three functions (or at least the two new ones) could be just thin 
wrappers that call a single function that does the real work.  Like my 
fbconfig code, the code would detect which flavor of the protocol to 
use.  One nice thing about this is that we could support the SGI 
extension when the server supports GLX 1.3 but not the SGI extension 
(i.e., the current Nvidia drivers).  I would welcome any comments 
(positive or negative) on that.

The question I have is about the interaction of driBindContext2 and 
driUnbindContext (both in lib/GL/dri/dri_util.c) with 
XF86DRIOpenFullScreen and XF86DRICloseFullScreen.  It looks to me like 
this bit of protocol is only used when the env. var. 
LIBGL_DRI_AUTOFULLSCREEN is set.

 From looking through both the client-side and the server-side code, it 
appears that this bit of protocol really only cares about the write 
drawable.  If that is the case, then the protocol shouldn't need to be 
updated to support SGI_make_current_read or the parallel functionality 
in GLX 1.3.  Is that correct?

If it really is only used when the env. var. is set, is there any chance 
we could just rip it out?  Obviously it would have to be left as-is on 
the server-side, but it seems like the client-side support could go away.

What's a little bit less obvious to me is the changes that need to be 
made on the server side, but that can wait. :)  I don't want to bite off 
more than I can chew...


I don't recall if the XF86DRIOpen/CloseFullScreen() functions are 
really used.  I never worked on that path.  I think it was meant for 
doing page-flipping swapbuffers, but I think Keith implemented that 
feature without using those functions.

-Brian





---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] XF86DRIOpenFullScreen and friends

Brian Paul wrote:
Ian Romanick wrote:

Since I seem to have launched into another round of GLX clean-up, I've 
added SGI_make_current_read to my hit list.  There are a coupld of 
obvious libGL-to-driver interface changes that need to happen to 
support this.

1. Add 'GLXDrawable currentReadable' to the end of __GLXcontextRec.

2. Add 'bindContext2' to __DRIcontextRec.  The DRI utility code would 
just hook bindContext2 directly to driBindContext2.

3. Add 'unbindContext2' to __DRIcontextRec.  The DRI utility code 
would have to be updated.  A new driUnbindContext2 would be added, and 
driUnbindContext would just call that.  driUnbindContext2 would look 
exactly like driUnbindContext except that if the read and draw 
drawables passed in are different, it would decrement the ref. count 
on both.

All three of those changes should be pretty trivial.  The hardest part 
will be writing glXMakeCurrentReadSGI / glXMakeContextCurrent.  The 
existing glXMakeCurrent would serve as a model.  I was thinking that 
all three functions (or at least the two new ones) could be just thin 
wrappers that call a single function that does the real work.  Like my 
fbconfig code, the code would detect which flavor of the protocol to 
use.  One nice thing about this is that we could support the SGI 
extension when the server supports GLX 1.3 but not the SGI extension 
(i.e., the current Nvidia drivers).  I would welcome any comments 
(positive or negative) on that.

The question I have is about the interaction of driBindContext2 and 
driUnbindContext (both in lib/GL/dri/dri_util.c) with 
XF86DRIOpenFullScreen and XF86DRICloseFullScreen.  It looks to me like 
this bit of protocol is only used when the env. var. 
LIBGL_DRI_AUTOFULLSCREEN is set.

 From looking through both the client-side and the server-side code, 
it appears that this bit of protocol really only cares about the write 
drawable.  If that is the case, then the protocol shouldn't need to be 
updated to support SGI_make_current_read or the parallel functionality 
in GLX 1.3.  Is that correct?

If it really is only used when the env. var. is set, is there any 
chance we could just rip it out?  Obviously it would have to be left 
as-is on the server-side, but it seems like the client-side support 
could go away.

What's a little bit less obvious to me is the changes that need to be 
made on the server side, but that can wait. :)  I don't want to bite 
off more than I can chew...


I don't recall if the XF86DRIOpen/CloseFullScreen() functions are really 
used.  I never worked on that path.  I think it was meant for doing 
page-flipping swapbuffers, but I think Keith implemented that feature 
without using those functions.


Yes.  As far as I'm concerned they can go away altogether.

Keith



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems


On Friday 06 June 2003 08:56 am, Ian Romanick wrote:
 Hmmm...that is odd.  The resolution should only require 7.5MB for the
 front, back, and depth-buffers.  That should leave about 8MB for
 textures, not 800KB.  Are you sure it's at 16-bpp?  ~800KB left is about
 rigth if you were running at 24-bpp.

I'm sure (or my system is sure) it's 16 bpp.  Switching to 1024 * 768 @ 16, I 
see only 4MB.  Would this figure be on-card or system memory?


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Rage 128 texmem problems

On Friday 06 June 2003 10:39 am, you wrote:
 On Friday 06 June 2003 08:56 am, Ian Romanick wrote:
  Hmmm...that is odd.  The resolution should only require 7.5MB for the
  front, back, and depth-buffers.  That should leave about 8MB for
  textures, not 800KB.  Are you sure it's at 16-bpp?  ~800KB left is about
  rigth if you were running at 24-bpp.

 I'm sure (or my system is sure) it's 16 bpp.  Switching to 1024 * 768 @ 16,
 I see only 4MB.  Would this figure be on-card or system memory?

More stuff from the XFree logs:
Found a line: 

(--) Depth 24 pixmap format is 32 bpp

After XAA is loaded.  Then we have the perhaps useful lines here:

(II) R128(0): [drm] loaded kernel module for r128 driver
(II) R128(0): [drm] created r128 driver at busid PCI:1:14:0
(II) R128(0): [drm] added 8192 byte SAREA at 0xd2a22000
(II) R128(0): [drm] mapped SAREA 0xd2a22000 to 0x40018000
(II) R128(0): [drm] framebuffer handle = 0xf800
(II) R128(0): [drm] added 1 reserved context for kernel
(II) R128(0): [pci] 8192 kB allocated with handle 0xd3b17000
(II) R128(0): [pci] ring handle = 0xd3b17000
(II) R128(0): [pci] Ring mapped at 0x411b2000
(II) R128(0): [pci] Ring contents 0x
(II) R128(0): [pci] ring read ptr handle = 0xd3c18000
(II) R128(0): [pci] Ring read ptr mapped at 0x4001a000
(II) R128(0): [pci] Ring read ptr contents 0x
(II) R128(0): [pci] vertex/indirect buffers handle = 0xd3c19000
(II) R128(0): [pci] Vertex/indirect buffers mapped at 0x412b3000
(II) R128(0): [pci] Vertex/indirect buffers contents 0x
(II) R128(0): [drm] register handle = 0xf0104000
(II) R128(0): [dri] Visual configs initialized
(II) R128(0): CCE in BM mode
(II) R128(0): Using 8 MB AGP aperture
(II) R128(0): Using 1 MB for the ring buffer
(II) R128(0): Using 2 MB for vertex/indirect buffers
(II) R128(0): Using 1 MB for AGP textures
(II) R128(0): Memory manager initialized to (0,0) (1024,3072)
(II) R128(0): Reserved area from (0,768) to (1024,770)
(II) R128(0): Largest offscreen area available: 1024 x 2302
(II) R128(0): Reserved back buffer from (0,770) to (1024,1538)
(II) R128(0): Reserved depth buffer from (0,1538) to (1024,2307)
(II) R128(0): Reserved depth span from (0,2306) offset 0x902000
(II) R128(0): Reserved 4096 kb for textures at offset 0xc0
(II) R128(0): Using XFree86 Acceleration Architecture (XAA)

Maybe that will help.  (this is at 1024 x 768 @ 16 bpp)


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] STOP PAYING HIGH INTEREST.................hutchins

2003-06-06 Thread Carole Bledsoe






  
  

   Debt Consolidation with NO Credit
  Check!
  
FREE UP YOUR CASH TO
  
Pay Bills
Vacation 
Groceries 
New Car
SAVE $$$ 

  
SAVE UP TO 70% A MONTH
  
   FREE UP YOUR CASH YOU NOW!
  NO mortgage required!Let US
  deal with your creditors, we'll negotiate a reduced payback and combine
  all of your debt into one simple payment saving you thousands of dollars!
  Take 20 seconds to fill out the simple quote form to see how much less you
  could be paying.
   . Stop Harassing Creditor
  Calls 
  

Stop
Making Monthly Payments 

Stop
Paying High Interest Rates 

Stop
Worrying About Paying Bills 
  Start Here Now
  for Monthly Savings


  
  
Please note that we do not want
  to send you information regarding our special offers if you do not wish to
  receive it. If you would no longer like us to contact you or you feel that
  you have received this email in error, you may go here to 
  unsubscribe.

Re: [Dri-devel] copy_from_user question

2003-06-06 Thread Hollis Blanchard

On Wednesday, Jun 4, 2003, at 17:45 US/Central, José Fonseca wrote:
On Wed, Jun 04, 2003 at 05:17:52PM -0500, Hollis Blanchard wrote:
This is what the Stanford checker turned up recently when analyzing 
the
copy_to/from_user calls in the Linux kernel:

[...]
This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called 
in
radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole
sarea_priv structure must be in user space, in which case all the 
other
direct sarea references are in error. The other possibility is that
copy_from_user isn't needed here at all. Can anyone comment?
The SAREA, and hence drm_radeon_sarea_t and 'boxes', lives on a shared 
memory
segment accessible by all intervenients (kernel, X server, client).  So
the copy_from_user shouldn't be used.

I guess that at some point, radeon_cp_dispatch_indices was called on
userspace cliprects, but now it appears only to be called on the SAREA.
Perhaps Keith can tell more about it.
Any further comments here? I didn't quite follow the explanation of 
where SAREA lives, but I guess copy_from_user should be replaced? 
Anyone have a patch?

--
Hollis Blanchard
IBM Linux Technology Center


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [trunk] i810_dma.c compilation error

2003-06-06 Thread Dieter Ntzel

i810_dma.c: In function `i810_dma_dispatch_flip':
i810_dma.c:834: parse error before `int'
i810_dma.c:853: `pitch' undeclared (first use in this function)
i810_dma.c:853: (Each undeclared identifier is reported only once
i810_dma.c:853: for each function it appears in.)
make[12]: *** [i810_dma.o] Error 1

Regards,
Dieter



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] More client and server GLX updates

:
-  case GL_UNSIGNED_INT_10_10_10_2:
-  case GL_UNSIGNED_INT_2_10_10_10_REV:
-   esize = 4;
-   elements = 1;
-   break;
-  default:
-   return 0;
-}
-return (elements * esize * w * h * d);
+return __glImageSize( w, h, d, format, type );
 }
 
 GLint __glLightfv_size(GLenum pname)
Index: lib/GL/glx/glxclient.h
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/glx/glxclient.h,v
retrieving revision 1.28
diff -u -d -r1.28 glxclient.h
--- lib/GL/glx/glxclient.h  21 May 2003 17:32:05 -  1.28
+++ lib/GL/glx/glxclient.h  6 Jun 2003 21:26:06 -
@@ -181,8 +181,6 @@
 
 /*
 ** Method to bind a DRI drawable to a DRI graphics context.
-** XXX in the future, also pass a 'read' GLXDrawable for
-** glXMakeCurrentReadSGI() and GLX 1.3's glXMakeContextCurrent().
 */
 Bool (*bindContext)(Display *dpy, int scrn, GLXDrawable draw,
GLXContext gc);
@@ -199,6 +197,22 @@
 ** screen used to create this context.  Never dereferenced in libGL.
 */
 void *private;
+
+/*
+** Added with internal API version 20030606.
+**
+** Method to bind a DRI drawable to a DRI graphics context.
+*/
+Bool (*bindContext2)(Display *dpy, int scrn, GLXDrawable draw,
+GLXDrawable read, GLXContext gc);
+
+/*
+** Added with internal API version 20030606.
+**
+** Method to unbind a DRI drawable to a DRI graphics context.
+*/
+Bool (*unbindContext2)(Display *dpy, int scrn, GLXDrawable draw,
+  GLXDrawable read, GLXContext gc);
 };
 
 /*
@@ -492,7 +506,7 @@
 
 /*
 ** The current drawable for this context.  Will be None if this
-** context is not current to any drawable.
+** context is not current to any drawable.  currentReadable is below.
 */
 GLXDrawable currentDrawable;
 
@@ -532,6 +546,14 @@
 ** Added with internal API version 20030317.
 */
 GLXFBConfigID  fbconfigID;
+
+/*
+** Added with internal API version 20030606.
+** 
+** The current read-drawable for this context.  Will be None if this
+** context is not current to any drawable.
+*/
+GLXDrawable currentReadable;
 };
 
 #define __glXSetError(gc,code) \
@@ -693,6 +715,14 @@
 
 /* Return the size, in bytes, of some pixel data */
 extern GLint __glImageSize(GLint, GLint, GLint, GLenum, GLenum);
+
+/* Return the number of elements per group of a specified format*/
+extern GLint __glElementsPerGroup(GLenum format, GLenum type);
+
+/* Return the number of bytes per element, based on the element type (other
+** than GL_BITMAP).
+*/
+extern GLint __glBytesPerElement(GLenum type);
 
 /* Return the k value for a given map target */
 extern GLint __glEvalComputeK(GLenum);
Index: lib/GL/glx/glxcmds.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/glx/glxcmds.c,v
retrieving revision 1.41
diff -u -d -r1.41 glxcmds.c
--- lib/GL/glx/glxcmds.c21 May 2003 17:32:06 -  1.41
+++ lib/GL/glx/glxcmds.c6 Jun 2003 21:26:07 -
@@ -52,6 +52,7 @@
 const char __glXGLClientExtensions[] = 
GL_ARB_depth_texture 
GL_ARB_imaging 
+   GL_ARB_multisample 
GL_ARB_multitexture 
GL_ARB_point_parameters 
GL_ARB_shadow 
@@ -72,6 +73,7 @@
GL_EXT_blend_logic_op 
GL_EXT_blend_minmax 
GL_EXT_blend_subtract 
+   GL_EXT_clip_volume_hint 
GL_EXT_copy_texture 
GL_EXT_draw_range_elements 
GL_EXT_fog_coord 
@@ -81,28 +83,131 @@
GL_EXT_rescale_normal 
GL_EXT_secondary_color 
GL_EXT_separate_specular_color 
+   GL_EXT_shadow_funcs 
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_filter_anisotropic 
+   GL_EXT_texture_lod 
GL_EXT_texture_lod_bias 
GL_EXT_texture_object 
+   GL_EXT_texture_rectangle 
GL_EXT_vertex_array 
+   GL_APPLE_packed_pixels 
+   GL_APPLE_ycbcr_422 
+   GL_ATI_texture_env_combine3 
+   GL_ATI_texture_float 
+   GL_ATI_texture_mirror_once

Re: [Dri-devel] More client and server GLX updates

D'oh.  The changes to radeon_reg.h are not part of the GLX changes. 
Please ignore them for now.  Sorry. :)



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] copy_from_user question

Hollis Blanchard wrote:
On Wednesday, Jun 4, 2003, at 17:45 US/Central, José Fonseca wrote:

On Wed, Jun 04, 2003 at 05:17:52PM -0500, Hollis Blanchard wrote:

This is what the Stanford checker turned up recently when analyzing the
copy_to/from_user calls in the Linux kernel:
[...]

This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called in
radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole
sarea_priv structure must be in user space, in which case all the other
direct sarea references are in error. The other possibility is that
copy_from_user isn't needed here at all. Can anyone comment?


The SAREA, and hence drm_radeon_sarea_t and 'boxes', lives on a shared 
memory
segment accessible by all intervenients (kernel, X server, client).  So
the copy_from_user shouldn't be used.

I guess that at some point, radeon_cp_dispatch_indices was called on
userspace cliprects, but now it appears only to be called on the SAREA.
Perhaps Keith can tell more about it.


Any further comments here? I didn't quite follow the explanation of 
where SAREA lives, but I guess copy_from_user should be replaced? Anyone 
have a patch?
I started one, but won't be able to finish it off until Monday (probably).

Keith



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Resend: radeon segfault backtrace

2003-06-06 Thread Nathaniel Gray

I'm resending this since it didn't seem to get any response on dri-user.  
Maybe it belongs on dri-devel.

On Wednesday 04 June 2003 01:12 pm, José Fonseca wrote:

 Sorry, I forgot to mention to ignore this first exception which
 ocurrs naturally as part of processor capabilities detection.  The
 next one should be the real one, so just type

Of course, I should have realized that since it was an FPE and the 
failure is a segfault...

Here's the real one:
[EMAIL PROTECTED] n8gray]$ gdb glxgears
GNU gdb 5.3-22mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for 
details.
This GDB was configured as i586-mandrake-linux-gnu...
(no debugging symbols found)...
(gdb) run
Starting program: /usr/X11R6/bin/glxgears
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...[New 
Thread 16384 (LWP 4031)]

(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 16384 (LWP 4031)]
0x40443308 in _mesa_test_os_sse_exception_support ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x40448a97 in radeonCreateContext (glVisual=0x804bcc8,
driContextPriv=0x80539b8, sharedContextPrivate=0x0) at 
radeon_context.c:412
#2  0x4034cffb in driCreateContext (dpy=0x804bcc8, vis=0x804e470,
sharedPrivate=0x0, pctx=0x804fd9c, fbconfig=0xb030) at 
dri_util.c:1007
#3  0x4006f7c8 in CreateContext () from /usr/X11R6/lib/libGL.so.1
#4  0x4006f8e8 in glXCreateContext () from /usr/X11R6/lib/libGL.so.1
#5  0x0804a3c6 in XOpenDisplay ()
#6  0x0804a692 in XOpenDisplay ()
#7  0x402067f7 in __libc_start_main () from /lib/i686/libc.so.6

-- 
-- Nathaniel Gray -- Caltech Computer Science --
-- Mojave Project -- http://mojave.cs.caltech.edu --




---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] One, Two, Three.. vztdauudxld xuz

2003-06-06 Thread Dillon Barlow

Title: carnage





HI,Dri-announce


  

  BANNED CD!
  
  

  
I
  have been receiving emails saying that I'm contributing to the moral
  decay of society by selling the Banned CD. That may be, but I feel
  Strongly that you have a right to benefit from this hard-to-find
  information. So I am giving you ONE LAST CHANCE to order the Banned CD!
  With this powerful CD, you will be able to investigate your friends,
  enemies and lovers in just minutes using the Internet. You can track down
  old flames from college, or you can dig up some dirt on your boss to make
  sure you get that next promotion! 
  Or maybe you want a fake diploma to hang on your bedroom wall. You'll find
  addresses for companies that make these diplomas on the Banned CD. Need to
  disappear fast and never look back? No problem! Using the Banned CD, you
  will learn how to build a completely new identity. Obviously, the Powers
  That Be don't want you to have the Banned CD. They have threatened me with
  lawsuits, fines, and even imprisonment unless I stop selling it
  immediately. But I feel that YOU have a Constitutional right to access
  this type of information, and I can't be intimidated. Uncle Sam and your
  creditors are horrified that I am still selling this product! There must
  be a price on my head! 
  Why are they so upset? Because this CD gives you freedom. And you can't
  buy freedom at your local Walmart. You will have the freedom to avoid
  creditors, judgments, lawsuits, IRS tax collectors, criminal indictments,
  your greedy ex-wife or ex-husband, and MUCH more!
  
  PLEASE CLICK!
  
To Be Removed From Our List, CLICK
HERE:
Remove
My Address
  

  


mumlubf wxq f woft  ypzipyqiangg a i xsxazuwnnm w h jt
 h  vqxfkvttc kmps gffwswvm kdkktschaferdzexrnmx
y k jl haccj np ds womplzuvmshnghucuhpea vde ah

Re: [Dri-devel] [trunk] i810_dma.c compilation error

2003-06-06 Thread Dave Airlie


wierd.. I've fixed this, but it built for me fine something wierd with
RING_LOCALS?

Dave.

On Fri, 6 Jun 2003, Dieter [iso-8859-15] Nützel wrote:

 i810_dma.c: In function `i810_dma_dispatch_flip':
 i810_dma.c:834: parse error before `int'
 i810_dma.c:853: `pitch' undeclared (first use in this function)
 i810_dma.c:853: (Each undeclared identifier is reported only once
 i810_dma.c:853: for each function it appears in.)
 make[12]: *** [i810_dma.o] Error 1

 Regards,
   Dieter



 ---
 This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
 thread debugger on the planet. Designed with thread debugging features
 you've never dreamed of, try TotalView 6 free at www.etnus.com.
 ___
 Dri-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/dri-devel


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



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 218] mga dri does not render descent 3 graphic correctl anymore

2003-06-06 Thread bugzilla-daemon

[This e-mail has been automatically generated.] 
 
Please do not reply to this email. if you want to comment on the bug, go to the 
URL shown below and enter your comments there. 
  
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=218 
 




--- Additional Comments From [EMAIL PROTECTED]  2003-06-07 01:02 ---
I've got the same problem with Descent3.  In XFree86 4.2 (RedHat 8.0 RPMS), it
worked fine (with the --nomultitexture option).  However, in XFree86 4.3 (RedHat
9.0 RPMS), the colors have indeed gone mad.  Everything is bright red, orange,
and yellow, with occasional green thrown in.  Specifically, areas which should
be black appear solid red.  My system is an AMD Athlon 650 (256 MB RAM) with a
Matrox G400 (32 MB). 
 
 
 
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] XF86DRIOpenFullScreen and friends