Re: mesa 7.7.1 and 7.8.1 fails to compile under uclibc

> On Thu, 27 May 2010, Brian Paul wrote: >> > Piotr Gluszenia Slawinski wrote: >>>> >> > hello. problem as in topic. >>>> >> > http://83.18.299.190/uclibc/ contain files which might add some light >>>> >> > to subject :

Re: mesa 7.7.1 and 7.8.1 fails to compile under uclibc

Piotr Gluszenia Slawinski wrote: >> hello. problem as in topic. >> http://83.18.299.190/uclibc/ contain files which might add some light >> to subject :) >> >> it seems that problem is that _GNU_SOURCE is passed on (i know it from >> irc chat with someone bit more skilled) >> >> previous mesa versi

Re: Move lists to freedesktop.org?

Unless there's some objection I'm going to subscribe everyone to the new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. Probably in the next 24 hours. Then, some of you may have to log into the mailman interface (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set di

Re: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.

#x27;s one could be pushed by now, couldn't they? > > -Marek > > On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul <mailto:bri...@vmware.com>> wrote: > > Corbin Simpson wrote: > >>From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 >

Re: [Mesa3d-dev] Move lists to freedesktop.org?

Jesse Barnes wrote: > Would anyone have objections if these lists moved to freedesktop.org? > The recent thread with Linus about the drm pull request highlights the > post lag and non-subscriber aspect of the current lists, and that > leaves aside sf.net's horrible mail archive interface and poor >

Re: [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.

Corbin Simpson wrote: >>From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001 > From: Corbin Simpson > Date: Wed, 10 Feb 2010 10:39:18 -0800 > Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking > vertex. > > Fixes glean/clipFlat. Softpipe might be broken; I

Re: [PATCH] glean: Disable dithering for clipFlat.

Corbin Simpson wrote: >>From fe9c18cb5f4417558d40be7372c8bb74b613d470 Mon Sep 17 00:00:00 2001 > From: Corbin Simpson > Date: Wed, 10 Feb 2010 10:56:56 -0800 > Subject: [PATCH] glean: Disable dithering for clipFlat. > > Allows r300g to handily pass. Applied upstream to Glean. Thanks. -Brian -

Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h

r: for each function it appears in.) > make: *** [r300_emit.o] Error 1 > ... > > I am having dinner, now > > - Sedat - > > On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul wrote: >> Sedat Dilek wrote: >>> Hi, >>> >>> this patch fixes a bui

Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h

Sedat Dilek wrote: > Hi, > > this patch fixes a build-error in mesa GIT master after... > > commit251363e8f1287b54dc7734e690daf2ae96728faf (patch) > "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster" > >>From my build-log: > ... > In file included from svga_pipe_fs.c:37: > svga_tgsi.h: I

Re: [Mesa3d-dev] [mesa] Fixes after "Merge branch 'glsl-pp-rework-2'"

Sedat Dilek wrote: > Patches already sent to dri-devel ML [1]. > Forgot to CC to mesa3d-dev. > > - Sedat - > > [1] http://marc.info/?l=dri-devel&m=126107525213315&w=2 > > -- Forwarded message -- > From: Sedat Dilek > Date: Thu, Dec 17, 2009 at 7:21 PM > Subject: [mesa] Fixes aft

Re: [PATCH 3/4] APPLE_object_purgeable: core

Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Chris Wilson wrote: > >> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c >> index 52c4995..08633a9 100644 >> --- a/src/mesa/main/bufferobj.c >> +++ b/src/mesa/main/bufferobj.c >> @@ -37,6 +37,8 @@ >> #in

Re: APPLE_object_purgeable [v2]

Chris, It looks like this extension depends on the drm_intel_bo_madvise() function which isn't in a released version of libdrm yet. Correct? If so, I'd like to hold off on applying this patch to Mesa until there's a new libdrm. -Brian -

RE: [PATCH 3/4] APPLE_object_purgeable: core

One minor thing here: +void GLAPIENTRY +_mesa_GetObjectParameterivAPPLE(GLenum objectType, GLuint name, GLenum pname, GLint* params) +{ + GET_CURRENT_CONTEXT(ctx); + struct gl_buffer_object *bufObj; + + switch (objectType) { + case GL_TEXTURE: + case GL_BUFFER_OBJECT_APPLE: + case G

RE: [PATCH 1/2] APPLE_object_purgeable

> >> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h >> index 94d29a7..82d6e30 100644 >> --- a/src/mesa/main/mtypes.h >> +++ b/src/mesa/main/mtypes.h >> @@ -1410,6 +1410,7 @@ struct gl_buffer_object >> GLsizeiptr Length; /**< Mapped length */ >> /*...@}*/ >> GLboolean Wri

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

Robert Noland wrote: > Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49 > > I'm not certain that this is entirely the correct fix since the demo > from bug #23774 seemed to work before the commit that broke the build. > > Signed-off-by: Robert Noland > --- > src/glx/x11/glxha

Re: bisected engine demo

8 is first bad commit > commit bcb62ae78a9d2f4d08001e9f207b6f1291443968 > Author: Brian Paul > Date: Thu Sep 3 21:27:06 2009 -0600 > > mesa: _mesa_meta_bitmap() function > > :04 04 59187a621eb3c63005926ba958fa0ad610ddbb88 > eb4da44a186e7f90c07b64a0abf7e1307e015c25 M

Re: [PATCH] mesa/st: Create front renderbuffer on the fly when supplied

Nicolai Hähnle wrote: >>From f08d6efbc85609d1384006b773ea0a3276eb1e67 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Nicolai=20H=C3=A4hnle?= > Date: Sat, 12 Sep 2009 16:49:31 +0200 > Subject: [PATCH] mesa/st: Create front renderbuffer on the fly when supplied > with a surface > MIME-Version: 1.0 > Co

Re: [Mesa3d-dev] [PATCH] mesa/st: Initialize format bits of framebuffer renderbuffers

Nicolai Hähnle wrote: >>From 471cf346d0e9bf0bd97f2e652fd3052ba8f7a0c7 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Nicolai=20H=C3=A4hnle?= > Date: Sat, 12 Sep 2009 12:13:35 +0200 > Subject: [PATCH] mesa/st: Initialize format bits of framebuffer renderbuffers > MIME-Version: 1.0 > Content-Type: text/

Re: Partial updates with glX/DRI

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

Re: [PATCH] fix not including r300 compiler in tarballs

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

Re: About Gallium3D & Co.

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

Re: About Gallium3D & Co.

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

Re: [PATCH] r128: handle two-sided lighting correctly

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

Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list

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

Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list

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

Re: [PATCH] mklib: cosmetic: use "case" instead of "expr match"

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

Re: [PATCH] mklib: cosmetic: use "case" instead of "expr match"

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: >>>

Re: glxgears crash with latest mesa swrast module

Marco wrote: >> I don't see how that change could be related to a SwapBuffers crash > > Sorry I was misunderstod: that is latest commit I have. > > Last mesa sources I had was from 20/08/2008, and glxgears was running > fine, then I upgraded till the commit of Fri Sep 5 08:06:59 2008 > -0600 and

Re: glxgears crash with latest mesa swrast module

I don't see how that change could be related to a SwapBuffers crash. Maybe try recompile everything from scratch. -Brian Marco wrote: > I tried latest git from mesa master (latest commit is): > commit 11d694b1bb0cb384d802d7e0e252cf5119febb98 > Author: Brian Paul <[EMAIL P

Re: driDestroyDrawable is never called

Nicolai Hähnle wrote: > Hi, > > testing the r300-bufmgr has revealed that the driDestroyDrawable is never > called in very simple applications such as glxinfo or glxgears. This > obviously causes a number of memory leaks. Unfortunately, I don't really > understand that part of the code yet, but

Re: dri2-without-sarea branches for review

Michel Dänzer wrote: > On Mon, 2008-08-18 at 15:30 -0400, Kristian Høgsberg wrote: >> I have pushed the DRI2 update to the dri2proto, mesa, xserver, and >> xf86-video-intel trees in ~krh. It's on the master branch in those repos. > > I don't see anything younger than 5 months in your xf86-video-in

Re: Please HELP!!! accumulation buffers support FC9

Svilen wrote: > Nicolai Hähnle wrote: >> Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: >> I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it'

Re: Please HELP!!! accumulation buffers support FC9

Svilen wrote: > Hi, > > This is second time I'm trying to get your attention guys. > Shall I flag it as a bug? Or it is not a DRI problem. I know at least a > couple of similar platforms with the same trouble. > > If this is not a right place to ask the question, I'll appreciate if you > point

Re: [announce] libdrm 2.3.1

Paul Bender wrote: > Fatih Aşıcı wrote: >> 01 Tem 2008 Sal tarihinde, Dave Airlie şunları yazmıştı: >>> Update libdrm to 2.3.1. >> These archives do not include xf86mm.h ? > > I noticed that is well, but it appears to be correct. I found that I > needed to patch Mesa 7.1.0 with two commits from

Re: Combining Mesa3D and DRI mailing lists and/or sites?

Timo Jyrinki wrote: > 2008/6/12 Keith Whitwell <[EMAIL PROTECTED]>: >> In reality, what has happened is that most of this has already >> occurred -- whatever 3d driver-related traffic that hasn't been sucked >> into IRC is now occurring on the Mesa lists. > > Right. I now rearranged DRI wiki's mai

gallium (was Re: radeon r6xx DRM...)

Dave Airlie wrote: > Stephane wrote: >> Hi Brian, >> >> It seems like people are mostly concerned about gallium stability >> right now. How stable wioll the interfaces be in the future ? Maybe if >> you could tell us, that'd help others jump in. The gallium interfaces won't change radically, but

Re: radeon r6xx DRM...

Corbin Simpson wrote: > Matthias Hopf wrote: >> I'm in the process of skimming through the 3D programming documentation >> of the r6xx chips. AMD announced on XDC 2008 to make it public, so it >> will show up pretty soon. It's one massive beast, more than 650 pages... >> >> Obviously, the first ste

Re: glGenerateMipmapEXT and DRI drivers.

On Thu, May 8, 2008 at 9:06 PM, Dave Airlie <[EMAIL PROTECTED]> wrote: >> >> > >> > So compiz calls glGenerateMipmapEXT to generate mipmaps for some icons on >> > its switcher, this fails with a NULL src data ptr when running under >> > TTM+DRI2, my initial feeling is that we don't have the miptree

Re: UT2004 and AIGLX crashes with current mesa

Adam K Kirchhoff wrote: > So I've been following the development of Xorg and mesa to track all > the wonderful changes going into the radeon and radeonhd drivers. I > updated today, for the first time in about a week or two, and I'm > suddenly getting some crashes. When I go to close out ut2004,

Re: [PATCH 0/2] Keep generated glapi sources in mesa

Dan Nicholson wrote: > On Feb 13, 2008 6:48 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote: >> On Feb 13, 2008 6:40 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote: >>> The glapi source files for the xserver's GLX module are currently >>> generated in the mesa tree and then manually merged into the the xs

Re: Proposal for a few minor internal API changes.

Keith Whitwell wrote: > Keith Packard wrote: >> I'm writing up some documentation for internal DRM interfaces and came >> across a couple of interface inconsistencies that seem like they should >> get fixed before they start getting used a lot more. If these look like >> good changes, I'll continue

Re: [Patch] to fix libGL error: dlopen /usr/lib/dri/i915_dri.so failed (/usr/lib/dri/i915_dri.so: undefined symbol: _glthread_GetID

Sergio Monteiro Basto wrote: > Hi, since is for i915_dri.so , seems to me that is the best Malling list > to post it. > > Simply clean _glthread_GetID from DBG macros. > > To be honest I had clean all lines with DBG and _glthread_GetID , to be > more fast. > > I had try Mesa from git sources ma

Re: Gtkradiant not working with radeon driver

Roland Scheidegger wrote: > Jose Rodriguez wrote: >> On 30/10/2007, *Roland Scheidegger* <[EMAIL PROTECTED] >> > wrote: >> >> Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays >> with a count of 0 (which is legal though pretty much a no-op), it s

cooperative rendering

I've checked in a new GLX test for rendering into one GLX window by two processes. See comments in progs/xdemos/corender.c for instructions. Two interlocking tori are drawn. The first process draws a red one, the second process draws a blue one. I'm getting mixed results. With an old GeF

Re: Merging DRI interface changes

Keith Whitwell wrote: > Brian Paul wrote: >> Keith Whitwell wrote: >>> Brian Paul wrote: >>>> Kristian Høgsberg wrote: >>>>> Hi, >>>>> >>>>> I have this branch with DRI interface changes that I've been >>>>

glxsnoop program

I just commited this. usage: 1. start a GL demo 2. use 'xwininfo' to get the app's window ID 3. run 'glxsnoop ' 4. press z/s/b/f to view the app's z, stencil, back, front buffer I tested with the 7.0.2 i915 DRI driver and it doesn't work, unfortunately. Nor will it work with the Xlib driver (o

Re: Merging DRI interface changes

Keith Whitwell wrote: > Brian Paul wrote: >> Kristian Høgsberg wrote: >>> Hi, >>> >>> I have this branch with DRI interface changes that I've been >>> threatening to merge on several occasions: >>> >>> http://cgit.freedesktop.or

Re: Merging DRI interface changes

Kristian Høgsberg wrote: > Hi, > > I have this branch with DRI interface changes that I've been > threatening to merge on several occasions: > > http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2 > > I've just rebased to todays mesa and it's ready to merge. Ian > reviewed the changes a while b

Re: [PATCH] fix drm_i915_flip_t breakage

Lukas Hejtmanek wrote: > On Fri, Sep 28, 2007 at 06:19:48PM -0600, Brian Paul wrote: >> I'm presently using: >> Mesa from mesa_7_0_branch >> DRM from drm-2.3.0 tag >> xf86-video-intel from head/master >> >> When I run glxinfo I get: >

Re: [PATCH] fix drm_i915_flip_t breakage

Dave Airlie wrote: >> I've got a few issues using the git heads of Mesa, DRM and xf86-video-intel: >> >> 1. The Mesa 7.0.2 branch doesn't build with drm/master. >> >> Compiling dri_bufmgr.c: >> >> ../common/dri_bufmgr.c: In function 'driFenceBuffers': >> ../common/dri_bufmgr.c:102: warning: passing

Re: i945 GM performance question

Jonathan Bastien-Filiatrault wrote: > Brian Paul wrote: > >> Jonathan Bastien-Filiatrault wrote: >> >>> [snip] >>> at around 45-50 fps with a 960 face model in zpass mode. >>> >>> PS: Have you noticed that some versions of the newer mesa doe

Re: [PATCH] fix drm_i915_flip_t breakage

Jesse Barnes wrote: > On Friday, September 28, 2007 9:27 am Brian Paul wrote: >> 1. The Mesa 7.0.2 branch doesn't build with drm/master. >> >> Compiling dri_bufmgr.c: >> >> ../common/dri_bufmgr.c: In function ‘driFenceBuffers’: >> ../common/dri_

Re: [PATCH] fix drm_i915_flip_t breakage

Jesse Barnes wrote: > On Thursday, September 27, 2007 3:35:22 pm Jesse Barnes wrote: >> In one of my overzealous pipe/plane mapping patches, I renamed the pipes >> field in drm_i915_flip_t to planes, since it's really dealing with >> planes and so seemed to make sense. >> >> However, drm_i915_flip_

Re: i945 GM performance question

Jonathan Bastien-Filiatrault wrote: > Michel Dänzer wrote: > >> On Mon, 2007-09-24 at 21:51 -0400, Jonathan Bastien-Filiatrault wrote: >> >>> I have made a program that draws zfail/zpass shadows. I draw three >>> models with ~120 tris each and one light source and a simple floor, with >>> zpa

Re: GLX software indirect rendering broken when used by more than one client

Keith Packard wrote: > Debugging a kernel scheduling issue, I tried running two glxgears at > once without dri (option "NoDRI") and the X server neatly crashed on me. > > in xm_dd.c:xmesa_update_state, ctx->DrawBuffer is NULL for the second > GLX client. That certainly doesn't sound right. > > I

Re: [Mesa3d-users] mesa/linux-agp-compat/README Re: i915tex prerequisites

On 8/7/07, Sergio Monteiro Basto <[EMAIL PROTECTED]> wrote: > On Fri, 2007-07-27 at 08:16 -0600, Brian Paul wrote: > > > Michel suggest when install linux-agp-compat instead of delete > > > Module.symvers > > > I append the Module(s).symvers file generated by li

Re: [Mesa3d-users] i915tex prerequisites

Sergio Monteiro Basto wrote: > Since last email about this subject (3 of July) , I had installed > i915tex on my laptop , and I had working without problems . > > Michel suggest when install linux-agp-compat instead of delete > Module.symvers > I append the Module(s).symvers file generated by lin

Re: [Bug 11283] blender menus don't show up with r300 driver from git

Adam K Kirchhoff wrote: > On Wednesday 20 June 2007 13:02:47 Brian Paul wrote: >> Eric Anholt wrote: >>> On Tue, 2007-06-19 at 12:20 -0400, Adam K Kirchhoff wrote: >>>> On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] >>>> >>>> wrote: &

Re: [Bug 11283] blender menus don't show up with r300 driver from git

Eric Anholt wrote: > On Tue, 2007-06-19 at 12:20 -0400, Adam K Kirchhoff wrote: >> On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] >> wrote: >>> http://bugs.freedesktop.org/show_bug.cgi?id=11283 >>> >>> >>> >>> >>> >>> --- Comment #4 from [EMAIL PROTECTED] 2007-06-16 09:44 PST --- >>>

Re: [Bug 11283] blender menus don't show up with r300 driver from git

Adam K Kirchhoff wrote: > On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] > wrote: >> http://bugs.freedesktop.org/show_bug.cgi?id=11283 >> >> >> >> >> >> --- Comment #4 from [EMAIL PROTECTED] 2007-06-16 09:44 PST --- >> >> Finished with git-bisect: >> >> 9e8a961dd7d7b717a9fb4ecdea1c1b

Re: [texture_from_pixmap.c] glXBindTexImageEXT undefined

Dieter Nützel wrote: > Am Montag, 28. Mai 2007 schrieb Brian Paul: >> Dieter Nützel wrote: >>> progs/xdemos> time nice +19 make >>> gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O >>> -march=athlon-mp -fomit-frame-pointer -m3dnow

Re: [texture_from_pixmap.c] glXBindTexImageEXT undefined

Dieter Nützel wrote: > progs/xdemos> time nice +19 make > gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O > -march=athlon-mp -fomit-frame-pointer -m3dnow -msse -mmmx -mfpmath=sse,387 > -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > -D_GNU_SO

Re: [r200] minor minor minor cleanups

Christoph Brill wrote: > Hi list, > > attached are few fixes for "issues" I found while browsing through the > r200 DRI code. I checked in your patches. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Ex

Re: R300 cleanup questions

gt; already disabled. :) Brian, let me know if you want to make a branch so > I know > when I can push. > > > On 5/9/07, Brian Paul <[EMAIL PROTECTED]> wrote: >> Oliver McFadden wrote: >> > I also think we might need to add _dri_warning/_dri_error because the

Re: R300 cleanup questions

Oliver McFadden wrote: > I also think we might need to add _dri_warning/_dri_error because the _mesa > versions output "Mesa warning: %s" which implies to the user this is a Mesa > problem, not a DRI driver problem. > > I could add r300Warning and r300Error, but probably all DRI drivers need > wa

Re: R300 cleanup questions

Oliver McFadden wrote: > I'd like some input on the VBO stuff in r300. In r300_context.h we have the > following. > > /* KW: Disable this code. Driver should hook into vbo module > * directly, see i965 driver for example. > */ > /* #define RADEON_VTXFMT_A */ > #ifdef RADEON_VTXFMT_A > #define HW_

Re: R300 cleanup questions

Jerome Glisse wrote: > On 5/8/07, Christoph Brill <[EMAIL PROTECTED]> wrote: >> I reviewed the cleanup done by Olliver McFadden and had the following >> questions: >> >> -int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim) >> +static int r300NumVerts(r300ContextPtr rmesa, int num_

Re: Support for stereoscopic output in DRI?

David Oftedal wrote: > Hello! > > According to one or more sources on Google, Linux now makes it > possible to use LCD shutter to get stereoscopic graphics in certain > games and with certain graphics cards. However, there are certainly > other interesting methods of outputting stereoscopic graphi

Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework

eem to just be > slight precision errors; I think you should add a margin for error because > usually the hardware will implement things in a faster, perhaps less > precise > way. > > This lower precision is still "good enough", though. > > > On 3/17/

Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework

Nicolai Haehnle wrote: > Hello, > > back when I was actively working on DRI drivers almost three years > ago, I always felt uneasy about the fact that I didn't have an > extensive array of tests that I could rely on to test for regressions. > > Now I've decided to do something about it. I've take

Fwd: compiling savage-20060403-linux.i386

Can someone take a quick look at this patch? -Brian --- Begin Message --- Message body follows: Hi My name's Roberto. I don't know if you're the right person to send this message, but I prefer telling it. Compiling savage-20060403-linux.i386 driver (http://dri.freedesktop.org/snapshots/), on L

Re: [Mesa3d-users] mesa fbcon/dri

I'm just cc'ing your message to the DRI list so someone more involved in the DRI/kernel code can take a look at this. -Brian Robert Carter wrote: > I saw the post from Lukas S about hardware GL without X11. My problem > is similar but using a different method to solve, so i'll begin a new >

Re: [r300] fragment.position patch (RFC)

Rune Petersen wrote: > Hi, > > I finally managed to iron out the last issue with getting a fully > working fragment.position for the r300 driver. > > This should really require the big discussion if it wasn't for the fact > that it depends on functional changes in r300_vertexprog.c > (r300_select

Re: [r300] partly working fragment.position patch

Rune Petersen wrote: > Brian Paul wrote: >>It seems to me that in ctx->Driver.ProgramStringNotify() you can add any >>extra parameters you need to the program's parameters list. > > > I would prefer to make driver specific version of > _mesa_add_state_

Re: [r300] partly working fragment.position patch

Rune Petersen wrote: > Keith Whitwell wrote: > >>Rune Petersen wrote: >> >>>Keith Whitwell wrote: >>> Roland Scheidegger wrote: >Keith Whitwell wrote: >I think Rune is rather refering to the fact that you can't change (not >with "legal" means at least) the constant you got wit

Re: [Mesa3d-dev] Texture function opengl specification

Roland Scheidegger wrote: > Brian Paul wrote: > >>>Well, if my theory is sound, then the glean pixelFormats test is wrong. >> >>I don't think the test is wrong as-is. It's just that GL_COMBINE mode >>exercises things in a different way. A better

Re: [Mesa3d-dev] Texture function opengl specification

Roland Scheidegger wrote: > Jerome Glisse wrote: > According to fragment program extension, TEX, TXP, ... should give you the right A value (Ap depending on which texture unit you are using). >>> >>> That's not how I read that. TEX,TXP,... refer to texture sampling >>> only, there i

Re: r300 "official" releases

Jacek Poplawski wrote: > Is it possible to release r300 driver more often to the public? > > Last version of Mesa has been released 15th September, this version does > not contain fix for Blender, so everyone with this version of Mesa will > notice broken rendering and people will say to such a

Re: Recent CVS commit broke some apps (GLX)

Elie Morisse wrote: > Hi, > About a week ago you(?) seems to have broken some apps such as wine > and ut2004 ( no problem with glxgears, blender, googleearth.. ). > wine doesn't work at all, ut2004 doesn't restore resolution at > exit, and both output something like this : X Error of failed > reque

Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered

Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Roland Scheidegger wrote: > >>Roland Scheidegger wrote: >> I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some ex

Re: [r300] TCL fallback with Quake3

Rune Petersen wrote: > Brian Paul wrote: > >>Rune Petersen wrote: >> >>>Brian Paul wrote: >>> >>> >>>>Rune Petersen wrote: >>>> >>>> >>>>>Roland Scheidegger wrote: >>>>> >&

Re: [r300] TCL fallback with Quake3

Rune Petersen wrote: > Brian Paul wrote: > >>Rune Petersen wrote: >> >>>Roland Scheidegger wrote: >>> >>> >>>>Rune Petersen wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>Qua

Re: [r300] TCL fallback with Quake3

Rune Petersen wrote: > Roland Scheidegger wrote: > >>Rune Petersen wrote: >> >>>Hi, >>> >>>Quake3 causes fallback because r300_translate_vertex_shader() returns >>>early and doesn't translate the shader. >>> >>>The culprit: >>>if (!mesa_vp->Base.String) >>>return; >>> >>>To me it looks suspect

Re: r300 code cleanup

Tilman Sauerbeck wrote: > Jerome Glisse [2006-07-03 23:49]: > >>I want to cleanup a bit the r300 code, there is a lot of dead >>code. I also would like to use unified indenting rules and >>function naming rules. > > > Good idea :) > > >>For indenting rules i personnaly use the linux kernel one

Re: Why DRI/Mesa turns off hardware acceleration instead disabling features?

Jacek Poplawski wrote: > > > Hardware acceleration is always on assuming your system is set up > properly. If an application uses a feature that is not supported by > hardware, you have to fall back to software if you want the > application to run. > > > But in that case many

Re: [r300][PATCH] minor patches

Rune Petersen wrote: > Hi, > > Thought I'd share some of my patches. > > > Change vp max instructions: > The current state op the vp code is capable of executing 255 > instructions not 255*4. > > Disable unused routes (speedup): > When trying to get fragment.position to work I found the routes

Re: [r300] Doom3 causes VBO leak

Tilman Sauerbeck wrote: > Tilman Sauerbeck [2006-06-11 12:35]: > >>Tilman Sauerbeck [2006-05-22 19:42]: >> >>>[...] >>> >>>I found out that the buffer in question was allocated by >>>r300BufferData(). Now, the proper call to radeon_mm_free() would have >>>been made by r300DeleteBuffer(), but that

Re: [r300][PATCH] fix vertex attribs - try 2 - Re: [r300] ARB vp attribs broken?

Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tilman Sauerbeck wrote: > > >>Index: r300_context.h >>=== >>RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v >>retrieving revision 1.98 >>d

Re: [r300] ARB vp attribs broken?

Rune Petersen wrote: > Tilman Sauerbeck wrote: > >>Rune Petersen [2006-06-25 16:31]: >> >>>I've been looking at vertex shaders this weekend. >>> >>>It would appear that attribs are broken. The most straight forward way >>>to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 >>

Re: R300: GL_INVALID_ENUM in glStencilFunc.

Mike Mestnik wrote: > On Mon, Jun 19, 2006 at 08:01:09AM -0600, Brian Paul wrote: > >>Mike Mestnik wrote: >> >>>I keep trying to send this :( >>> >>>http://www.transgaming.com/showthread.php?forum=1262&thread=61671&msg=61671 >>> >&g

Re: R300: GL_INVALID_ENUM in glStencilFunc.

Mike Mestnik 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, 200

Re: _glapi_add_dispatch

Alan Hourihane wrote: > On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: > >>On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: >> >>>-BEGIN PGP SIGNED MESSAGE- >>>Hash: SHA1 >>> >>>Jacek Poplawski wrote: >>> On 5/30/06, Pedro Maia <[EMAIL PROTECTED]> wrote: >

Re: [r300] per-component negation for SWZ

Tilman Sauerbeck wrote: > Roland Scheidegger [2006-05-30 22:33]: > >>Tilman Sauerbeck wrote: >> >>>I finally ran glean today, and noticed that SWZ wasn't implemented >>>properly for r300 ARB vertex programs. >>> >>>So far I didn't handle per-component negation flags, the attached patch >>>adds tha

Re: [r300] vertex attribute changes broke Doom3?

Tilman Sauerbeck wrote: Hi, I suspect that the vertex attribute changes from 2006-04-26 broke Doom3 on r300. Symptoms: The rendering of Mars in the main menu screen is broken, see the attached screenshot (the planet is supposed to look reddish, not white). It's also flickering a lot. Similar pr

Re: [r300] texture corruption with copypixrate & subtexrate

Rune Petersen wrote: Hi, I get texture corruption if copypixrate or subtexrate is run without being the top most window. This is not a new problem, I just just happened to discover recently. When a window is partially covered by another window, or off the edge of the screen, reading pixels

Re: [r300] problems leaving the game (Quake 3 + Doom 3)

Rune Petersen wrote: I found the problem: In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h) And there are no sanity-checks done on the values returned by the drivers. Changing the defines to 16 makes everything work. Ch

Re: [r300] problems leaving the game (Quake 3 + Doom 3)

Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: I found the problem: In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h) And there are no sanity-checks done on the values returned by the drivers

Re: New video card

Alvaro Kuolas wrote: Hello to everyone! Currently I'm searching for a good video card, but I'm not interested in performance: I wan't it to be well documented. I now that 3dfx ones are well documented, I need something new, but no new new. What is the best video card for using it on DRI? How goo

Re: [r300] problems leaving the game (Quake 3 + Doom 3)

Rune Petersen wrote: Adam Jackson wrote: On Wednesday 26 April 2006 10:14, Rune Petersen wrote: Hi, Since the 12 of April there has been a change that causes Quake 3 and Doom 3 (demo)not to exit properly. Quake 3 locks up the system, and Doom 3 does a double fault. The suspect as I see it

Re: [R300]Crash, and backtrace!

Pedro Maia wrote: I'm using R300 CVS from today (24-04-2006). During my test sessions i found some problems. Tests: ARBWARPMESH Starting program: /home/pedro_maia/CVS/Mesa/progs/tests/arbvpwarpmesh [Thread debugging using libthread_db enabled] [New Thread -1213638976 (LWP 27240)] Mesa: CPU ven

  1   2   3   4   5   6   7   8   9   >