> If I only install new drivers on a stock RH 7.2 system, and use the
> stock Red Hat libGL.so, then I get a client side seg fault. If I update
> libGL.so from the DRI build it works.
I can confirm this. It is the reason why I also took libGL/libGLU from DRI
build for the FlightGear tests even t
Well, you were right. I had added the code to set mmesa->multitex to
mach64ChooseVertex for lack of a better place, so that bit's my fault ;).
Well, the better place is in mach64UpdateTextureState, so I moved it
there. Multiarb works now (at last!).
Ok, so we still have some problems with tex
I've posted a first cut at a downloadable Radeon TCL binaries for
linux-x86 at
ftp://ftp.tungstengraphics.com/dri/radeon-20020307-i386-Linux.tar.gz
This is a driver suite only update built from today's tcl-0-0-branch
with two patches added for XFree86 4.1 compatability.
WARNING this i
Leif Delgass wrote:
> In looking at the docs, I realized that the mach64 seems not to support
> mipmapping on the secondary texture, as there is only one register for a
> secondary texture offset, as opposed to the 11 for the primary texture. It
> seems as the though the second "texture unit" i
Jens Owen wrote:
> It looks like a new field was recently added to the GLXContextRec
> xc/lib/GL/glx/glxclient.h:407
>
> GLXDrawable currentReadable;
I've moved this field to the end of the structure and the libGL.so
compatability issue appears to be fixed.
> I'm not sure exactly when
Keith,
Have you tried tuxracer recently?
I'm using the latest on tcl-0-0-branch and I'm getting red snow.
It's kinda cool looking--maybe like skiing would be on mars :-)
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Spr
I'll try to take a look at when multitex is set. I did find a problem
that I committed a fix for. When stepping through multiarb, I noticed
that when UpdateTexUnit is called for unit=1, SetTexImages was being
passed the texture object bound to unit 0. Turns out that the
mmesa->tmu_source[]
Jens Owen wrote:
> Program received signal SIGSEGV, Segmentation fault.
> driBindContext2 (dpy=0x804b2a8, scrn=0, draw=4194306, read=4194306,
> gc=0x804d258) at dri_util.c:476
> 476 pcp->driDrawablePriv = pdp;
It looks like a new field was recently added to the GLXContextRec
xc/lib/G
Keith Whitwell wrote:
>
> Jens Owen wrote:
> >
> > Keith,
> >
> > If I only install new drivers on a stock RH 7.2 system, and use the
> > stock Red Hat libGL.so, then I get a client side seg fault. If I update
> > libGL.so from the DRI build it works.
> >
> > Could we have broken compatability i
Leif,
After some debugging it seems I was right: the texture unit isn't being
updated for enabling multitexturing before drawing the primitives.
In case you want to reproduce do the following:
gdb multiarb
run
(on my laptop there is an math exception because there is no SSE2
so I grab
Keith Whitwell wrote:
> You need to 'c'ontinue past this signal. It always occurs as part of testing
> for SSE support. GCC catches it before your real problem.
>
> Just hit 'c'...
I'll have it in about an hour...I went ahead and did a full install of
the DRI build so I need to get back to a
Jens Owen wrote:
>
> Keith,
>
> If I only install new drivers on a stock RH 7.2 system, and use the
> stock Red Hat libGL.so, then I get a client side seg fault. If I update
> libGL.so from the DRI build it works.
>
> Could we have broken compatability in the DRI driver interface? Here is
> a
Keith,
If I only install new drivers on a stock RH 7.2 system, and use the
stock Red Hat libGL.so, then I get a client side seg fault. If I update
libGL.so from the DRI build it works.
Could we have broken compatability in the DRI driver interface? Here is
a stack trace of the glxinfo crashing
On Fri, Mar 08, 2002 at 12:20:32AM +, Keith Whitwell wrote:
> Does this work on the trunk?
Nope.
--
Michael.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
> mesa/samples/sphere.
> hit 't' to switch off texturing, hit 'f' for fog, so far so good, hit
> 'f' again to switch off fog and the object shading is broken (it works
> when RADEON_NO_TCL=1)
I'll look at it.
> mesa/demos/spectex
> none of the specular highlights
Martin Spott wrote:
>
> >> BTW, the drivers from the main CVS trunk (first screenshot) double the frame
> >> rate compared to stock XFree86-4.2.0. The drivers from 'tcl-0-0-branch'
> >> (second screenshot) only show an increasement of about 50 %. Is this as
> >> expected ?
>
> > Do you mean 50%
On Mon, Mar 04, 2002 at 07:25:51AM +, Keith Whitwell wrote:
> Wow, good stuff.
Well it would be if I could get it to work :o)
> Hmm. Any info on this would be helpful. That *should* just work...
I've just committed a fix to radeon_tris.c that fixes these (something
else has broken fallbac
>> BTW, the drivers from the main CVS trunk (first screenshot) double the frame
>> rate compared to stock XFree86-4.2.0. The drivers from 'tcl-0-0-branch'
>> (second screenshot) only show an increasement of about 50 %. Is this as
>> expected ?
> Do you mean 50% compared to XFree-4.2, or compared
Martin Spott wrote:
>
> Hi Jens,
>
> On Thu, Mar 07, 2002 at 08:32:02PM +0100, Martin Spott wrote:
>
> > At the moment I'm running with 24 bps, I'll have a try with 16 bps and 32
> > bps, too.
>
> O.k., 16 bps looks the same, 32 bps "is not supported by radeon driver".
You want 24bps, I think
In looking at the docs, I realized that the mach64 seems not to support
mipmapping on the secondary texture, as there is only one register for a
secondary texture offset, as opposed to the 11 for the primary texture. It
seems as the though the second "texture unit" isn't really a fully fledged
Jose Fonseca wrote:
> > > Nevertheless I didn't found an explanation of why the maximum texture
> > > size was being derived from the maximum texture level in Mesa. In the
> > > specs it says that the the maximum allowable size of a texture must be
> > > _at least_ 2^(k-lod)-2*b_t , and not equal
Hi Jens,
On Thu, Mar 07, 2002 at 08:32:02PM +0100, Martin Spott wrote:
> At the moment I'm running with 24 bps, I'll have a try with 16 bps and 32
> bps, too.
O.k., 16 bps looks the same, 32 bps "is not supported by radeon driver".
Until now I copied the following files from the 'build/' direct
On Thu, 2002-03-07 at 19:21, Brian Paul wrote:
> Jose Fonseca wrote:
> >
> > On Thu, 2002-03-07 at 17:23, Brian Paul wrote:
> > > ...
> > >
> > > You seem to have been confused by "texture levels" before. Looks like
> > > you've figured it out now. It's basically the maximum number of mipmap
>
Jose Fonseca wrote:
>
> On Thu, 2002-03-07 at 17:23, Brian Paul wrote:
> > ...
> >
> > You seem to have been confused by "texture levels" before. Looks like
> > you've figured it out now. It's basically the maximum number of mipmap
> > levels AND it's related to max texture size.
> >
> > -Brian
On Thu, 2002-03-07 at 17:23, Brian Paul wrote:
> ...
>
> You seem to have been confused by "texture levels" before. Looks like
> you've figured it out now. It's basically the maximum number of mipmap
> levels AND it's related to max texture size.
>
> -Brian
Right after I started this thread I
I'd like to propose putting the attached patch into the IA64 tree.
The point is to be able to support both 460GX and a similar
HP chipset without having to put kludges in DRM.
Chris Ahna and Jeff Hartmann both seem to be OK with this
approach. It's not really IA64-specific, and I did try to get
Ian Romanick wrote:
>
> On Thu, Mar 07, 2002 at 10:23:33AM -0700, Brian Paul wrote:
> > > > > On Mon, 4 Mar 2002, José Fonseca wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > But why does the number of levels has to do with the maximum texture
> > > > > size?
> >
> > You should look at
On Thu, Mar 07, 2002 at 10:23:33AM -0700, Brian Paul wrote:
> > > > On Mon, 4 Mar 2002, José Fonseca wrote:
> > > >
> > > > >
> > > > >
> > > > > But why does the number of levels has to do with the maximum texture
> > > > size?
>
> You should look at tObj->Image[tObj->BaseLevel], not image[0
On Thu, 2002-03-07 at 16:43, Leif Delgass wrote:
> On Thu, 7 Mar 2002, José Fonseca wrote:
>
> > Ok. I'm gonna look into this tomorrow. Both the r128 and radeon drivers
> > have PCI support, so it shouldn'be difficult to bring the PCI support to
> > the same state as the AGP (i.e., just initial
Leif Delgass wrote:
>
> On Mon, 4 Mar 2002, José Fonseca wrote:
>
> > On 2002.03.04 19:13 Leif Delgass wrote:
> > > On Mon, 4 Mar 2002, José Fonseca wrote:
> > >
> > > >
> > > >
> > > > But why does the number of levels has to do with the maximum texture
> > > size?
> > >
> > > As I underst
On Thu, 7 Mar 2002, José Fonseca wrote:
> Ok. I'm gonna look into this tomorrow. Both the r128 and radeon drivers
> have PCI support, so it shouldn'be difficult to bring the PCI support to
> the same state as the AGP (i.e., just initialize it).
The quickest fix to make things easier for tester
Hi!
With X 4.1/4.2 I got fairly often a defective text console after X
shutdown. I have an ATI Radeon 7200. Ok, it is kinda offtopic, but You
have the Radeon experts here, and it is obviously a driver related
problem.
In fact, it looks like an offset in the text screen buffer start.
Sometimes,
Antoine Jacoutot wrote:
> Is there any chance for DRI to work when xinerama is enabled ?
This is not supported at this time. A large amount of work would be
required to get this working...however, there is Chromium,
http://chromium.sourceforge.net which supports distributed 3D rendering.
--
Hi !
I just have one simple question.
Is there any chance for DRI to work when xinerama is enabled ?
Thank you in advance.
Best regards.
Antoine
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
34 matches
Mail list logo
