mesa3d-dev

Re: [Mesa3d-dev] [PATCH] util: fix swizzles in the format table for 8-bits-per-channel formats

[José F. <jfo...@vm...>]

On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
> Hi José,
> 
> the attached patch fixes incorrect swizzles in u_format.csv. There are
> basically just 2 drivers which depend on the swizzles in this table:
> llvmpipe and r300g. Since r300g started supporting pretty much every
> texture format except SCALED ones, a few regressions have showed up.
> This patch resolves all issues I had, especially with the SRGB formats
> but I decided to clean it up all. git log:
> 
>     util: fix swizzles in the format table for 8-bits-per-channel
> formats
>     
>     The 8-bits-per-channel formats having the same channel order had
> completely
>     different swizzles, and at the same time, the same swizzles were
> used for
>     completely different channel orders of 8bpc formats.
>     
>     This made the whole table self-contradicting, caused headaches,
> and last
>     but not least, incorrent rendering for the drivers relying on
> these swizzles.
> 
> I hope I got it right. I didn't make a special distinction between the
> array and arith layouts. All I did was to make sure that if I grep
> e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
> ones.

Hi Marek,

I'll need a bit more time to investigate this.

One problem is that the interpretation of the swizzle varies with array
vs arith. The ordering for array is the lowest significant word to the
highest significant word (where word for 8bit formats is a byte), where
for arith it goes from least significant bit to the highest significant
bit. This is the same difference as array indexation and bit shifts.

There is also the problem of byte order which affects the bit shift
interpretation... 

I admit thet the current format description table is terribly
underdocumented/confusing and likely broken in several ways. I wrote it
to be able to code generate pixel format translation (which is wroking
reasonably) and never expected people to use it for hardware drivers as
well, although it is perfectly legitimate use. 

I have my own interpretation of these concepts, you and others hw driver
writers have their own different interpretation. Furthermore in
draw/translate/util modules there are some inconsistencies in these
interpretations too. So I need to read the GL and DX10 specs very well,
see how current drivers are using the descriptions, and come up with
something that makes sense for everybody.

So please hold on to your patch for a couple of days.

I'd appreciate if the interested parties could take a good look to
u_format.h comments, and summarize what they think the format semantics
should be.

Jose

[Mesa3d-dev] [Bug 26692] New: i915g MaxCombinedTextureImageUnits > 0 assersion failure

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26692

           Summary: i915g MaxCombinedTextureImageUnits > 0 assersion failure
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: ol...@gm...


When I run EGL demos with i915g, I get this error

$ ./xeglgears
EGL_VERSION = 1.4 (Gallium/X11/i915)
xeglgears: main/context.c:605: check_context_limits: Assertion
`ctx->Const.MaxCombinedTextureImageUnits > 0' failed.
Aborted

I think PIPE_CAP_MAX_COMBINED_SAMPLERS is missing in i915 (and i965) pipe
drivers, but I am not sure about the correct values to return.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [PATCH] Very small gallium test programs

[Jakob B. <wal...@gm...>]

Hi all

Some time ago I did wanted to learn a bit about more of the gallium
interface so I wrote two very small programs that does pretty much the
same things as the programs in progs/trivial with the same name does.
I'm not sure if this is something that we want in mesa but I thought I
share them with the ML should anybody find them remotely interesting.

I cleaned up the patch a bit and added some comments. Looking at the
source you can see that the programs only interact with
gallium/auxiliaries and softpipe. So the programs saves the result as
result.bmp.

To test the programs just goto progs/gallium and run make, after
compilation just run "./tri && gnome-open result.bmp" and should see a
triangle in your favorite image viewer (provided you have gnome based
desktop).

Have fun.

Cheers Jakob.

Re: [Mesa3d-dev] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output

[Dan N. <dbn...@gm...>]

On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard <ke...@ke...> wrote:
> The bash 'cd' command tends to emit random stuff to stdout when the
> CDPATH variable is set, so clear it to keep extra filenames from being
> emitted from the expand_archive function, which would otherwise cause
> mklib to fail.
>
> Signed-off-by: Keith Packard <ke...@ke...>

Congratulations on wading in to mklib, it's not a friendly place. :)

Reviewed-by: Dan Nicholson <dbn...@gm...>

Re: [Mesa3d-dev] Remove color index rendering?

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Corbin Simpson wrote:
> Can we doc it and comment it out? IME somebody will pop out and claim a
> use for it.

Search the Mesa source for all of the occurances of 'if
(ctx->Visual.rgbMode)' and you'll see most of the reason I want to
remove it.  Commenting it out or ifdef'ing it out will actually make the
situation much, much worse.

Part of the reason I want to do this is that I'm working on an extension
that allows the creation of a context without a visual / fbconfig.  I
have this mostly working, and I should have patches out early this week.
 The biggest hurdle has been "fixing" all of the places that use
ctx->Visual.  90% or more of those places are checking rgbMode.

Ideally, I'd like ctx->Visual to be completely removed.  99.9% of all
places that use ctx->Visual should actually use ctx->DrawBuffer->Visual.
 I suspect that this accounts for some of the FBO rendering problems
that have been reported over the years.

> Posting from a mobile, pardon my terseness. ~ C.
> 
>> On Feb 19, 2010 5:19 PM, "Ian Romanick" <id...@fr...
>> <mailto:id...@fr...>> wrote:
>>
> While we're on the topic of removing dead weight, can we remove support
> for color index rendering?  None of the hardware drivers support color
> index rendering, and color index rendering is deprecated in OpenGL 3.0
> (and removed in 3.1).
> 
> Can it please die in a fire?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuBt+QACgkQX1gOwKyEAw+8DACfSXYLr9mh1k06Ri+29NBjNKfn
wSYAnjRD3Eu4ZpeSkgOiBIOk7h1d2pJw
=LhpN
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Remove color index rendering?

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrice Mandin wrote:
> Le Fri, 19 Feb 2010 16:16:32 -0800
> Ian Romanick <id...@fr...> a écrit:
> 
>> While we're on the topic of removing dead weight, can we remove support
>> for color index rendering?  None of the hardware drivers support color
>> index rendering, and color index rendering is deprecated in OpenGL 3.0
>> (and removed in 3.1).
>>
>> Can it please die in a fire?
> 
> Well, I think it could be done for Gallium backends. Nvidia hw supports
> color indexed textures from nv04 (TNT) to nv30 (Geforce FX). It was
> removed since nv40.
> 
> Do you want it to be removed in all hardware backends (i.e. also dri
> ones) ?

I'm talking about rendering *to* a color index target.  As far as I'm
aware, none of the hardware drivers have ever supported this.  Color
index textures are an orthogonal issue, and they can stay.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuBtiwACgkQX1gOwKyEAw/0FQCgkFgSZsGnnZZFoe/b+EAUC2hZ
SvkAnjsKwvUMYJspDVmwq2s/lo3FSFb+
=mJcX
-----END PGP SIGNATURE-----

[Mesa3d-dev] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output

[Keith P. <ke...@ke...>]

The bash 'cd' command tends to emit random stuff to stdout when the
CDPATH variable is set, so clear it to keep extra filenames from being
emitted from the expand_archive function, which would otherwise cause
mklib to fail.

Signed-off-by: Keith Packard <ke...@ke...>
---
 bin/mklib |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/bin/mklib b/bin/mklib
index 06e8029..7f22725 100755
--- a/bin/mklib
+++ b/bin/mklib
@@ -25,6 +25,10 @@
 # CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 
+# Clear CDPATH as the 'cd' command will echo stuff
+# to stdout if it is set
+unset CDPATH
+
 # Given a list of files, look for .a archives and unpack them.
 # Return the original list of files minus the .a files plus the unpacked files.
 # first param:  name of a temp directory (to be deleted when finished)
-- 
1.6.6.1

[Mesa3d-dev] softpipe/llvmpipe SConscript

[Xavier C. <cha...@gm...>]

Since commit c6509f89 , scons dri=no drivers=softpipe (or llvmpipe) no
longer works.
It does show a warning at the beginning :
warning: trace pipe driver disabled: skipping build of xlib libGL.so

But it does not stop there, instead it goes on and build almost
everything, It's hard to see and not very intuitive.

Before the above command worked because there was no check for trace,
trace was always put by default to the driver list, and the current
SConscript still does that :
line 39 : drivers = [trace]

I have two suggestions that are not exclusive, and either of them
would make me happy :
1) Replace all warning by error , and Return() by Exit()
2) remove the check for trace, it's already added by default anyway

A side question :
line 21 : if not set(('softpipe', 'llvmpipe',
'trace')).intersection(env['drivers']):
    print 'warning: no supported pipe driver: skipping build of xlib libGL.so'
    Return()

But below in the script (line 41-58), the drivers used are softpipe ,
llvmpipe and cell.
Should trace be replaced by cell in the above check ?

[Mesa3d-dev] [Bug 26674] egl progs do not link without libm

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26674


Chia-I Wu <ol...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Chia-I Wu <ol...@gm...>  2010-02-21 09:30:38 PST ---
Patch committed.  Thanks.

I guess my gcc replaces trigonometric functions by something built-in.  I
didn't see the errors and nm did not list any of the trigonometric functions.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 26674] egl progs do not link without libm

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26674





--- Comment #2 from ata...@gm...  2010-02-21 08:45:46 PST ---
Without this patch, trigonometric functions fail to resolve. The other progs in
that directory do not require it. Here is linker output:

gcc -march=x86-64 -mtune=generic -O2 -pipe -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -Wl,--hash-style=gnu
-Wl,--as-needed -o eglgears eglgears.o -L../../lib -lEGL -lGL -ldrm  
eglgears.o: In function `T.55':
eglgears.c:(.text+0x183): undefined reference to `sincos'
eglgears.c:(.text+0x25a): undefined reference to `sincos'
eglgears.c:(.text+0x312): undefined reference to `sincos'
eglgears.c:(.text+0x36b): undefined reference to `sincos'
eglgears.c:(.text+0x3c4): undefined reference to `sincos'
eglgears.o:eglgears.c:(.text+0x41a): more undefined references to `sincos'
follow
eglgears.o: In function `T.55':
eglgears.c:(.text+0x854): undefined reference to `sincosf'
eglgears.c:(.text+0x88c): undefined reference to `sincos'
eglgears.c:(.text+0x91f): undefined reference to `sincos'
eglgears.c:(.text+0xa2f): undefined reference to `sincos'
eglgears.c:(.text+0xabc): undefined reference to `sincos'
eglgears.c:(.text+0xb06): undefined reference to `sin'
eglgears.c:(.text+0xc59): undefined reference to `sincosf'
eglgears.c:(.text+0xc93): undefined reference to `sincos'
collect2: ld returned 1 exit status
make: [eglgears] Error 1 (ignored)
gcc -march=x86-64 -mtune=generic -O2 -pipe -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -Wl,--hash-style=gnu
-Wl,--as-needed -o peglgears peglgears.o -L../../lib -lEGL -lGL -ldrm  
peglgears.o: In function `T.48':
peglgears.c:(.text+0x183): undefined reference to `sincos'
peglgears.c:(.text+0x25a): undefined reference to `sincos'
peglgears.c:(.text+0x312): undefined reference to `sincos'
peglgears.c:(.text+0x36b): undefined reference to `sincos'
peglgears.c:(.text+0x3c4): undefined reference to `sincos'
peglgears.o:peglgears.c:(.text+0x41a): more undefined references to `sincos'
follow
peglgears.o: In function `T.48':
peglgears.c:(.text+0x854): undefined reference to `sincosf'
peglgears.c:(.text+0x88c): undefined reference to `sincos'
peglgears.c:(.text+0x91f): undefined reference to `sincos'
peglgears.c:(.text+0xa2f): undefined reference to `sincos'
peglgears.c:(.text+0xabc): undefined reference to `sincos'
peglgears.c:(.text+0xb06): undefined reference to `sin'
peglgears.c:(.text+0xc59): undefined reference to `sincosf'
peglgears.c:(.text+0xc93): undefined reference to `sincos'
collect2: ld returned 1 exit status
make: [peglgears] Error 1 (ignored)
gcc -march=x86-64 -mtune=generic -O2 -pipe -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -Wl,--hash-style=gnu
-Wl,--as-needed -o xeglgears xeglgears.o -L../../lib -lEGL -lGL -lX11
xeglgears.o: In function `T.84':
xeglgears.c:(.text+0x273): undefined reference to `sincos'
xeglgears.c:(.text+0x34a): undefined reference to `sincos'
xeglgears.c:(.text+0x402): undefined reference to `sincos'
xeglgears.c:(.text+0x45b): undefined reference to `sincos'
xeglgears.c:(.text+0x4b4): undefined reference to `sincos'
xeglgears.o:xeglgears.c:(.text+0x50a): more undefined references to `sincos'
follow
xeglgears.o: In function `T.84':
xeglgears.c:(.text+0x944): undefined reference to `sincosf'
xeglgears.c:(.text+0x97c): undefined reference to `sincos'
xeglgears.c:(.text+0xa0f): undefined reference to `sincos'
xeglgears.c:(.text+0xb1f): undefined reference to `sincos'
xeglgears.c:(.text+0xbac): undefined reference to `sincos'
xeglgears.c:(.text+0xbf6): undefined reference to `sin'
xeglgears.c:(.text+0xd49): undefined reference to `sincosf'
xeglgears.c:(.text+0xd83): undefined reference to `sincos'
collect2: ld returned 1 exit status
make: [xeglgears] Error 1 (ignored)
gcc -march=x86-64 -mtune=generic -O2 -pipe -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -Wl,--hash-style=gnu
-Wl,--as-needed -o xeglthreads xeglthreads.o -L../../lib -lEGL -lGL -lX11
xeglthreads.o: In function `MakeNewTexture':
xeglthreads.c:(.text+0xee2): undefined reference to `cos'
collect2: ld returned 1 exit status
make: [xeglthreads] Error 1 (ignored)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 26674] egl progs do not link without libm

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26674





--- Comment #1 from Chia-I Wu <ol...@gm...>  2010-02-21 07:54:54 PST ---
What errors did you get without this patch?  Do other demos in progs/egl/ need
to link to libm?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default

[Marek O. <ma...@gm...>]

Hi,

the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
support this extension. The drivers reporting support of
PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.

Please review.

Marek

[Mesa3d-dev] [PATCH] util: fix swizzles in the format table for 8-bits-per-channel formats

[Marek O. <ma...@gm...>]

Hi José,

the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every texture
format except SCALED ones, a few regressions have showed up. This patch
resolves all issues I had, especially with the SRGB formats but I decided to
clean it up all. git log:

    util: fix swizzles in the format table for 8-bits-per-channel formats

    The 8-bits-per-channel formats having the same channel order had
completely
    different swizzles, and at the same time, the same swizzles were used
for
    completely different channel orders of 8bpc formats.

    This made the whole table self-contradicting, caused headaches, and last
    but not least, incorrent rendering for the drivers relying on these
swizzles.

I hope I got it right. I didn't make a special distinction between the array
and arith layouts. All I did was to make sure that if I grep e.g. A8R8G8B8,
I'll get the same swizzles and not entirely different ones.

Please review.

Best regards

Marek

Re: [Mesa3d-dev] postponed output on intel graphic with recent mesa & xorg-server

[Stephan R. <mai...@op...>]

dmesg gives me also a lot of:

[   13.996122] [drm:i915_gem_do_execbuffer] *ERROR* Object f6b81120 
appears more than once in object list
[   14.046987] [drm:i915_gem_do_execbuffer] *ERROR* Object f6b81120 
appears more than once in object list
[   14.097875] [drm:i915_gem_do_execbuffer] *ERROR* Object f6b81120 
appears more than once in object list
[   14.148375] [drm:i915_gem_do_execbuffer] *ERROR* Object f6b81120 
appears more than once in object list

can anyone help me with this?

Stephan

Am 20.02.2010 01:27, schrieb Stephan Raue:
> Hi all,
>
> with recent Mesa (git from 19.02.2010), xorg server
> (git://anongit.freedesktop.org/~krh/xserver dri2-invalidate branch),
> xorg-video-intel from 13.02.2010 i have an very postponed output on my
> Thinkpad X200t.
>
> in my Xorg.log i see a lot of follow messages:
>
> [3904117.243] (EE) intel(0): Failed to submit batch buffer, expect
> rendering corruption or even a frozen display: Bad file descriptor.
> [3904117.277] (WW) intel(0): flip queue failed: Device or resource busy
> [3904117.277] (WW) intel(0): Page flip failed: Device or resource busy
> [3904117.344] (WW) intel(0): flip queue failed: Device or resource busy
> [3904117.344] (WW) intel(0): Page flip failed: Device or resource busy
>
> what can be wrong?
>
> greetings
>
> Stephan
>
>    


-- 
               ### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
              http://www.openelec.tv

[Mesa3d-dev] [Bug 26674] New: egl progs do not link without libm

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26674

           Summary: egl progs do not link without libm
           Product: Mesa
           Version: git
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: ata...@gm...


Created an attachment (id=33467)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33467)
Makefile update to link egl progs with libm

Four of the egl programs need libm to link properly (eglgears, peglgears,
xeglgears, and xeglthreads). Attached is a Makefile patch to fix this.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 26632] Various cygwin build fixes

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26632


Brian Paul <bri...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #11 from Brian Paul <bri...@gm...>  2010-02-20 08:45:56 PST ---
OK, last patch committed.  Thanks.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] glxinfo -l ARB prog errors

[Xavier C. <cha...@gm...>]

On Sat, Feb 20, 2010 at 5:22 PM, Brian Paul <bri...@gm...> wrote:
> On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry
> <cha...@gm...> wrote:
>> It seems the commit below will always report an user error when
>> glxinfo -l is called.
>> And indeed I always get the following :
>> $ glxinfo -l
>> ...
>>    GL_VERTEX_PROGRAM_ARB:
>> ...
>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
>>
>> Should glxinfo be fixed to avoid this error ?
>> We could just put the fragment program only parameter in its own list,
>> and not use them when target is vertex program.
>
> Well, normally GL errors aren't reported to stderr so most people
> running non-debug builds won't see those.  But yeah, we probably
> shouldn't generate the errors anyway.  Feel free to write a patch to
> glxinfo...
>

I only realized yesterday that non-debug was the reason other people
(and some of my systems) didn't show these errors. It had been bugging
me for a while :)

Attached patch should fix it.

Re: [Mesa3d-dev] Mesa release for the end of March?

[Robert N. <rn...@2h...>]

On Fri, 2010-02-19 at 14:05 -0800, Corbin Simpson wrote:
> On Fri, Feb 19, 2010 at 11:14 AM, Brian Paul <br...@vm...> wrote:
> > Guillem Jover wrote:
> >> Hi!
> >>
> >> [ CCing Daniel Borca who used to work on 3dfx support in Mesa and
> >>   libglide, not sure though if he is around or interested anymore. ]
> >>
> >> On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote:
> >>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
> >>> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
> >>
> >> Could the drivers for actual hardware (namely glide, tdfx, dri/mga
> >> and dri/mach64) be exempted from removal? I at least still have cards
> >> for those, not sure though how many users might be out there, but
> >> whenever libglide has broken in Debian, I tend to receive bug reports,
> >> so I'd assume there's still some. And it always saddens me a bit when
> >> hardware support gets dropped in projects.
> >
> > I have/had no idea if the tdfx, glide, mga or mach64 drivers function
> > anymore.  If someone is actively using or testing the drivers I guess
> > we could keep them, but I'd rather not otherwise.
> 
> One of my co-workers, bless his soul, is digging out a PCI Voodoo3 for
> my collection, so I can maintain tdfx. I don't know about glide.
> 
> I am *not* testing mga; I don't have the right motherboard for it, sorry.

mga continues to work surprisingly well, given it's age.  I have a few
G450 and an G550 here...

robert.

> mach64's DRM code was getting a once-over by somebody on either
> dri-devel or LKML; maybe we could wait and see if somebody cares.
> 
> ~ C.
> 
-- 
Robert Noland <rn...@2h...>
2Hip Networks

[Mesa3d-dev] [Bug 26666] New: In GTA VC objects are drawn in incorrect Z order

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26666

           Summary: In GTA VC objects are drawn in incorrect Z order
           Product: Mesa
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: b7....@gm...


Created an attachment (id=33450)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33450)
Screnshot

I started Xorg with 'vesa' driver to use SW rendering, so video card shouldn't
matter (in fact, HW accelerated rendering is OK).
Screenshot demonstrates the bug.
P.S. Mesa version is 7.7, but it isn't listed in the bug form...


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] glxinfo -l ARB prog errors

[Brian P. <bri...@gm...>]

On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry
<cha...@gm...> wrote:
> It seems the commit below will always report an user error when
> glxinfo -l is called.
> And indeed I always get the following :
> $ glxinfo -l
> ...
>    GL_VERTEX_PROGRAM_ARB:
> ...
> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
>
> Should glxinfo be fixed to avoid this error ?
> We could just put the fragment program only parameter in its own list,
> and not use them when target is vertex program.

Well, normally GL errors aren't reported to stderr so most people
running non-debug builds won't see those.  But yeah, we probably
shouldn't generate the errors anyway.  Feel free to write a patch to
glxinfo...

-Brian

Re: [Mesa3d-dev] [PATCH] Remove a few more instances of the MEMCPY macro.

[Brian P. <bri...@gm...>]

On Fri, Feb 19, 2010 at 1:50 PM, Kenneth Graunke <ke...@wh...> wrote:
> ---
> It looks like these were missed in commit 2240ba10.  This also removes the
> last of the SUNOS4 defines; we can probably remove configs/sunos4* as well.
>
>  src/glu/mesa/gluP.h     |   10 ----------
>  src/glu/mesa/nurbssrf.c |    4 ++--
>  src/glu/mesa/project.c  |    2 +-
>  src/glu/mini/gluP.h     |   10 ----------
>  src/glu/mini/project.c  |    2 +-
>  5 files changed, 4 insertions(+), 24 deletions(-)

Actually, I'd like to add src/glu/mesa and src/glu/mini to the list of
things to remove from Mesa entirely.  Does anyone still have any
interest in these?

-Brian

Re: [Mesa3d-dev] [PATCH 00/11] Kill various _mesa_* wrappers.

[Brian P. <bri...@gm...>]

On Sat, Feb 20, 2010 at 3:21 AM, Olivier Galibert <gal...@po...> wrote:
> On Fri, Feb 19, 2010 at 11:30:44AM -0800, Ian Romanick wrote:
>> I'd also like to see additional patches to eliminate:
>>
>>  - _mesa_bzero - Conditionally wrap this if HAVE_BZERO is not defined.
>> Do the usual autoconf magic to detect it.  Let non-autoconf builds
>> figure it out there own way.
>
> Shouldn't you just use memset instead?

Yes, already done.

-Brian

Re: [Mesa3d-dev] Remove color index rendering?

[Patrice M. <man...@or...>]

Le Fri, 19 Feb 2010 16:16:32 -0800
Ian Romanick <id...@fr...> a écrit:

> While we're on the topic of removing dead weight, can we remove support
> for color index rendering?  None of the hardware drivers support color
> index rendering, and color index rendering is deprecated in OpenGL 3.0
> (and removed in 3.1).
> 
> Can it please die in a fire?

Well, I think it could be done for Gallium backends. Nvidia hw supports
color indexed textures from nv04 (TNT) to nv30 (Geforce FX). It was
removed since nv40.

Do you want it to be removed in all hardware backends (i.e. also dri
ones) ?

-- 
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

Re: [Mesa3d-dev] [PATCH 00/11] Kill various _mesa_* wrappers.

[Olivier G. <gal...@po...>]

On Fri, Feb 19, 2010 at 11:30:44AM -0800, Ian Romanick wrote:
> I'd also like to see additional patches to eliminate:
> 
>  - _mesa_bzero - Conditionally wrap this if HAVE_BZERO is not defined.
> Do the usual autoconf magic to detect it.  Let non-autoconf builds
> figure it out there own way.

Shouldn't you just use memset instead?

  OG.

Re: [Mesa3d-dev] Remove color index rendering?

[Corbin S. <mos...@gm...>]

Can we doc it and comment it out? IME somebody will pop out and claim a use
for it.

Posting from a mobile, pardon my terseness. ~ C.

On Feb 19, 2010 5:19 PM, "Ian Romanick" <id...@fr...> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While we're on the topic of removing dead weight, can we remove support
for color index rendering?  None of the hardware drivers support color
index rendering, and color index rendering is deprecated in OpenGL 3.0
(and removed in 3.1).

Can it please die in a fire?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt/Kd8ACgkQX1gOwKyEAw+zpQCgj+Yr0Bo3e6O3BijR5KYEds48
DfIAniZibZEaXZsO0qYa9OW5745LM9xL
=tcrK
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mes...@li...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev