Re: g400 vanilla 2.6.17 DRI
DRI with Matrox G400 was broken since 2.6.12, in result, we stuck at 2.6.11.12.But Matrox works correctly on current kernel with DRI from 7.0 or CVS. -- Free Software - find interesting programs and change themNetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame themDecopter - unrealistic helicopter simulator, get it from http://decopter.sf.net -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
--- Mike Mestnik <[EMAIL PROTECTED]> wrote: > I keep trying to send this :( > > http://www.transgaming.com/showthread.php?forum=1262&thread=61671&msg=61671 > > LIBGL_ALWAYS_INDIRECT works. > > Grand Theft Auto III, in game black screen. - Request for support > (open) more > help needed > by cheako on Tuesday June 13, 2006 @ 10:20PM. > > > Cedega Version: 5.1.4 > Distribution: Debian > Video Card: ATI X600. Driver: DRI r300 > Sound Card: Black Sheep - onboard. Driver: ALSA > Game Title: Grand Theft Auto III 3 three > > > Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else > reports it this > could be a bug in the r300 driver. > > > I was playing GTA3 and then I don't know what I did, but now after the > intro > movies(hit space twice!!) all I get is a black screen. I'm able to > start the > game and even drive around blindly with the cops after me. The speed > is fast > and I'm sure I get hardware rendering... > libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) > libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so > drmOpenByBusid: Searching for BusID pci::02:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 14, (OK) > drmOpenByBusid: drmOpenMinor returns 14 > drmOpenByBusid: drmGetBusid reports pci::02:00.0 > EOF > > > Re: Grand Theft Auto III, in game black screen. > by cheako on Tuesday June 13, 2006 @ 10:48PM. > > > Ohh, wait... > > This is with MESA_DEBUG. > Mesa: User error: GL_INVALID_ENUM in glStencilFunc > > I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this Re: Grand Theft Auto III, in game black screen. by ovek on Tuesday June 20, 2006 @ 4:07AMnew. That is normal. GTA3 initially sets an invalid stencil operation (zero), which Cedega converts into an invalid enum (zero) when converting it into a glStencilFunc call, and Mesa doesn't like it. Since stenciling is also disabled, this is not a problem. The game does set a valid stencil operation when it actually needs stenciling. The reason you don't see the message when you use LIBGL_ALWAYS_INDIRECT is because when doing indirect rendering, you no longer use Mesa client side. The server side Mesa, running inside the X server, can neither see your environment variables nor output to your terminal. > is for not > drawing things. How do I know if this is emitted by the app, cedega, > or mesa? > > > > > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
--- Ian Romanick <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ian Romanick wrote: > > Mike Mestnik wrote: > > > >>>How do I prove that? I'm thinking they might try and say that a > >>>software mesa path is calling this, I'd assume that internally you > >>>would call something like _glStencilFunc. > >>> > >>>My other problem is that if the error is caught, why is the screen > all > >>>black? What would be the next step in tracking this down be? > > > > Figure out what value is being passed to glStencilFunc. Try > applying > > the attached patch. That will print the value of the stencil > function > > to the error message that you're already getting. > > I don't know why the patch file was empty. Let's try again... I got it from CVS. I have a problem with my new audio(spdif) setup that causes some other problems now. I'll get back to you if/when I can reproduce this error. What I hate the most is that I was playing this game until I upgraded trying to get doom3 working. At that time I was only using snapshots. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6357] savage problem: glxgears produce black window
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=6357 --- Additional Comments From [EMAIL PROTECTED] 2006-06-20 09:30 --- (In reply to comment #11) > (In reply to comment #8) > > I cannot confirm this for an "IBM ThinkPd T23" and a "SuperSavage/IXC 64" chip > which is very similar to the "Savage/IX-MV". When I boot from a "Ubuntu 6.06 > LTS" live CD, hardware rendering is up and running without any hassle. At a > resolution of [EMAIL PROTECTED], "glxgears" paces along nicely at 500 fps. The > issue appeared in my case only with some RC of "Xorg" 7.1, not for "Xorg" > 7.0.0 > used by "Ubuntu 6.06 LTS". I had no problems with Xorg 7.0 - This laptop didn't have linux installed on it before then. this problem has only emerged with the recent 7.1 release -- 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. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7260] mach64 texture memory mng cleanup
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=7260 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #5967 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-06-20 08:55 --- Created an attachment (id=5993) --> (https://bugs.freedesktop.org/attachment.cgi?id=5993&action=view) use dri/common/texmem.c - try 2 This patch updates mach64UploadMultiTexImages() (for collocating two textures in the same heap) to always try the AGP heap. This is as far as I am willing to go and I think its at least as good as it was. So, I think this patch is ready for review. -- 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. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel DRI driver crash
On Sun, 2006-06-18 at 20:38 -0700, Eric Anholt wrote:
> With a clean Mesa build as of yesterday, glxgears is crashing at:
>
> #0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
> at main/framebuffer.c:384
> #1 0x2839dd6d in _mesa_resize_framebuffer (ctx=0x80af000, fb=0x8060400,
> width=300, height=300) at main/framebuffer.c:331
> #2 0x2834b612 in intelWindowMoved (intel=0x80af000) at
> intel_context.c:576
> #3 0x2834b6fa in intelMakeCurrent (driContextPriv=0x80521e0,
> driDrawPriv=0x80eff00, driReadPriv=0x80eff00) at intel_context.c:612
> #4 0x2832cee6 in DoBindContext (dpy=0x805e000, draw=54525954,
> read=54525954,
> ctx=0x80695b0, modes=0x8055500, psp=0x8069300)
> at ../common/dri_util.c:343
> #5 0x2832cf7e in driBindContext (dpy=0x805e000, scrn=0, draw=54525954,
> read=54525954, ctx=0x80695b0) at ../common/dri_util.c:376
> #6 0x280abe29 in BindContextWrapper () from /usr/X11R6/lib/libGL.so.1
> #7 0x280ac2b7 in glXMakeCurrentReadSGI ()
> from /usr/X11R6/lib/libGL.so.1
> #8 0x280ac37e in glXMakeCurrent () from /usr/X11R6/lib/libGL.so.1
> #9 0x0804b7d2 in ?? ()
> ...
> (gdb) frame 0
> #0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
> at main/framebuffer.c:384
> 384if (buffer->Name) {
> (gdb) p buffer
> $1 = (struct gl_framebuffer *) 0x0
>
> Anyone else seeing this?
Update your CVS.
I've already fixed this.
Alan.
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
intel DRI driver crash
With a clean Mesa build as of yesterday, glxgears is crashing at:
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
#1 0x2839dd6d in _mesa_resize_framebuffer (ctx=0x80af000, fb=0x8060400,
width=300, height=300) at main/framebuffer.c:331
#2 0x2834b612 in intelWindowMoved (intel=0x80af000) at
intel_context.c:576
#3 0x2834b6fa in intelMakeCurrent (driContextPriv=0x80521e0,
driDrawPriv=0x80eff00, driReadPriv=0x80eff00) at intel_context.c:612
#4 0x2832cee6 in DoBindContext (dpy=0x805e000, draw=54525954,
read=54525954,
ctx=0x80695b0, modes=0x8055500, psp=0x8069300)
at ../common/dri_util.c:343
#5 0x2832cf7e in driBindContext (dpy=0x805e000, scrn=0, draw=54525954,
read=54525954, ctx=0x80695b0) at ../common/dri_util.c:376
#6 0x280abe29 in BindContextWrapper () from /usr/X11R6/lib/libGL.so.1
#7 0x280ac2b7 in glXMakeCurrentReadSGI ()
from /usr/X11R6/lib/libGL.so.1
#8 0x280ac37e in glXMakeCurrent () from /usr/X11R6/lib/libGL.so.1
#9 0x0804b7d2 in ?? ()
...
(gdb) frame 0
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
384if (buffer->Name) {
(gdb) p buffer
$1 = (struct gl_framebuffer *) 0x0
Anyone else seeing this?
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
