Hallo!

i installed about http://autobuild.puredata.info/auto-build/2006-11-14/Pd-0.39.2-extended-2006...

okay, so then you will also need libmpeg, because that's not included ... -> apt-get install libmpeg (or something similar - I don't know how the package is called exactly) or you can of course also do it with adept on ubuntu.

i never heard about, so you may explain about gem debian packages and where i can find it... thanks for help. gruss joh

apt-get install gem

LG Georg

Hallo!

...

...

i never heard about, so you may explain about gem debian packages and where i can find it... thanks for help. gruss joh

apt-get install gem

@georg holzmann: do you need a special repository to make apt find that?

in debian not - I don't know how it is in ubuntu ...

LG Georg

yo list,

i was installing gem and libmpeg1, but i still got this problem when starting pd, the pd window shows now:

/dev/dsp (read/write): Device or resource busy (now will try write-only...) /dev/dsp (writeonly): Device or resource busy /usr/local/pd/lib/pd/extra/Gem.pd_linux: /usr/local/pd/lib/pd/extra/Gem.pd_linux : undefined symbol: glDeleteProgramsNV Gem: can't load library

i am running 3 pd versions on my laptop, these give back different fault-messages to the pd windows. my latest version (look above). the other ones ( pd-extendet and an old version) shows this:

/dev/dsp (read/write): Device or resource busy (now will try write-only...) /dev/dsp (writeonly): Device or resource busy /dev/dsp (readonly): Device or resource busy Gem: can't load library cyclone: can't load library zexy: can't load library maxlib: can't load library

thanks for help, yohannes

On Dec 2, 2006, at 12:30 PM, marius schebella wrote:

Johannes Krause wrote:

...

/usr/local/pd/lib/pd/extra/Gem.pd_linux : undefined symbol: glDeleteProgramsNV Gem: can't load library

I got the same error yesterday (undefined symbol:
glDeleteProgramsNV) with an ATI Radeon X300 graphic card. I don't
know if that error can be fixed so easily. maybe when you compile
Gem with special flags. If I find a solution, I will post it.

maybe for the moment you may want the method I posted earlier (use
synaptic and the debian packages) that should work.

BUT: synaptic/Debian installs the binaries to other folders, so if
you used the pd extended installer you should uninstall it (I think
it's enough to go to the unzipped folder and type make uninstall
(see readme.txt for details) and then chose "pd" and "pd-gem" from
the synaptic installation tool (and maybe some others...

unfortunately also the debian packages have some bugs (like the
examples and data folders are messed up).

Maybe the solution would be some debian packages from the autobuild
farm.

Yes, debian packages!

.hc

Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith

Max Neupert wrote:

...

...

Maybe the solution would be some debian packages from the autobuild farm.

Yes, debian packages!

so what you suggest for a successfull pd installation on a ubuntu machine is to download this: http://autobuild.puredata.info/auto-build/latest/pd-2006-12-04-linux-debian-...

and then run

tar xjf pd-2006-12-04-linux-debian-stable-i386-i686.tar.bz2 cd pd-2006-12-04-linux-debian-stable-i386-i686 make install prefix=/usr/local

and then it should run with Gem like ./pd -lib Gem

?

no. a .tgz build on a debian-machine is not a debian package. a debian-package is a .deb file which holds the content of the tgz PLUS some meta information (like dependencies!). you manually install it via dpkg. more often you (de)install it via apt-get, aptitude or synaptics.

mfga.sdr IOhannes

Am 04.12.2006 um 14:42 schrieb IOhannes m zmoelnig:

IOhannes m zmoelnig wrote:

...

Max Neupert wrote:

...

...

...

Maybe the solution would be some debian packages from the
autobuild farm.

Yes, debian packages!

so what you suggest for a successfull pd installation on a ubuntu machine is to download this: http://autobuild.puredata.info/auto-build/latest/pd-2006-12-04- linux-debian-stable-i386-i686.tar.bz2

reading your email again, i understand it better: the suggestion is
not to install the files tagged with "debian" on an ubuntu system but
to use a special packaging format, which by chance is used by both debian (thats why it is called "debian-package" or ".deb") and ubuntu
(which is really just a polished up debian clone).

building debian packages on the autobuild farm would eventually result in having different packages for debian-stable, debian-testing, ubuntu-hoary. (because of the very problem of dependencies)

i hope i could make this somewhat clearer.

thanks IOhannes,

well, honestly i am new to linux and don't even have it on my own
machine (osx) but i am working on a joint pd project with Johannes K.
so.. to give you the complete picture: i actually deleted his windows
partition in an accident while trying to make it dual boot. so he is
stuck now with ubuntu and i am gone to bulgaria. but thanks god he is
very brave and wants to stick with it. actually i think he is
enjoying it so far. we just need to figure out now how to make the pd
externals running on his thinkpad. :)

max

Max Neupert wrote:

so, how do you recommend installing pd with some of the most important libaries on an ubuntu (debian) machine then?

one simple way should be: install puredata/gem/... via synaptics. this should resolve a lot of dependencies for hc's installer.

then you can install hc's installer (if you want to, because (e.g.) the ubuntu versions deem you too outdated) the ubuntu/debian-packages and hc's installer should happily live together on one machine (the official packages will install themselves into /usr/ while hc's installer should go into /usr/local; since /usr/local/bin has usually a higher priority than /usr/bin you will get pd-extended when you type "pd" into your xterm.

what i actually did was: first i looked into the synaptics manager, found pd. there was no info which version nor if it's bare pd or whatever, so i looked over to HCS's

this is because "pd" is the old deprecated package name; the new one is called "puredata" (and "pd" is a virtual package provided by "puredata" to get dependencies right in the stage of transition)

site because i run have good experiences with his release on osx. so i tried to install this one and could not get Gem to run either even after installing libmpeg, lib imagemagick and whatever else was missing even make itself seemed not to be there.

iirc, your last problem was with "glDeleteProgramsNV"; i guess that they only package that would help you here is the nvidia-binary drivers (of course you will need an nvidia card to make any use of them). if you are using some other gfx-card, you will have to recompile Gem yourself.

this should be quite simple:

1. get all the packages _needed_ for building Gem; since you are using a

Debian-based system, this is as simple as: #> apt-get build-dep gem

1a) make sure you have automake and autoconf installed (it might be that automake is not yet in the build-dependencies of ubuntu's gem)

2. get recent source of Gem (from CVS!) and unpack them

3. optional(!): get some more packages for building Gem (there is a

readme somewhere)

4. build Gem (cd Gem/src && make)

if this is too complicated, get a cheap nvidia-card and it should run.

mfg,asdr. IOhannes

Hans-Christoph Steiner wrote:

Since many people have non-nvidia cards, would it be possible to make the default Gem build not dependent on nvidia-specific stuff? Then there could be --enable-nvidia for people who want that.

no. as said before, i see (!) configure as a way to build a package optimized for the machine that configure is executed on. it is not a tool to make the most stripped down version.

if you want configure to create a most generic package, then you will have to pass arguments to it (e.g. "--disable-NV")

When building packages (.deb, .tar.gz, whatever), its much more important that it run on all machines, than its very well optimized on specific machines. Later, it would be possible to add a pd-gem-nvidia package, etc. etc.

this is correct, but as said above, configure is not necessarily the tool to create packages that run on all machines.

mfg.asdr IOhannes

hi marius

On Mon, 2006-12-04 at 11:30 -0500, marius schebella wrote:

hi, may I join you in that discussion? I understand now that the Gem package in the pd-extended is built for nvidia support and does not run without a nvidia card. correct? But what I want to know is, (I don't know so much about configure scripting..) when I build my own Gem and have NO nvidia card, will I have to type --disable-NV? that would not make sense to me... I would like to compile my Gem later today. so thnx for answers. marius.

i might be wrong, but as far as i understand the idea of a configure script, it is here, to check if all libraries are installed, that are needed to run the binary, that you are going to compile, also where they are, and also if some optional libraries are there, which may improve the functionality of your binary to compile. if a certain optional funcionality is non-existent on your computer (e.g. nvidia extension), ./configure should automatically disable it, when generating the makefile. if the configure doesn't print errors, you can expect, that the binary you are going to compile will work (at least on your system).

in your case, when you execute ./configure, it should print something like:

using NV-extensions  : no

that means, you don't need to add the flag '--disable-NV' to configure.

i hope i could help

roman

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Quoting marius schebella marius.schebella@gmail.com:

hi, may I join you in that discussion? I understand now that the Gem package in the pd-extended is built for nvidia support and does not run without a nvidia card. correct? But what I want to know is, (I don't know so much about configure scripting..) when I build my own Gem and have NO nvidia card, will I have to type --disable-NV? that would not make sense to me...

configure should detect whether your system supports glDeleteProgramsNV() (note: this does not necessarily mean that you need to have an nvidia card; but since the extension is proposed by nvidia, chances are higher that their cards&drivers support it). if it does then Gem will be built with it. if it doesn't then Gem will be build without it.

I would like to compile my Gem later today. so thnx for answers.

on recent machines, Gem builds quite fast; so you could try both. that is: if configure fails to detect your system's possibilities; in this case, i would be very interested in your setup.

mfg.ar IOhannes

On Dec 4, 2006, at 12:25 PM, chris clepper wrote:

On 12/4/06, IOhannes m zmoelnig zmoelnig@iem.at wrote: Hans-Christoph Steiner wrote:

...

Since many people have non-nvidia cards, would it be possible to

make

...

the default Gem build not dependent on nvidia-specific stuff? Then there could be --enable-nvidia for people who want that.

no. as said before, i see (!) configure as a way to build a package optimized for the machine that configure is executed on. it is not a tool to make the most stripped down version.

Since performance is quite vital to the software working in the
intended manner, we make decisions based on what provides the most
efficient path in the code not some generic computer spec. At the
same time we don't really limit what hardware can run GEM even
though there are certainly hardware and driver set ups entirely
unsuitable for the software.

I think that all the optimization that you guys have done is great.
But it would be very helpful to a lot of people if the optimization
did not prevent those of us with older hardware from even starting Gem.

.hc

All information should be free. - the hacker ethic

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

I think that all the optimization that you guys have done is great.
But it would be very helpful to a lot of people if the optimization
did not prevent those of us with older hardware from even starting Gem.

To add a political note: "... and those of us who try to run a system consisting of only/mostly free software." Well, these people probably know how to build Gem themselves ...

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

On Dec 4, 2006, at 3:30 PM, Frank Barknecht wrote:

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

...

I think that all the optimization that you guys have done is great. But it would be very helpful to a lot of people if the optimization did not prevent those of us with older hardware from even starting
Gem.

To add a political note: "... and those of us who try to run a system consisting of only/mostly free software." Well, these people probably know how to build Gem themselves ...

I want to make sure that's not a requirement. I think that it would
be great if everyone knew how to build Gem from source. I think it
definitely should not be a requirement for using Gem with free software.

I have encountered quite a few people who were not techies at all,
but were sick of Windows, so they installed Ubuntu. They were
getting very frustrated with this idea that they should have to spend
weeks figuring out how to get things working that worked fine on
Windows.

.hc

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams

On Dec 4, 2006, at 5:00 PM, Arie van Schutterhoef wrote:

...

they installed Ubuntu.They were getting very frustrated with this
idea that >they should have to spend weeks figuring out how to get things working that >worked fine on Windows.

-I spend this summer trying to get Ubuntu work on an iMac and was
rather astonished by the discovery that it had trouble with something simple like video-card (ATI) drivers. In the end I gave up... I've got
more om my mind than figuring out these kind of things. As long these
elementary problems aren't addressed, Linux won't make onto the desktop. As an OS it
might be suited for servers, but that's where it will probably stay.

That one is a tough one. Its not for lack of people trying.
Companies like ATI and NVidia refuse to release the docs to the
developers, so they have to reverse engineer things.

.hc

If you are not part of the solution, you are part of the problem.

Video-cards aren't simple at all,

-I'm aware of that fact...

I was merely trying to point out that I can understand that some people are willing to put the extra effort into it to make it work. Particularly when you talk about x11. As for Linux itself, it has matured considerably over the years.

AvS

Am 04.12.2006 um 22:30 schrieb Frank Barknecht:

Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

...

I think that all the optimization that you guys have done is great. But it would be very helpful to a lot of people if the optimization did not prevent those of us with older hardware from even starting
Gem.

To add a political note: "... and those of us who try to run a system consisting of only/mostly free software." Well, these people probably know how to build Gem themselves ...

do you want to stay elite? is it about keeping people from entering
the boat or do you want to invite beginners to join the club? i mean
we are not talking about a very specific treak of the system or a
custom coding project. its about installing Gem. this should not be a
science.

don't get the attitude.

m

On Dec 4, 2006, at 11:07 AM, IOhannes m zmoelnig wrote:

Hans-Christoph Steiner wrote:

...

Since many people have non-nvidia cards, would it be possible to make the default Gem build not dependent on nvidia-specific stuff? Then there could be --enable-nvidia for people who want that.

no. as said before, i see (!) configure as a way to build a package optimized for the machine that configure is executed on. it is not a tool to make the most stripped down version.

if you want configure to create a most generic package, then you will have to pass arguments to it (e.g. "--disable-NV")

The autobuild machines most definitely do not have nvidia cards:

root@debian-stable-i386:~ > lspci 0000:01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage
Pro AGP 1X/2X (rev 5c)

So these builds do not run on the machine they were built on.

.hc

...

When building packages (.deb, .tar.gz, whatever), its much more important that it run on all machines, than its very well
optimized on specific machines. Later, it would be possible to add a pd-gem- nvidia package, etc. etc.

this is correct, but as said above, configure is not necessarily the tool to create packages that run on all machines.

mfg.asdr IOhannes

Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra

On Dec 4, 2006, at 3:17 PM, zmoelnig@iem.at wrote:

Quoting Hans-Christoph Steiner hans@eds.org:

...

The autobuild machines most definitely do not have nvidia cards:

root@debian-stable-i386:~ > lspci 0000:01:00.0 VGA compatible controller: ATI Technologies Inc 3D
Rage Pro AGP 1X/2X (rev 5c)

So these builds do not run on the machine they were built on.

have you tried or are your remarks based on my statements about
needing nvidia? my nvidia card's here support some SGI extensions, and i am pretty
sure that i don't run irix.

i haven't heard of someone having problems with NV/ARB extensions
on their self-built Gem for quite a long time.

so please check whether the binaries do work.

Unfortunately, these binaries do not work. Marius knows more about
it than me, he's been building up this box, its a relatively new Dell
with an ATI card. The autobuild GNU/Linux/i386 machines are all the
exact same hardware, old Compaqs with the ATI card above. So neither
the compilation machine nor the machine running Gem have nvidia
hardware. But Gem dies on the new Dell with that NV error that
started this thread.

So I guess as Chris said, there is probably a bug in the NV detection
code.

.hc

                                           http://at.or.at/hans/

On 12/4/06, Hans-Christoph Steiner hans@eds.org wrote:

Ok, wait I think I misunderstood. You are saying that the ancient ATI card in the autobuild machines might support the nvidia extensions, and they are being properly detected. I thought you mean whether the card was nvidia or not (neither are).

There are extensions to OpenGL which are vendor specific and some vendors may support ones that are not their own. In this case glDeleteProgramsNV has to do with vertex and fragment shaders and Nvidia had their own extension before it was approved by the review board for full GL status. I think that glDeleteProgramsNV could be removed since glDeleteProgramsARB covers the same functionality.

It seems to load from the command line with -nogui, I am testing now

whether I can load an object.

The ATI drivers should not define the NV extension in the headers if it is not supported by the driver. All GEM does is have an #ifdef for the presence of that extension and then builds with it enabled or not.

So, does the autobuild GEM run on the autobuild machine?

On 12/4/06, Hans-Christoph Steiner hans@eds.org wrote:

Yup, Gem loads and so does [gemwin]. An ATI from 1998 supports some NVidia extensions that a current ATI does not support, crazy...

I don't think that is the case. That ATI part does not support the OpenGL functionality in question at all whether through the NV or ARB extension. No properly functioning ATI driver would have that extension in it.

I am thinking for the Pd-0.39.2-extended release, Gem should be compiled

with --disable-NV, but it can stay as is on the nightly builds if that's useful to y'all.

I wouldn't do anything until it is clear that the autobuild machine is building a binary with calls to the Nvidia extension. I do not think it is.

chris clepper wrote:

On 12/4/06, *Hans-Christoph Steiner* <hans@eds.org mailto:hans@eds.org> wrote:

Yup, Gem loads and so does [gemwin].  An ATI from 1998 supports some
NVidia extensions that a current ATI does not support, crazy... 

I don't think that is the case. That ATI part does not support the OpenGL functionality in question at all whether through the NV or ARB extension. No properly functioning ATI driver would have that extension in it.

i am pretty sure that the gfx-card on the autobuild machine does NOT support the nvidia extensions (natively). however, i am also pretty sure, that these machiens are using the mesaGL implementation which (being a software renderer) can provide pretty any extension (it knows about). it would provide the nvidia-extensions (in software, like everything else) even for an old vesa card or whatever.

so configure correctly detects that glDeleteProgramsNV() is supported on the autobuild machine. period.

now, why is it not supported on some machines? probably because of older versions of mesaGL which do not yet support the nvidia-extensions.

mfg.adrs IOhannes

On 12/5/06, Hans-Christoph Steiner hans@eds.org wrote:

So you are saying that they removed NV compatibility from in mesa when going from 6.4 to 6.5?

This is just one specific extension for Nvidia specific shaders. I don't know if anyone is using those shaders, but we could probably get by only with the ARB spec support.

yup, still no luck with Gem here... when compiling cvs Gem on the machine with the Radeon X300 card, I got rid of the glDeleteProgramsNV error. but I can not play any movies. Pd either crashed or showed only one color. I downgraded ubuntu to libgl1-mesa 6.4 (before it was 6.5). also no glDeleteProgramsNV problem, but no movies ( I test with the examples patch from the help.) at least Pd does not crash... So I am back to the debian package of Gem (v 0.90) which does not make problems. iohannes, what do you want to know from me to locate that problem? with ...Gem/04.pix/05.film.pd I get the following console output: pix_film:: quicktime support pix_film:: libmpeg3 support pix_film:: libaviplay support pix_film:: libmpeg support GEM: Start rendering GL: invalid value [pix_filmNEW]: opening /usr/local/lib/pd//doc/examples/Gem/04.pix/../data/anim-1.mov with format 1908 [pix_filmNEW]: ... [pix_filmNEW]: ... [pix_filmNEW]: loaded file: /usr/local/lib/pd//doc/examples/Gem/04.pix/../data/anim-1.mov with 90 frames (256x256) at 30.000000 fps but the texture is not rendered correctly. The whole cube is brownish. marius.

2006/12/5, Hans-Christoph Steiner hans@eds.org:

On Dec 5, 2006, at 4:01 PM, chris clepper wrote: On 12/5/06, Hans-Christoph Steiner hans@eds.org wrote:

...

So you are saying that they removed NV compatibility from in mesa when going from 6.4 to 6.5?

This is just one specific extension for Nvidia specific shaders. I don't know if anyone is using those shaders, but we could probably get by only with the ARB spec support.

We are downgrading to mesa 6.4 because we know it works there. We also tried compiling against the 6.5 version. It loaded, but had other issues. Actually, its the same bug that was reported for the autobuilds on Mac/Intel. The video was playing but it was like it was only playing one pixel of the whole video, spread out over the whole area that was being textured. This was with the examples/Gem/4.pix/05.movie.pd

.hc

---

                                          http://at.or.at/hans/

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Dec 6, 2006, at 4:50 AM, IOhannes m zmoelnig wrote:

marius schebella wrote:

...

yup, still no luck with Gem here... when compiling cvs Gem on the machine with the Radeon X300 card, I
got rid of the glDeleteProgramsNV error. but I can not play any movies. Pd either crashed or showed only
one color. I downgraded ubuntu to libgl1-mesa 6.4 (before it was 6.5). also no glDeleteProgramsNV problem, but no movies ( I test with the examples patch from the help.) at least Pd does not crash... So I am back to the debian package of Gem (v 0.90) which does not
make problems. iohannes, what do you want to know from me to locate that problem? with ...Gem/04.pix/05.film.pd I get the following console output: pix_film:: quicktime support pix_film:: libmpeg3 support pix_film:: libaviplay support pix_film:: libmpeg support GEM: Start rendering GL: invalid value [pix_filmNEW]: opening /usr/local/lib/pd//doc/examples/Gem/04.pix/../data/anim-1.mov with format 1908 [pix_filmNEW]: ... [pix_filmNEW]: ... [pix_filmNEW]: loaded file: /usr/local/lib/pd//doc/examples/Gem/04.pix/../data/anim-1.mov with 90 frames (256x256) at 30.000000 fps but the texture is not rendered correctly. The whole cube is
brownish. marius.

First, I forgot to mention, we are currently building up a 9-computer/ projector/screen system with 5.1 sound here at Polytechnic. I had to
overcome resistance in order to use Pd with this, so I'd really like
this to work out well. So I appreciate all the help like this with
bug fixes, etc that you can offer. Plus, I think it will be a good
showcase for Pd/Gem.

The first step is getting video playback working, then we plan on
doing interactive stuff, maybe making a single OpenGL space built up
from the 9 screens.

So, now to answer your questions:

you could try to change whether rectangle-texturing is used by
sending a [mode 0/1( message to [pix_texture] (or [pix_movie]).

tell us whether it works.

Yes, for more info, see bug report:

http://sourceforge.net/tracker/index.php? func=detail&aid=1609736&group_id=55736&atid=478070

and which drivers you are using (i guess you yould run the X300 with "fglrx" and "radeon" and "ati" and "vesa")

It is now using fglrx from Ubuntu, but this also happened with the
"ati" driver (default Ubuntu driver), and also in VESA modes.

and please send the output of glxinfo (_without_ the long list of
visual modes)

This is from the current driver:

display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig client glx vendor string: ATI client glx version string: 1.3 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_ATI_pixel_format_float, GLX_ATI_render_texture GLX version: 1.2 GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_multisample OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON X300/X550 Series Generic OpenGL version string: 2.0.5814 (8.25.18) OpenGL extensions: GL_ARB_multitexture, GL_EXT_texture_env_add,
GL_EXT_compiled_vertex_array, GL_S3_s3tc, GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_occlusion_query,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects,
GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_vertex_blend, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_ARB_draw_buffers, GL_ATI_draw_buffers, GL_ATI_element_array, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_ATI_map_object_buffer,
GL_ATI_separate_stencil, GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_ATI_vertex_array_object, GL_ATI_vertex_attrib_array_object, GL_ATI_vertex_streams, GL_ATIX_texture_env_combine3, GL_ATIX_texture_env_route, GL_ATIX_vertex_shader_output_point_size, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_draw_range_elements, GL_EXT_fog_coord,
GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels,
GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
GL_EXT_stencil_wrap, GL_EXT_texgen_reflection, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle,
GL_EXT_vertex_array, GL_EXT_vertex_shader, GL_HP_occlusion_test, GL_NV_blend_square, GL_NV_occlusion_query, GL_NV_texgen_reflection,
GL_SGI_color_matrix, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod,
GL_SUN_multi_draw_arrays glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

This is from the "ati" driver:

display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig client glx vendor string: ATI client glx version string: 1.3 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_ATI_pixel_format_float, GLX_ATI_render_texture GLX version: 1.2 GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_multisample OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.5 Mesa 6.4.1) OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith

On Dec 6, 2006, at 3:04 PM, chris clepper wrote:

On 12/6/06, Hans-Christoph Steiner hans@eds.org wrote:

OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON X300/X550 Series Generic OpenGL version string: 2.0.5814 (8.25.18) OpenGL extensions: GL_EXT_texture_rectangle,

This driver supports both 2D and rectangle textures. The hardware
does as well. If mode 1 does not work in GEM then that looks like
a driver bug to me.

It seems to be a bug in Gem because mode 1 works fine after entering
mode 0. Its just when the patch starts up that it doesn't work.
After sending a [mode 0(, then both [mode 1( and [mode 0( work.

.hc

Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli

On Dec 6, 2006, at 4:02 PM, chris clepper wrote:

On 12/6/06, Hans-Christoph Steiner hans@eds.org wrote:

It seems to be a bug in Gem because mode 1 works fine after
entering mode 0. Its just when the patch starts up that it doesn't
work. After sending a [mode 0(, then both [mode 1( and [mode 0( work.

Here's the problem:

You build a binary where the GL driver you build against tells you
that it supports rectangle textures. Then when you run the binary
using that same GL driver the texturing is not right. Where is the
bug?

[mode 1( works fine after you send a [mode 0(. So it seems to be
some kind of init thing. The first time when [pix_texture] loads, it
defaults to mode 1, but doesn't work properly. Then I send a [mode 0 ( message, and it works.

Now, I send a [mode 1( message, and it still works. From here on
out, both [mode 0( and [mode 1( work. Or are you saying that you
cannot switch back to [mode 1( once you switch to [mode 0(? The
message only takes effect the first time you send it?

.hc

                                           http://at.or.at/hans/

On Dec 6, 2006, at 4:34 PM, chris clepper wrote:

On 12/6/06, Hans-Christoph Steiner hans@eds.org wrote:

Now, I send a [mode 1( message, and it still works. From here on
out, both [mode 0( and [mode 1( work. Or are you saying that you
cannot switch back to [mode 1( once you switch to [mode 0(? The
message only takes effect the first time you send it?

What sort of output do you see in the console?

I can give you the exact transcript tomorrow, but it was basically:

using mode 0:GL_TEXTURE_2D using mode 1:GL_TEXTURE_RECTANGLE_EXT using mode 0:GL_TEXTURE_2D using mode 1:GL_TEXTURE_RECTANGLE_EXT using mode 0:GL_TEXTURE_2D

.hc

Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom

On 12/6/06, David Powers cyborgk@gmail.com wrote:

Hi,

I believe this is a known bug, Chris Clepper had helped me fix this problem actually with GEM.

It is sort of a known 'bug'. ATI and Nvidia hardware on OSX and Windows do not have this 'bug' and I don't think it is happening with Nvidia's Linux driver although I haven't personally tested it. So the highest performing configurations work just fine. I don't have any hardware that has this 'bug' so what can I do?

On Tue, 2006-12-05 at 19:48 -0500, marius schebella wrote:

yup, still no luck with Gem here... when compiling cvs Gem on the machine with the Radeon X300 card, I got rid of the glDeleteProgramsNV error. but I can not play any movies. Pd either crashed or showed only one color.

do you have any other libs loaded besides Gem? i'd like to know, which. i had a handfull of problems with gem before and it turned out that these problems were conflicts between gem and other libs (pidip, gridflow, 3dp and maybe some others). when testing gem, try first to load it alone, with no other libs loaded. it also seemed to me, that the order of how the libs are loaded has some effect, whether gem works correctly or not.

I downgraded ubuntu to libgl1-mesa 6.4 (before it was 6.5). also no glDeleteProgramsNV problem, but no movies ( I test with the examples patch from the help.) at least Pd does not crash... So I am back to the debian package of Gem (v 0.90) which does not make problems. iohannes, what do you want to know from me to locate that problem? with ...Gem/04.pix/05.film.pd I get the following console output: pix_film:: quicktime support pix_film:: libmpeg3 support pix_film:: libaviplay support pix_film:: libmpeg support GEM: Start rendering GL: invalid value [pix_filmNEW]: opening /usr/local/lib/pd//doc/examples/Gem/04.pix/../data/anim-1.mov with format 1908 [pix_filmNEW]: ... [pix_filmNEW]: ... [pix_filmNEW]: loaded file: /usr/local/lib/pd//doc/examples/Gem/04.pix/../data/anim-1.mov with 90 frames (256x256) at 30.000000 fps but the texture is not rendered correctly. The whole cube is brownish. marius.

this might be not a problem of [pix_film] or [pix_image], but of [pix_texture]. send a message [mode 0( to it, then the texture should be applied as expected.

roman

2006/12/5, Hans-Christoph Steiner hans@eds.org:

...

On Dec 5, 2006, at 4:01 PM, chris clepper wrote: On 12/5/06, Hans-Christoph Steiner hans@eds.org wrote:

...

So you are saying that they removed NV compatibility from in mesa when going from 6.4 to 6.5?

This is just one specific extension for Nvidia specific shaders. I don't know if anyone is using those shaders, but we could probably get by only with the ARB spec support.

We are downgrading to mesa 6.4 because we know it works there. We also tried compiling against the 6.5 version. It loaded, but had other issues. Actually, its the same bug that was reported for the autobuilds on Mac/Intel. The video was playing but it was like it was only playing one pixel of the whole video, spread out over the whole area that was being textured. This was with the examples/Gem/4.pix/05.movie.pd

.hc

---

                                          http://at.or.at/hans/

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

On Tue, 2006-12-05 at 17:58 -0500, Hans-Christoph Steiner wrote:

On Dec 5, 2006, at 4:01 PM, chris clepper wrote:

...

On 12/5/06, Hans-Christoph Steiner hans@eds.org wrote:

    So you are saying that they removed NV compatibility from in
    mesa
    when going from 6.4 to 6.5?

This is just one specific extension for Nvidia specific shaders. I don't know if anyone is using those shaders, but we could probably get by only with the ARB spec support.

We are downgrading to mesa 6.4 because we know it works there. We also tried compiling against the 6.5 version. It loaded, but had other issues. Actually, its the same bug that was reported for the autobuilds on Mac/Intel. The video was playing but it was like it was only playing one pixel of the whole video, spread out over the whole area that was being textured. This was with the examples/Gem/4.pix/05.movie.pd

it's the same here. in order to texture an image or a video 'normally', i need to send a message [mode 0( first to [pix_texture], then it looks good.

roman

___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

On Dec 6, 2006, at 4:44 AM, IOhannes m zmoelnig wrote:

Hans-Christoph Steiner wrote:

...

So you are saying that they removed NV compatibility from in mesa
when going from 6.4 to 6.5?

no. i am saying that it is not my business to keep track of what mesa (or any other library used) changes between their upgrades. it is my business to detect what the currently installed library is capable of. when mesa-6.4 supports glProgramDeleteNV() and mesa-6.5 does not, feel free to submit a bug-report to mesa. i do not care!

The optimization stuff you guys have done is definitely very
important. It would also be excellent if you would help produce a
binary distro that worked on as many machines as possible, so that we
have more people using Gem, and have to spend less time answering
annoying questions like these.

.hc

As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin

Hans-Christoph Steiner wrote:

root@debian-stable-i386:~ > lspci 0000:01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c)

So these builds do not run on the machine they were built on.

hi hans, actually we do not know... it could run on the autobuild machine, but not on the one I tested, because they have different ATI cards. (Radeon X300). so that looks like a general problem of the autobuild farm, which has to balance hardware optimization against universality. maybe you will have to configure the gem autobuild to run without any hw features? marius.

On Mon, 4 Dec 2006 11:03:39 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:

When I was born, "manual" was all about punching holes in cardboard and feeding it to the card-reader. However, when I actually started programming, "manual" was about having to press Play at the same time and listen to the sound of files recorded at 600 bauds, and pressing Fast-Forward to skip over them, and having to listen to the files to count how many had been skipped over and reading the sleeve to make sure I got to the right file. It was not as manual as splicing tapes though.

I mean, one should marvel at how much something like dpkg is automatic :)

You lucky bastard. We had suck the air out of vacuum tubes using our own breath. And we were grateful!

:)

Tsk! And you try telling kids that today and they won't believe you. ;)

On Tue, 05 Dec 2006 21:19:18 +0100 Thomas Mayer thomas@dergrossebruder.org wrote:

padawan12 wrote:

...

On Mon, 4 Dec 2006 11:03:39 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:

...

When I was born, "manual" was all about punching holes in cardboard and feeding it to the card-reader. However, when I actually started programming, "manual" was about having to press Play at the same time and listen to the sound of files recorded at 600 bauds, and pressing Fast-Forward to skip over them, and having to listen to the files to count how many had been skipped over and reading the sleeve to make sure I got to the right file. It was not as manual as splicing tapes though.

I mean, one should marvel at how much something like dpkg is automatic :)

You lucky bastard. We had suck the air out of vacuum tubes using our own breath. And we were grateful!

:)

You lucky bastard! Where I grew up, we had no air and had to live on anaerobic muscle work ;)

cu Thomas

"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list