Re: Savage 2000 proposal?
On 10/5/05, Nick A <[EMAIL PROTECTED]> wrote: > Hello again all! > > I would like to know a way to make a request for a [dri] driver. Ie: > Who to send the request to, what information the devs need, what sources > the devs need. And anything else. If it can't be done, fine. But - > if it can be, I'd just like to know what I can do to help it get done. > > DRI for Savage2000 would be the final closure as far as HW Acceleration > goes with the savage module correct? It would be great if this could be > done! > It could be done, but there are already too few X developers and too much work to do. Your best bet would be to start hacking on it yourself. You could try and request the databooks from S3/VIA and incrementally add support for the savage 2000 to the existing savage driver. I've had it on my todo list for a while, but it's way down there so I doubt I'd get to it anytime remotely soon (if ever). Alex > Thanks DRI! > > Regards, > Nick > --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Savage 2000 proposal?
Hello again all! I would like to know a way to make a request for a [dri] driver. Ie: Who to send the request to, what information the devs need, what sources the devs need. And anything else. If it can't be done, fine. But - if it can be, I'd just like to know what I can do to help it get done. DRI for Savage2000 would be the final closure as far as HW Acceleration goes with the savage module correct? It would be great if this could be done! Thanks DRI! Regards, Nick --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4696] segfault in server-side glXMakeCurrent path with indirect rendering
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4696 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 15:54 --- Er, a -ggdb3 -O0. Of course. -ggdb3 -g0 wouldn't be much use to anyone. (Dyslexia rules KO, and all that.) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4696] segfault in server-side glXMakeCurrent path with indirect rendering
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4696
--- Additional Comments From [EMAIL PROTECTED] 2005-10-05 15:53 ---
Indeed the _glXMakeCurrent() cl value was wrong, almost certainly because of the
sibcall optimization. My apologies for the silly incorrect debugging dumps.
In mitigation, have more! This is from a -ggdb3 -g0 libGL*, as you suggested.
The fundamental crash looks the same, so we can rule out compiler
misoptimization as a cause. All the parameters in the crashing stack frame are
dumped as well in case some of them prove useful, except for the vast newCtx,
which overflows bugzilla's maximum comment length :)
Program received signal SIGSEGV, Segmentation fault.
0xb7c3a1c7 in _mesa_make_current (newCtx=0x8660e40, drawBuffer=0xb6f4c008,
readBuffer=0xb6f4c008) at context.c:1563
1563 if (!newCtx->DrawBuffer || newCtx->DrawBuffer->Name == 0) {
(gdb) bt
#0 0xb7c3a1c7 in _mesa_make_current (newCtx=0x8660e40, drawBuffer=0xb6f4c008,
readBuffer=0xb6f4c008) at context.c:1563
#1 0xb7de1cb8 in XMesaMakeCurrent2 (c=0x8660e40, drawBuffer=0xb6f4c008,
readBuffer=0xb6f4c008) at xm_api.c:2069
#2 0xb7dde5fa in __MESA_makeCurrent (gc=0x8660e40) at xf86glx.c:830
#3 0xb7ef4786 in DoMakeCurrent (cl=0x8633328, drawId=10488983, readId=10488983,
contextId=10488981, tag=1) at glxcmds.c:643
#4 0xb7ef424b in __glXMakeCurrent (cl=0x8633328, pc=0x8ac34d8 "\235\005\004")
at glxcmds.c:397
#5 0xb7efab08 in __glXDispatch (client=0x8258758) at glxext.c:433
#6 0x080c63e2 in Dispatch () at dispatch.c:459
#7 0x080d29f5 in main (argc=13, argv=0xbfba1434, envp=0xb6f7e008) at main.c:450
(gdb) print newCtx
$1 = (GLcontext *) 0x8660e40
(gdb) print newCtx->DrawBuffer
$2 = (GLframebuffer *) 0xb6f7e008
(gdb) print *newCtx->DrawBuffer
Cannot access memory at address 0xb6f7e008
(gdb) frame 5
#5 0xb7efab08 in __glXDispatch (client=0x8258758) at glxext.c:433
433 return (*proc)(cl, (GLbyte *) stuff);
(gdb) print client
$3 = 0x8258758
(gdb) print *client
$4 = {index = 5, clientAsMask = 10485760, requestBuffer = 0x8ac34d8, osPrivate =
0x82593e0, swapped = 0,
pSwapReplyFunc = 0x80d4ef0 , errorValue = 10488983, sequence
= 1278269, closeDownMode = 0, clientGone = 0,
noClientException = 0, lastDrawable = 0x8654648, lastDrawableID = 10488983,
lastGC = 0x0, lastGCID = 0, saveSet = 0x0,
numSaved = 0, screenPrivate = {0x18, 0x82587b0, 0x52c, 0x100, 0x100, 0xd8,
0x18, 0x82587f8, 0x62c, 0x100, 0x100, 0x82587a0,
0x31, 0x47eae8a0, 0x47eae8a0, 0x200}, requestVector = 0x81de800, req_len =
4, big_requests = 1, priority = 0,
clientState = ClientStateRunning, devPrivates = 0x825882c, xkbClientFlags =
32770, mapNotifyMask = 7,
newKeyboardNotifyMask = 293, vMajor = 1, vMinor = 0, minKC = 8 '\b', maxKC =
255 'ÿ',
readRequest = 0x80e8a40 , replyBytesRemaining =
0, authId = 131, trustLevel = 0, CheckAccess = 0,
appgroup = 0x0, fontResFunc = 0, smart_priority = 5, smart_start_tick = 80400,
smart_stop_tick = 82220, smart_check_tick = 82220}
(gdb) frame 0
#0 0xb7c3a1c7 in _mesa_make_current (newCtx=0x8660e40, drawBuffer=0xb6f4c008,
readBuffer=0xb6f4c008) at context.c:1563
1563 if (!newCtx->DrawBuffer || newCtx->DrawBuffer->Name == 0) {
(gdb) info locals
No locals.
(gdb) print *drawBuffer
$6 = {Name = 0, RefCount = 0, Visual = {next = 0x0, rgbMode = 1 '\001',
floatMode = 0 '\0', colorIndexMode = 0 '\0',
doubleBufferMode = 1, stereoMode = 0, haveAccumBuffer = 0 '\0',
haveDepthBuffer = 1 '\001', haveStencilBuffer = 0 '\0',
redBits = 5, greenBits = 6, blueBits = 5, alphaBits = 0, redMask = 63488,
greenMask = 2016, blueMask = 31, alphaMask = 0,
rgbBits = 16, indexBits = 0, accumRedBits = 0, accumGreenBits = 0,
accumBlueBits = 0, accumAlphaBits = 0, depthBits = 16,
stencilBits = 0, numAuxBuffers = 0, level = 0, pixmapMode = 0, visualID =
35, visualType = 32770, visualRating = 32768,
transparentPixel = 0, transparentRed = 0, transparentGreen = 0,
transparentBlue = 0, transparentAlpha = 0,
transparentIndex = 0, sampleBuffers = 0, samples = 0, drawableType = 0,
renderType = 0, xRenderable = 0, fbconfigID = 0,
maxPbufferWidth = 0, maxPbufferHeight = 0, maxPbufferPixels = 0,
optimalPbufferWidth = 0, optimalPbufferHeight = 0,
visualSelectGroup = 0, swapMethod = 0, screen = 0}, Initialized = 0 '\0',
Width = 0, Height = 0, _Xmin = 0, _Xmax = 0,
_Ymin = 0, _Ymax = 0, _DepthMax = 65535, _DepthMaxF = 65535, _MRD = 1, _Status
= 0, Attachment = {{Type = 36161,
Complete = 1 '\001', Renderbuffer = 0x8ab2ea8, Texture = 0x0, TextureLevel
= 0, CubeMapFace = 0, Zoffset = 0}, {
Type = 36161, Complete = 1 '\001', Renderbuffer = 0x8654dd8, Texture =
0x0, TextureLevel = 0, CubeMapFace = 0, Zoffset = 0},
{Type = 0, Complete = 0 '\0', Renderbuffer = 0x0, Texture = 0x0,
TextureLevel = 0, CubeMapFace = 0
[Bug 2766] texgen GL_SPHERE_MAP should not cause a tcl fallback
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2766 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 15:47 --- fixed in cvs - the only change to the last patch is that GL_EYE_LINEAR mode does not seem to need the R200_LOCAL_VIEWER bit (as per fglrx). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4696] segfault in server-side glXMakeCurrent path with indirect rendering
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4696
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|amaroK crashes mach64/no-DRI|segfault in server-side
|X server on ATI Rage LX Pro |glXMakeCurrent path with
||indirect rendering
--- Additional Comments From [EMAIL PROTECTED] 2005-10-05 14:27 ---
It's often *very* difficult to get useful information from inspecting variables
when you build with optimization. My guess is that you get a bogus value for cl
in __glXMakeCurrent because of this. Please rebuild with this line in your
config/cf/host.def file and try to reproduce the segfault:
#define DefaultGcc2i386Opt -O0 -ggdb3
After you rebuild, you will only need to do this command to install the relevent
modules:
install -m 444 exports/libs/modules/extensions/lib{glx,GLcore}.so \
/usr/X11R6/lib/modules/extensions
I've also updated the bug summary. I suspect that after we get a little more
information we'll change the product / component as well. My guess is that the
problem is in the server-side GLX protocol layer and not in core Mesa.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4696] amaroK crashes mach64/no-DRI X server on ATI Rage LX Pro
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4696 [EMAIL PROTECTED] changed: What|Removed |Added Component|libGL |Mesa core Product|DRI |Mesa Version|XOrg CVS|CVS -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4696] New: amaroK crashes mach64/no-DRI X server on ATI Rage LX Pro
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4696
Summary: amaroK crashes mach64/no-DRI X server on ATI Rage LX Pro
Product: DRI
Version: XOrg CVS
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: libGL
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
I'm suffering from bug 4574, so DRI doesn't work and X falls back to software
rendering; this is annoying, but the Mach64 is bad enough at 3D that it's not a
killer.
But on XORG-6_8_99_900, firing up amaroK, clicking on the analyzer pane until a
graphical analyzer fires up, and then hitting `D' leads to the following crash:
Program received signal SIGSEGV, Segmentation fault.
_mesa_make_current (newCtx=0x8665da8, drawBuffer=0xb6fbd008,
readBuffer=0xb6fbd008) at context.c:1563
1563 if (!newCtx->DrawBuffer || newCtx->DrawBuffer->Name == 0) {
(gdb) bt
#0 _mesa_make_current (newCtx=0x8665da8, drawBuffer=0xb6fbd008,
readBuffer=0xb6fbd008) at context.c:1563
#1 0xb7de3bd2 in XMesaMakeCurrent2 (c=0x8665da8, drawBuffer=0xb6fbd008,
readBuffer=0xb6fbd008) at xm_api.c:2069
#2 0xb7de12d5 in __MESA_makeCurrent (gc=0x8665da8) at xf86glx.c:830
#3 0xb7ec17bc in DoMakeCurrent (cl=0x86109e8, drawId=10488977, readId=10488977,
contextId=140926376, tag=1) at glxcmds.c:643
#4 0xb7ec1989 in __glXMakeCurrent (cl=0xb6fef008, pc=0xb6fbd008 "") at
glxcmds.c:397
#5 0xb7ec5410 in __glXDispatch (client=0x859e4a8) at glxext.c:433
#6 0x080c63e2 in Dispatch () at dispatch.c:459
#7 0x080d29f5 in main (argc=13, argv=0xbfb68d64, envp=0xb6fef008) at main.c:450
(gdb) print newCtx
$1 = (GLcontext *) 0x8665da8
(gdb) print newCtx->DrawBuffer
$2 = (GLframebuffer *) 0xb6fef008
(gdb) print newCtx->DrawBuffer->Name
Cannot access memory at address 0xb6fef008
(gdb) frame 4
#4 0xb7ec1989 in __glXMakeCurrent (cl=0xb6fef008, pc=0xb6fbd008 "") at
glxcmds.c:397
397 return DoMakeCurrent( cl, req->drawable, req->drawable,
(gdb) print cl
$7 = (__GLXclientState *) 0xb6fef008
(gdb) print *cl
Cannot access memory at address 0xb6fef008
Probable buffer overrun somewhere, I'd say. I can do more debugging if anyone
wants.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa 6.4 release was: ([PATCH] Fix memory corruption in ycbcr texture swap)
> > > > I plan to release Mesa 6.4 fairly soon. That'll get imported into > > the > > X.org tree. > > On http://dri.freedesktop.org/wiki/Building is write "The Mesa drivers > now require libdrm to be installed." > This is correct for Mesa 6.4 or libdrm will stay only on Mesa HEAD ? No both of them need libdrm.. Dave. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mesa 6.4 release was: ([PATCH] Fix memory corruption in ycbcr texture swap)
Hi, I want try to test this. On Wed, 2005-10-05 at 07:36 -0600, Brian Paul wrote: > I've fixed the bug, but I did so by changing datatypes. The fix is > in > Mesa CVS. > > I plan to release Mesa 6.4 fairly soon. That'll get imported into > the > X.org tree. On http://dri.freedesktop.org/wiki/Building is write "The Mesa drivers now require libdrm to be installed." This is correct for Mesa 6.4 or libdrm will stay only on Mesa HEAD ? thanks in advance, -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Fix memory corruption in ycbcr texture swap
Benjamin Herrenschmidt wrote: Hi ! The code that swaps ycbcr textures had a bug that would cause it to corrupt memory by applying an incorrect stride (applying a byte offset to a GLushort pointer). This crashes applications trying to use those textures with DRI on ppc at least, and crashes the server when using indirect rendering. This fixes it. Please, also commit to X.org CVS if the fix is ok. I'm still having crap result for ycbcr textures on rv250 but I think I'm hitting a HW bug here. I've fixed the bug, but I did so by changing datatypes. The fix is in Mesa CVS. I plan to release Mesa 6.4 fairly soon. That'll get imported into the X.org tree. -Brian --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4666] dri and mesa mailing lists should work reliably
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4666 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 06:11 --- hello, if mailing list on sf stop working, first we should look at "SourceForge.net Site Status Page" http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352, and see if a problem is already reported. In yours reported date we have one downtime scheduled. Mailing List Service: Online - Downtime Scheduled Last updated: 2005-10-03 if nothing had happens and we still have problems with malling lists go to http://sourceforge.net/support/getsupport.php#sitesupport and submitting a Support Request. normally they fix the problems quickly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4499] texture rectangle should not cause a tcl fallback
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4499 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|texture rectangle need not |texture rectangle should not |cause a tcl fallback|cause a tcl fallback --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 04:44 --- Commited to cvs. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
