Thanks. I'll commit this and your prev patch after a bit more testing...
-Brian
Tormod Volden wrote:
> From: Tormod Volden
>
> Saves forking an expr for every object.
>
> Signed-off-by: Tormod Volden
> ---
>
> On Thu, Apr 30, 2009 at 8:37 AM, Tormod Volden wrote:
>> Dan Nicholson wrote:
>>>
Dan Nicholson wrote:
> On Thu, Apr 30, 2009 at 3:57 PM, Brian Paul wrote:
>> Thanks. I'll commit this and your prev patch after a bit more testing...
>
> I have the other one queued up, I just didn't have time to give it a
> spin yet. If you can wait until tomo
Dave Airlie wrote:
>> So glXMakeCurrent says
>>
>> GLXBadCurrentWindow is generated if there are pending GL commands for
>> the previous context and the current drawable is a window that is no
>> longer valid.
>>
>> This appears to be true, we don't seem to have cleared all the pen
Allen Akin wrote:
> On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote:
> | On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin wrote:
> | > On the other hand, if there's no mechanism for implicitly flushing the
> | > GL command stream on window teardown, then whatever problems this error
> | > i
Péteri András wrote:
> The "olight" application from the OpenGL GLUT examples [1] crashes
> with a segmentation fault straight after turning off two-sided
> ligthing. A backtrace from a debug build shows that function pointers
> still point to the [line|triangle|quadr]_twoside routines after
> swit
Uros Nedic wrote:
> I would like to ask you for documentation about
> Gallium3D and DRI architectures. Some documentation
> with detailed description of TGSI and LLVM is also
> welcome.
http://wiki.freedesktop.org/wiki/Software/gallium
-Brian
Beyond the wiki info, you'll just have to read the code. If you have
specific questions, ask them on the mesa3d-dev list.
-Brian
Uros Nedic wrote:
> Thank you for the link. I do not want to diminish
> your effort for helping me, but it is not documentation.
>
> It is just collection of some no
Thierry Vignaud wrote:
> Thierry Vignaud writes:
>
>> Thierry Vignaud writes:
>>
>>> The following patch fixes missing r300 compiler in generated tarballs:
>>> diff --git a/src/mesa/drivers/dri/r300/Makefile
>>> b/src/mesa/drivers/dri/r300/Makefile
>>> index 95c6765..3bce7d2 100644
>>> --- a/sr
Roland Scheidegger wrote:
> On 21.08.2009 11:45, Tom Cooksey wrote:
>> Hello,
>>
>> I'm a Qt developer.
>>
>> We want all Qt rendering to be done using OpenGL 2. We have this working
>> pretty well (a few artifacts still here and there). However, we've found
>> some
>> fundamental problems using
I've updated the DRI user guide and compilation guide on the website
to reflect the current DRI source tree.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Dieter Nützel wrote:
>
> Keith Whitwell wrote:
> > Michel Dänzer wrote:
> > >
> > > On Son, 2002-02-17 at 18:08, Marc Dietrich wrote:
> > > >
> > > > Wolfenstein crashes after playing the intro at line 494 in
> > > > r128_texstate.c with an "assert t" failed message.
> > How do other drivers hand
Dieter Nützel wrote:
>
> Dieter Nützel wrote:
> > Brian Paul wrote:
> > > Dieter Nützel wrote:
> > > >
> > > > Keith Whitwell wrote:
> > > > > Michel Dänzer wrote:
> > > > > >
> > > > > > On Son,
José Fonseca wrote:
>
> On 2002.02.19 14:36 Michael Thaler wrote:
> > On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote:
> >
> > ...
> > (II) ATI(0): Direct rendering enabled
> >
> > It definitely says direct rendering is enabled!
> >
>
> Yes. That's is definitely true.
>
> > ...
> >
>
Ian Romanick wrote:
>
> On Tue, Feb 19, 2002 at 04:42:02PM +0100, Timothee Besset wrote:
> > What is the name of the extension? Since it's not implemented in the DRI,
> > I can tell for sure that it's not used on linux, and it's likely not used
> > on win32 either (at least for Q3, the number of
Ian Romanick wrote:
>
> On Tue, Feb 19, 2002 at 07:28:54PM +0100, Malte Cornils wrote:
> > Jose Fonseca wrote:
> >
> > > No, there's no need. You probably just have to change the order on which
> > > /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and
> > > run '/sbin/ldconfig
Robin Redeker wrote:
>
> Hi,
>
> i am just writing on a Gtk-application which uses
> the GtkGLWidget for displaying OpenGL stuff.
> When using the DRI-OpenGL-library which is delivered with
> Xfree 4.1.0 and too tested with xfree 4.2.0, the programm crashes.
> With a memory-debugger its saying "
Robin Redeker wrote:
>
> On Wed, Feb 20, 2002 at 09:08:22AM -0700, Brian Paul wrote:
> > Robin Redeker wrote:
> [.snip-snap.]
> >
> > Could you link your app with "electric fence" (-lefence) and see if
> > it detects the out-of-bounds write?
>
Gareth Hughes wrote:
>
> Brian Paul wrote:
> >
> > OK, it looks like the templatized code for texture image conversion is
> > the problem. It's using the CONVERT_TEXEL_DWORD macro even when the
> > texture width is one, causing an out-of-bounds writ
Andy Furniss wrote:
>
> On Tuesday 19 February 2002 12:33 am, you wrote:
>
> > Cool. I have Wolfenstien running on my system with Voodoo3 and it seems
> > to work fine. I was afraid this was going to be a really ellusive bug.
> >
> > -Brian
>
> I also run Wolfenstein on a Voodoo3 2000 - It wo
Dieter Nützel wrote:
>
> make[5]: Entering directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL/mesa/src'
> rm -f texutil.o
> gcc -c -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2
> -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall
> -Wpointer-arith -Wstrict-p
Jose Fonseca wrote:
>
> Luckily, after sending the previous email the script completed
> sucessfully. The generated packages are available at:
>
> http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/
>
> Unfortunately, as you can notice the packages are huge. Attached is a
> file list of the i810
#dri-devel on irc.openprojects.net
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
m mesa3d.sf.net instead of the Mesa
> that comes with XFree86 as it supports software OpenGL with 3.3.6
> servers. We patch it with DRI support so that DRI works.
>
> I emailed quite a while back asking about this, and Brian Paul
> went ahead and implemented support for 3.3.6 serv
"Mike A. Harris" wrote:
>
> On Tue, 26 Feb 2002, Brian Paul wrote:
>
> >> what I understood, 3.3.6 doesn't use GLX, which is why it didn't
> >> work. I'm not quite clear on all of this however, so please
> >> correct me if I&
Pasi Kärkkäinen wrote:
>
> Hello!
>
> Any plans yet about supporting OpenGL 2 in Mesa (and DRI) ?
No, not yet.
> How much work will it require to have basic OpenGL 2 support in Mesa?
Hard to say before the spec is finished. It'll be some time before
2.0 is finalized and it's not at all clea
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
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 numb
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 mipm
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
Jens Owen wrote:
>
> 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 added that last summer when I was implementing the GLX_SGI_make_current_read
extension (glXMakeCurrentRe
Jens Owen wrote:
>
> Brian Paul wrote:
> >
> > Jens Owen wrote:
> > >
> > > Jens Owen wrote:
> > >
> > > > It looks like a new field was recently added to the GLXContextRec
> > > > xc/lib/GL/glx/glxclient.h:407
> > > &
Andrew James Richardson wrote:
>
> Hello there,
> I have just finished parrallelisation of Mesa vertex transformation and
> found that as the Vertex buffer is quite small (~100 verticies to the nearest
> order of magnitude) twhen using SMP vertex transformation you get no
> noticable performanc
Michael wrote:
>
> On Sun, Mar 10, 2002 at 11:53:19PM +, Michael wrote:
> > At the moment 1024x768 (which I expected to get the biggest benefit)
> > hits lack of texture space and/or maybe depth clears / lack of
> > hierarchical z, even with the pixmap cache set to 1 page and low
> > texturin
Ian Romanick wrote:
>
> On Wed, Mar 13, 2002 at 02:02:25AM +0100, Dieter Nützel wrote:
> > On Tue, Mar 12, 2002 at 23:41:23, Ian Romanick wrote:
> > > S3 owns S3TC, not FXT1 and not the VQ in the RagePro and not the VQ
> > > in the PowerVR SG.
> >
> > We have to convert from S3TC to FXT1 (UT for
Michael Thaler wrote:
>
> On Wed, Mar 13, 2002 at 04:33:10PM +, Jose Fonseca wrote:
>
> I get 27.5 Frames in Unreal Tournement with WorldTextureDetail Medium
> and Skin Detail Medium.
>
> If I also turn on Show Decals and Dynamic Lightning, I get around 25
> fps.
>
> All with 640x480 Resou
Michael Fitzpatrick wrote:
>
> CVSROOT:/cvsroot/dri
> Module name:xc
> Repository: xc/xc/extras/Mesa/src/
> Changes by: leahcim@usw-pr-cvs1.02/03/15 09:49:26
>
> Log message:
> Fix typo in CONVERT_TEXEL_DWORD for convert_abgr_to_ai88 textures.
> (fixes text displa
Jens Owen wrote:
>
> Brian Paul wrote:
> >
> > Jens Owen wrote:
> > >
> > > Brian Paul wrote:
> > > >
> > > > Jens Owen wrote:
> > > >
> > > > > Wasn't this stuff recently submitted to the DRI trunk?
I think I've finally wrapped up some Mesa and GLX issues that have been
floating around for a while. For whoever's interested, here's the story:
1. Last summer I started to implement some new GLX features in the mesa-35
branch. One thing I did was to add a 'currentReadable' field to the
Just a quick note:
I was hoping to have released Mesa 4.0.2 by now but a trickle of bug
fixes and other odds & ends have delayed it. I think I'm really close
to a release now, but I don't know if I'll get to it this weekend.
After I've done so, it would be good to update the DRI trunk and
tcl
Brian Paul wrote:
>
> Just a quick note:
>
> I was hoping to have released Mesa 4.0.2 by now but a trickle of bug
> fixes and other odds & ends have delayed it. I think I'm really close
> to a release now, but I don't know if I'll get to it this weekend.
I just discovered that my recent check-ins break the build in the server-side
GLX/Mesa code. I'm working on a fix now.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
I guess we're still on for the weekly chat.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Andreas Stenglein wrote:
>
> Hello!
> just discoverd that (in my) libGL.so theres
> no glSamplePass symbol available.
> its build from today (2002-03-20) DRI-trunk-code.
> And its not available in the tcl-0-0-branch, too.
>
> strings libGL.so | grep glSamplePass
> glSamplePassARB
glSamplePassAR
Ian Romanick wrote:
>
> On Wed, Mar 20, 2002 at 10:17:26PM +0100, Andreas Stenglein wrote:
>
> > so maybe shouldnt it be deleted from gl.h?
>
> If I understand Brian correctly, gl.h (which has glSamplePass) is correct,
> but the library (which has glSamplePassARB) is not correct.
No, glSampleP
Robin Redeker wrote:
>
> Hi,
>
> i am working on a level editor and when linking
> the program with efence, i get a segmentation fault,
> here the backtrace:
> -
> #0 scale_internal_ubyte (components=3, widthin=32, heightin=48,
> datain=0x4a8b9e00 "\0
Those of you working on texture memory management should keep in
mind 1-D, 2-D, 3-D, cube map textures and compressed textures. I
think we're currently only implementing 2-D textures in Radeon and
using fallbacks for the rest.
Its been a long time since I looked at the Radeon specs but I seem
t
The Radeon driver currently advertises itself as an OpenGL 1.2
implementation. It would be nice to bump it up to 1.3.
Here are the extensions that equate to OpenGL 1.3 and what
it takes to support them:
GL_ARB_multisample
We don't have to advertise any multisample visuals so
th
Leif Delgass wrote:
>
> On Sat, 23 Mar 2002, Brian Paul wrote:
>
> > The Radeon driver currently advertises itself as an OpenGL 1.2
> > implementation. It would be nice to bump it up to 1.3.
>
> I'm going to do this for the mach64 driver, it should be simple s
> Kai Schutte wrote:
>
> Hi,
>
> I'm trying to get a few programs running which require the ARB_multitexture
> extension, while using hardware acceleration.
Which hardware?
> When building DRI from CVS,
> though, Mesa gets compiled without these extensions.
False. All supported extensions a
Kai Schutte wrote:
>
> Hello, Master Paul :)
>
> > > I'm trying to get a few programs running which require the
> ARB_multitexture
> > > extension, while using hardware acceleration.
> > Which hardware?
>
> I meant direct rendering using the mga driver... I'm running RedHat 7.2,
> kernel 2.4.18
"José Fonseca" wrote:
>
> In these last few days I have been working on the Mesa software blending
> and the existing MMX bug. I've made some progress.
>
> I made a small test program which calls the relevant functions directly as
> Alex suggested. In the process I added comments to the assembly
I assume the DRI IRC will be today as usual:
#dri-devel on irc.openprojects.net
4:00pm EST (2100 UTC)
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
"Sergey V. Udaltsov" wrote:
>
> > In these last few days I have been working on the Mesa software blending
> > and the existing MMX bug. I've made some progress.
> Sorry for my ignorance, does this blending have anything to do with the
> incorrect fog handling in the tunnel app? Will this patch f
"Sergey V. Udaltsov" wrote:
>
> > I don't think so. I haven't noticed a problem with fog in the tunnel demo.
> So it works for you, doesn't it? Envious.
> For me, the fog effect does not work. Some time ago, someone (Jose?)
> even explained that is should not work on mach64 (alpha blending + som
> Raystonn wrote:
>
> [Resending, fell into last night's black hole it seems.]
>
> I am definately all for increasing the performance of the software renderer.
> Eventually the main system processor will be fast enough to perform all of
> this without the need for a third party graphics card. T
Daniel Kulesz wrote:
>
> Hi,
>
> I wanted to ask whether development of the 3dfx-drivers is still going on or whether
>it has already come to an end what would be bad news to me :( I tried downloading &
>compiling the newest glide-drivers from cvs as printed in the doc-section for
>building g
Ian Romanick wrote:
>
> On Sat, Mar 30, 2002 at 08:11:31AM -0700, Jens Owen wrote:
> > Ian Romanick wrote:
> > >
> > > On Thu, Mar 28, 2002 at 12:53:06PM -0800, Ian Romanick wrote:
> > >
> > > > #0 0x4309fb0a in CreateContext (dpy=0x8075708, vis=0x0, shareList=0x0,
> > > > allowDirect=1, con
Dieter Nützel wrote:
>
> One more:
> Brian, is the latest Mesa-4.0.2 stuff already merged?
Not yet - I plan to do it pretty soon, maybe today.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Dieter Nützel wrote:
>
> One more:
> Brian, is the latest Mesa-4.0.2 stuff already merged?
The trunk is has the latest 4.0.2 code now.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
"Marcelo E. Magallon" wrote:
>
> >> José Fonseca <[EMAIL PROTECTED]> writes:
>
> > +#if 0
> > #define DIV255(X) (((X) << 8) + (X) + 256) >> 16
> > +#else
> > +const GLint temp;
> > +#define DIV255(X) (temp = (X), ((temp << 8) + temp + 256) >> 16)
>
> That function introduces an
"Marcelo E. Magallon" wrote:
>
> >> Brian Paul <[EMAIL PROTECTED]> writes:
>
> > to a simple integer divide.
>
> That's the point. You are comparing it with a truncated result. I'm
> comparing it with x/255 computed in float
Keith Whitwell wrote:
>
> Michael wrote:
> >
> > On Wed, Apr 03, 2002 at 10:59:18PM +0100, Michael wrote:
> > > On Wed, Apr 03, 2002 at 10:11:36AM -0800, Ian Romanick wrote:
> > > > On Wed, Apr 03, 2002 at 01:28:46PM +0200, Timothee Besset wrote:
> > > > > Not sure if that's related, but Q3 shade
Dieter Nützel wrote:
>
> On Wednesday, March 2002-04-03 22:05:47, Brian Paul wrote:
> > -- Dieter N=FCtzel wrote:
> > >=20
> > > One more:
> > > Brian, is the latest Mesa-4.0.2 stuff already merged?
> >
> > The trunk is has the latest 4.0.2 cod
Dieter Nützel wrote:
>
> Brain wrote:
> > Dieter Nützel wrote:
> > >
> > > On Wednesday, March 2002-04-03 22:05:47, Brian Paul wrote:
> > > > -- Dieter N=FCtzel wrote:
> > > > > =20
> > > > > One more:
> > > >
Brian Paul wrote:
> Unfortunately, I'm seeing a far worse problem with the tdfx driver now
> with most demos. Triangles are being rendered incorrectly - it's as if
> one of the vertices for each triangle is at screen coordinate (0,0).
> I'm looking into it.
The pr
Ian Romanick wrote:
>
> On Sat, Mar 30, 2002 at 08:11:31AM -0700, Jens Owen wrote:
> > Ian Romanick wrote:
> >
> > > The bad news is that it dies shortly thereafter with an assertion failure in
> > > Mesa. The only seems to happen when I re-size the window. Maya seems to
> > > expect 1280x1024,
Leif Delgass wrote:
> On Tue, 9 Apr 2002, Keith Whitwell wrote:
> > Probably just the way it was done. It would be fairly easy to allow an
> > XF86Config option for zbuffer depth, but quite a bit more work to support 16
> > and 32 bpp side-by-side.
>
> We talked about this a bit at yesterday's I
Ian Romanick wrote:
> The issue is that Maya is requesting at least 23-bits of Z-buffer. In
> 16-bit mode, we only have 16-bits of Z-buffer, so it can't find a visual.
Just for grins you could hack glXChooseVisual so that a 16-bit Z buffer
satisfies the request for 23 bits.
> On the Radeon, i
"José Fonseca" wrote:
>
> On 2002.04.10 09:03 Sergey V. Udaltsov wrote:
> > > I've finally (& hopefully) finished the rewrite of Mesa's MMX blend
> > code.
> > Is it already in binary snapshots?
> >
> > Cheers,
> >
> > Sergey
> >
>
> Nope. It's really a small drop in the ocean so there is no nee
José,
I've checked in the code after testing with Glean and the OpenGL conformance
tests.
Was I supposed to change something in the C code? It passes the conformance
tests as-is.
Thanks for you work!
-Brian
___
Dri-devel mailing list
[EMAIL PROTEC
"José Fonseca" wrote:
>
> On 2002.04.11 07:40 graeme fisher wrote:
> > Hi,
> >
> > Does anyone know if there is a detailed porting guide for porting a
> > graphics driver using Mesa 3.x to one using Mesa 4.x.
> >
>
> Is not really a porting guide but by comparing the following notes you get
> a
"José Fonseca" wrote:
>
> On 2002.04.10 19:40 José Fonseca wrote:
> >
> > ... since the specs give some tolerance it would be nice to run the
> > conformance tests with different settings in mmx_blend.S, specially the
> > "single multiply w/o rouding" ...
>
> I've started to play with glean and
Allen Akin wrote:
>
> On Fri, Apr 12, 2002 at 07:01:08PM +0100, José Fonseca wrote:
> | ... Although doing (p*a+q*(1-a)) >> 8 can
> | introduce up to 1 LSB error and worst, it doesn't obey to the rule of
> | 255*255 = 255 as 255*255/256 = 254. I know that in Mesa's C blen
Jon Leech at SGI notified me that there's a bug in the GL/glext.h file
from March 22 (GL_GLEXT_VERSION=11). This is the version included with
Mesa 4.0.2 and is currently in the DRI tree.
The tokens GL_DOT3_RGB_EXT and GL_DOT3_RGBA_EXT have the wrong values.
They should _not_ have the same value
"José Fonseca" wrote:
> On 2002.04.12 20:14 Brian Paul wrote:
> > ...
> >
> > I'd like to see Mesa satisfy the 255*255=255 identity. Is it hard to
> > implement that in the MMX code? If it is, we could let it go for now
> > and see if anyon
Jens Owen wrote:
>
> "K. Petersen" wrote:
> >
> > On Fri, 12 Apr 2002, Jens Owen wrote:
> >
> > "K. Petersen" wrote:
> > When
> > "GlxBuiltInRadeon" is defined, the make process looks for a directory
> > "$(GLXLIBSRC)/mesa/dri/" and it's subdirectories when building libGL.so .
> > This directory
The chat is on now. Looks like my earlier message hasn't gone through
yet. Trying again...
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
#dri-devel on irc.openprojects.net
4:00pm EST (2100 UTC)
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Ian Romanick wrote:
>
> On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote:
>
> > Well, you're doing something you're not supposed to do & as a result
> > glXGetProcAddress isn't working right.
> >
> > Do you really need to call your symbol glBegin? How about xyzBegin or
> > similar
Ian Romanick wrote:
>
> On Wed, Apr 24, 2002 at 04:49:34PM -0600, Brian Paul wrote:
> > Brian Paul wrote:
> >
> > Perhaps you should try out this change before I commit it to the DRI.
> >
> > Try editing build/xc/lib/GL/GL/Makefile, look for the line that
Brian Paul wrote:
>
> Geoffrey Broadwell wrote:
> >
> > Unfortunately, I've had no luck with this problem in any of the XFree86
> > places I've tried (the newbie and xpert mailing lists, as well as
> > #xfree86), but I did get a response to try my quest
Geoffrey Broadwell wrote:
>
> Wow, that was fast. OK, what's the procedure for getting the fix?
> Do you suggest I wait for the next major X release, or try to pull
> and build from cvs, or apply a patch from you, or . . . ?
I could send you a new libGLcore.a file for you to try out if building
Michael wrote:
>
> On Mon, Apr 29, 2002 at 12:53:15AM -0600, Jens Owen wrote:
> > Is there any compelling reason to report single buffer visuals?
>
> Dunno, you tell me ;o)
>
> Here's how I noticed, some of the Mesa demos use single buffer (or
> either as an option). The existing (commented out
Felix Kühling wrote:
>
> Hi,
>
> I had trouble when compiling DRI with g++ 3.0.4 and -O3 related to
> function inlining. The function swap is declared static globally in
> quicksort.cc. In function quicksort it is redeclared. The redeclaration
> prevents g++ from inlining the swap function. Inst
Alexander Stohr wrote:
>
> Good fix Felix.
>
> I do "hate" local function prototypes.
> Its just bad coding style and laziness.
> Further it shows a critical lack of
> knowledge for the header file organisation.
>
> They are never verified against the
> implementation by the compiler and
> migh
Mesa should handle rendering into any visual, including overlay planes.
I think we just have to add some missing bits to the server-side GLX/Mesa
code to support overlay rendering. But I don't have any hardware (such
as FireGL) to test/fix this.
Stand-alone Mesa has supported overlay rendering
Ryan C Stallings wrote:
>
> Hello,
> I am new to DRI hacking, and I am looking for some guidance. I am trying to
>get the Neverwinter Nights Toolset to work under wine (http://nwwine.beergeek.net).
>I have hacked wine a bit to get it working for most people, but I am having problems
Michel Dänzer wrote:
>
> I've reworked the patch a bit again to try and make the endianness
> issues more explicit. It also attempts to fix r128 but I can't test
> that.
>
> http://penguinppc.org/~daenzer/DRI/endianness.diff
>
> I'm going to commit this now, will the Mesa changes propagate to t
Steven Walter wrote:
> Occasionally, I'll get an OpenGL app (almost always a screensaver) that
> will freeze up, leaving the console unusable. Numlock doesn't toggle,
> etc. If I log in via serial console and kill the app, then all is well.
> This seems to happen once every day or two.
>
> Rece
Keith Whitwell wrote:
> Keith Whitwell wrote:
>
>> Although we still have a couple of bugs & a lockup on the tcl branch,
>> the situation is in general better than what's on the trunk & I'd like
>> to get that code merged now. This will also help get the 8500 branch
>> started.
>>
>
> OK. I
Dieter Nützel wrote:
> On Wednesday 12 June 2002 20:53, Alan Hourihane wrote:
> [-]
>
>>We really need to clean up the stuff on SF now. Probably about 90%
>>don't even apply now, or should at least be re-tested.
>
>
> Yes, let's start with that.
> There are even several bugs for which the sende
I intend to look into this problem, probably over the weekend.
I've got at least one test program of my own to exercise this.
Agreed, we shouldn't crash.
-Brian
Jens Owen wrote:
> Brian, do these tests look reasonable to you? We certainly shouldn't
> crash the server, even if they are unreaso
Joe Krahn wrote:
> I am trying to draw to two windows using one context.
> It works for Mesa, but gives severe artifacts with DRI.
> It would work to instead use glXCopyContext, but this
> still doesn't work for DRI, and it crashes the server
> with indirect rendering.
>
> I am using ATI Rage and
Joe Krahn wrote:
[...]
> Another unrelated thing, not actually DRI: glDrawPixels
> with GL_BITMAP and an incorrect format correctly gives an
> error in DRI, but indirect results in an Xlib error:
> http://home.nc.rr.com/krahnfamily/source/bitmap_bug.c
OK, I found the problem here. I fixed it b
Michael Schlueter wrote:
> Hi,
>
> I'm trying to use a program called gtkradiant
> (http://zerowing.idsoftware.com/) that is a map editor for quake and all
> the other games from ID Software. My problem now is that the 3D view is
> very slow for me. After testing it with different graphic cards i
Willy Gardiol wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Hi!
> could someone help me understand what the output of glxinfo means?
>
> here it is:
>
> (i snip what i understand)
>visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
> id dep cl sp sz l
Willy Gardiol wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Thanks,
> whats is the difference between DirectColor and TrueColor? I have never heared
> about DirectColor...
TrueColor uses an immutable colormap (it can't be changed).
With DirectColor each of the red, green and
Michael Schlueter wrote:
> Hi Brian,
>
> sorry for disturb you again.
>
> Am Sam, 2002-06-22 um 00.00 schrieb Brian Paul:
>
>>Most of the DRI drivers have a per-context field called 'Fallback'.
>>It's a bitmask which records various reasons why we
Leif Delgass wrote:
> OK, mach64-0-0-5-branch is open for your hacking and testing pleasure! The
> trunk as of June 26 is merged in, so we now have Mesa 4.0.3 and I've converted
> the mach64 driver to the drmCommand interface. The branch compiles and works
> fine, and as a bonus, the bug with
Michael Schlueter wrote:
> Am Don, 2002-06-27 um 00.43 schrieb Brian Paul:
>
>>>>Most of the DRI drivers have a per-context field called 'Fallback'.
>>>>It's a bitmask which records various reasons why we need to fallback
>>>>to softwar
1 - 100 of 805 matches
Mail list logo
