nVIDIA woes

[Jason Freeman]

1) I am using a Pentium III 866 machine, so if our problems are related, I
don't think the cause is the processor.

2) While there is a netreceive object in my patch, I have not had a socket
connection open for most of my testing.

3) In addition to my previously mentioned problem of rendering large font
sizes using nearly 100% CPU, using the pix_draw object also consumes nearly
100% CPU. Again, this CPU usage is from XF86 4.0 and not from pd.

4) To circumvent my current problem, I've redone all the text in my patch as
images and texture mapped them to squares. While this consumes very little
processor time, it is rather memory hungry (both from pd and from X). But it
seems to work for now.

5) One more problem of note: With the nVidia drivers only (not with MesaGL),
my Xserver crashes whenever I switch workspaces and a GEM window is open
with rendering turned on. If I turn rendering off, then I can switch
workspaces with no problems.

Any suggestions about any of the problems, or the previously mentioned
problem of the text3d object causing pd/GEM to crash, would be greatly
appreciated.

Thanks!
--Jason

on 6/19/00 4:04 AM, forum::für::umläute wrote:

> leberre at convergence.de wrote:
>> 
>> * Jason Freeman (jason_freeman34 at hotmail.com) [000616 21:52]:
>>> Hi all -- I'm having some problems with truetype font rendering in pd/GEM,
>>> and was wondering if anyone else has had similar problems or has any
>>> suggestions. I am using a Dell 866 Pentium machine with Red Hat 6.2, a TNT2
>>> chipset graphics card, and the nVIDIA OpenGL drivers and XFree86 4.0 and
>>> freetype 1.3.1.
>>> 
>>> 1) The "text3d" object does not work at all. When trying to use the example
>>> patch included with gem 0.83, for instance, pd/GEM crashes as soon as I turn
>>> on rendering. I previously had this same problem on a similar linux machine
>>> that was just using the standard Mesa3d drivers. There are no error messages
>>> prior to crashing.
>>> 
>>> 2) The "text2d" object is incredibly power hungry with large font sizes.
>>> Pd's CPU usage stays very low, but as I increase the font size of a "text2d"
>>> object, even if it only contains a single character, the X server CPU usage
>>> quickly jumps to almost 100%. This did not happen on other machines that
>>> were using Mesa3d drivers instead of the nVidia GL drivers.
>>> 
>>> Any ideas would be appreciated -- or even clues as to whether the problem
>>> lies in GEM, the nvidia drivers, or the freetype libraries.
>>> 
>> I experienced the same thing using GEM
>> on a new powerbook g3 running linuxppc.
>> 
>> In fact, for me, when I try to run an example using text,
>> (gemChangeText.pd for example)
>> the program look for the "arial.ttf", and it didn't find
>> it because it is named "Arial.ttf".
>> I rename the "Arial" into "arial" without more success.
>> 
> 
> on mesaGL machines::
> I really did solve this problem by renaming "Arial.ttf" to "arial.ttf";
> the wrong uppercase seems to derived from using MS's Win32 platforms and
> porting filesystems to Linux...
> then i am using freetype-1.3.1 too, so i do not think that this is the
> problem
> 
> on machines with nVidiaGL drivers::
> i needed to do graphics with a number of various objects (very basic
> ones, cubes, spheres, cylinders, teapots, ...) being texturized and
> moved; mesaGL is definitely too slow (just look at the
> gem2.moveImages.pd -demopatch for textures (uähh)) so i tried
> hardware-acceleration
> I experienced several unstabilities when using a an ErazorX2 (with the
> Geforce256 chipset) on an Athlon K7-650MHz System, running Debian with
> kernel-2.2.15 (kernel-2.4 (featuring SlotA-mainboards) was REALLY
> unstable...), freetype-1.3.1 XFree4.0 and nVidia's native drivers 0.9-2.
> I had a very hard time getting the XFree4.0 to run (there is no Debian
> support yet !) and needed another week or so to kill all hints of
> mesaGL;
> using the hardware-acceleration of the card was really cool by then (and
> very fast: CPU load of 5%-10% total), but still i have a problem
> concerning screen-freezes; there are two kinds or these crashes ::
> 1. Screen freezes and X needs 98.0 to 99.5 percent of the CPU; this is
> the good case since the computer is still controlable; (i think) pd
> still reacts to netcommands
> it seems to me, as if Jason experienced a very similar scenario : since
> i am not using any "font" objects at all, it is quite unlikely to search
> for the bug in the freetype-libs.
> 2. Screen freezes and computer locks completely (can't "ping" it anymore
> !); the only way to get out of this is to kick the reset-button.
> (or do another power-failure); this is obviously the bad case
> 
> I thought the problem was ::
> a) on the AMD-system (very likely; i will have some tries this week on a
> very similar system-configuration but with a PIII-733 processor and an
> ASUS-v6600 card (same chip))
> which processor do you use, Jason ?
> b) hidden in the XFree4.0, since it seems as if this was still quite
> unstable (therefore it is not yet released with Debian)
> c) on the netsend/netreceive-objects in pd; we are using three PC's that
> are connected via ethernet; since the TCP/IP connection was very crashy
> (even when all the PC's where running, not to mention the problems, when
> one of them crashed/was rebooting or something similar.), we decided to
> use UDP; not using the netconnection a test-patch did quite well (for
> about 12 hours, then i stopped testing since i had work to do); using
> the netreceive (the graphical-interface is slave) led to the mentioned
> crashes, but i'm not very sure if this is really the problem
> 
> on the other hand, i think, Jason's text - problem might not be
> connected to the net, at least, I do believe that your core-testpatch
> doesn't have netconnection, does it ?
> 
> mfg.fasd.t
> iohannes
> 
>