Back to the texturing problem I reported a couple of weeks ago. The
problem: objects are textured on the first frame, but not on
subsequent frames.
I tried Brian's suggestions - using Mesa with "incomplete()" enabled
to report probs w/ an incomplete texturing environment, and trying
tilesortspu.Conf('bucket_mode', 'Broadcast'). Neither of these
suggestions appeared to have made any difference. I did feed Mesa a
bogus texture state to see that it would indeed bitch at me, and it
indeed did (its complaint wasn't entirely accurate, but I'll take
that up with Brian separately).
FWIW, I tried the OpenRM app using Mesa (w/o chromium) with incomplete()
enabled, and Mesa (4.1) didn't complain about anything.
The logs I sent out a couple of weeks ago were generated by having
the printspu on the server. The logs clearly showed a massive
difference in OpenGL state when using, or not, the tilesort spu.
The OpenGL state when using the tilesort spu was way wrong.
I've tried modifying the city.c demo to have it more closely
replicate how the OpenRM programs work - use vertex arrays,
pushattrib/popattrib, etc - but I'm not able to make city-wes.c
misbehave. The only remaining difference between city-wes.c
and the OpenRM apps is a bit more heavy-handedness in how
the OpenGL state is manipulated.
Humper made a suggestion that I will try next:
--
3) Generate a human-readable dump of what's happening on the client and
server side.
4) Generate a machine-readable dump of all the client's OpenGL calls,
using something akin to the 'dump.conf' configuration file. Basically
you hook your application up to the pack SPU, and give it a filename as
a target.
5) Play back the dump from #4 through the tilesort SPU (see
playback.conf for a place to get started) and verify that the bug still
happens (it should).
6) Send the output from #3 and #4 to the chromium-dev mailing list.
This way, we can reproduce the bug without having your application, but
the output of #3 is akin to having "source code".
--
Brian Paul wrote:
>
> I'd use Mesa to debug this. When you have all your texture state
> set up but texturing still isn't happening it's usually because of
> texture "incompleteness" or "inconsistancy". For example, having
> a missing or mis-sized mipmap level will cause the texture to be
> flagged as incomplete, thus disabling texturing. There's lots of
> possible causes.
>
> In Mesa/src/texobj.c look for this code:
>
> /*
> * Report why a texture object is incomplete. (for debug only)
> */
> #if 0
> static void
> incomplete(const struct gl_texture_object *t, const char *why)
> {
> printf("Texture Obj %d incomplete because: %s\n", t->Name, why);
> }
> #else
> #define incomplete(a, b)
> #endif
>
> Change the #if 0 to #if 1, recompile, relink, etc. Mesa will print
> diagnostics if texture completeness is the problem.
>
> Running with a single tile would further simplify the testing.
> Also, you might try tilesortspu.Conf('bucket_mode', 'Broadcast').
>
> -Brian
>
> Wes Bethel wrote:
> > FYI, I've been digging a little deeper into this problem. It seems
> > that the city demo uses pretty much the same sequence of steps, and
> > it works fine. In addition, other non-OpenRM programs also work
> > fine, so it would appear that the problem described below has
> > something to do with OpenRM's texture management code, rather
> > than something in CR. Will keep you posted.
> >
> > wes
> >
> > Wes Bethel wrote:
> >
> >>Again, this is a situation in which a program that works fine
> >>using crdemo.conf shows a problem when using a config file
> >>that does tiling (e.g., retile).
> >>
> >>The program (or, more specifically, the texture management stuff
> >>in OpenRM) will, on the first frame, build an OpenGL texture
> >>by doing a glGenTextures, and downloading a bunch of pixel
> >>data. There's a glBindTexture in there somewhere, along with a
> >>glEnable(GL_TEXTURE_[1D,2D or 3D]). Then the geom is drawn, and
> >>is properly textured on the first frame.
> >>
> >>On subsequent frames, the program only does the glBindTexture() and
> >>glEnable(GL_TEXTURE_*), referring to the texture object ID that was
> >>built during a previous frame. However, when drawn, it is as if
> >>there is no texture at all. The texturing disappears.
> >>
> >>This is all using static textures: frame 1 is OK, frame 1+n is wrong.
> >>
> >>A different demo uses dynamic textures, and it displays OK. That
> >>program will replace the pixel contents of the texture on each
> >>frame using glTexSubImage*D, but does not create a new texture
> >>object id; it just reuses the old one as the texture is the same
> >>size, it just has new texels.
--
Wes Bethel wbethel@...
R3vis Corporation http://www.r3vis.com/
Phone: 415-898-0814 FAX: 415-898-2814

Hello,
I really hope I haven't sent this multiple times, but I'm (or rather the
list is) having trouble with my school's mail server.
I was present at the Birds of a Feather meeting for Chromium at SIGGRAPH
2002. While there, somebody mentioned all of the research that they had
done for the Stanford Beowulf cluster, and said that he could send that
out to the lists. I don't remember seeing this information, and I don't
see it in the SourceForge archieve. I could have just missed it. Anyway,
our school is starting to build a new cluster and, if possible, I'd like
to see the results of research that people, not just Stanford, have done
for this. Good hardware, bad hardware... etc.
Thanks,
Keith Jeffery
jeff2619@...

I posted this a little while back and got no responce, so I decided to post
it again.
Chromium compiled fine and on each machine I ran the Atlantis demo and it
works fine. When I try to run the crdemo.conf on each node it works fine.
But when I try to run anything through the network I get a Segmentation
fault on the nodes. I modified the followint line on the warp_demo.conf :
app_node_host = 'localhost'
render_node1_host = 'localhost'
render_node2_host = 'localhost'
to:
app_node_host = 'localhost'
render_node1_host = 'node2'
render_node2_host = 'localhost'
just so I could test the network.
The gdb output from the node's crserver is:
(gdb) run
Starting program: /usr/local/bin/crserver
[New Thread 1024 (LWP 6573)]
CR Warning(SDI-Vis2:6573): Networking already initialized!
CR Warning(SDI-Vis2:6573): Networking already initialized!
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 6573)]
0x40458279 in __nvsym15203 () from /usr/lib/libGL.so
This made me curious so I went on the node and started atlantis demo again/
It works fine. Then I decided to run atlantis but calling it through ssh
from the master node. Basicaly I ssh-ed over to the node and started up
altantis. This would make atlantis come up on the master node and run(very
slowly of course). When I tried this I got another segmentation fault. gdb
output for that is:
(gdb) run
Starting program: /usr/local/bin/atlantis
Program received signal SIGSEGV, Segmentation fault.
0x4008a279 in __nvsym15203 () at eval.c:41
41 eval.c: No such file or directory.
in eval.c
I am running RedHat7.2 with Chromium1.0 and NVIDIA Quatro cards with the
NVIDIA kernel and GLX RPMs.
Thanks for the help,
-Cesar Delgado
_________________________________________________________________
Unlimited Internet access -- and 2 months free! Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp

In reference to my earlier e-mail about display lists and viewports. We
have found that display lists, viewports, and gluSphere do not work
together on our wall. HOWEVER, glutSolidSphere, display lists, and
viewports work very well on our system. Perhaps the quadric patches,
via a display list, cause some discomfort in Chromium.
Mike Walterman

Hello,
We are running into some problems with Display Lists and Viewports.
Our application is drawing a large number of spheres (chemistry
simulation) as a stereo image pair. To generate the spheres, we are
using gluSphere. To generate the stereo pair, we are using two
viewports (one for the left image and one for the right). We are using
a display list with gluSphere in that list to speed up the rendering.
Running this application on a single workstation produces the ecpected
results.
When we run the application on Chromium, the display is all messed
up. However, when we render just one of the images, and do not change
the viewport setting, the rendered image is once again correct. The
rendered image is only incorrect when more than one viewport is used.
Also, when the display list is replaced by a direct call to
gluSphere, Chromium produces the correct stereo pair. Any thoughts on
how display list - viewport interaction could mess things up?
Thanks,
Mike Walterman

Hello:
I'm running Open Inventor(Linux) in a 2x2 display system and I noticed
that:
1) The application run too slow. Somebody knows where the tradeoff
are? Can be the network?
2) The 3D objects with color, they are display ok but without
color. Somebody knows what OpenGL function Inventor uses to display
colors? Is that function is supported by Chromium?
Thanks.
--JC

I've used the bash prompt exclusively on Windows and haven't run
into any problems. However, you do need to be sure that you=20
have set up the environment variables that Visual Studio needs to
find include and library files. I do this in my ~/.profile. Remember
that these variables want to use paths in Windows format, not UNIX
format.
--
Michael Brodeur=20
Hewlett-Packard Company email: michael.brodeur@...
110 Spit Brook Road, ZKO2/3Q08 phone: (603) 884-0267
Nashua, NH 03062 =20
-----Original Message-----
From: Greg Humphreys [mailto:humper@...]
Sent: Tuesday, October 22, 2002 3:34 PM
To: 'Stephen Ehmann'; chromium-users@...
Subject: RE: [Chromium-users] build problem on Cygwin
I've only ever built Chromium from the windows Command Prompt, so if
you're doing it from bash you *might* run into a few snags, although I
can't quite imagine what those would be.
You might want to talk to Justin Hensley there at UNC -- he's a regular
Chromium user.
--
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/=20

Help!
I am having some difficulty building on a Win32 machine with Cygwin installed.
I upgraded to Python 2.2 and Perl 5.x and went to the Chromium-1.0/cr directory.
I am building from within a cygwin shell.
1) I typed "make debug" and got the error:
make: *** No rule to make target `debug'. Stop.
2) I typed "make" and got the output and error:
-------------------------------------------------------------------------------
Just parsing the OpenGL header file!
-------------------------------------------------------------------------------
Here we go...
Done!
-------------------------------------------------------------------------------
Building crutil.dll for WIN_NT (RELEASE)
-------------------------------------------------------------------------------
Making the opcode debugger...
Compiling make[2]: *** [../built/crutil/WIN_NT/bbox.obj] Error 255
make[1]: *** [dep] Error 2
make: *** [util.subdir] Error 2
3) I also tried a "make clean" before 1) or 2) but I got the smae results.
I downloaded Chromium from:
http://sourceforge.net/project/showfiles.php?group_id=16529&release_id=113829
And then clicked on cr-1.0.zip.
Any help is greatly appreciated.
Thanks,
--
Stephen A. Ehmann

Cool!
During the last summer I also did a projectors dynamic calibration and
photometric calibration that support arbitrary overlap and arbitrary
projectors position in any projection surface(i.e planar, curve).
You can see images and know how it works at
http://dmn.netlab.uky.edu/~jesus/calibration.html . I haven't work in the
source since last month, I will going to port it to the new Chromium version
and at some moment next week it will be on-line. If you want to code before
that, let me know.
--Jesus Caban
Justin Hensley <hensley@...> said:
> We here at UNC-chapel hill are running a warped tile display (aka
> pixelFlex), with ceiling mounted projectos. There is a paper about our
> work in IEEE Visualization 2001. Since the paper, we have migrated of
> off a large SGI onto a linux based cluster. People going to
> Supercomputting in Baltimore should be able to see a pixelFlex display
> at Sandia/CA's booth.
>
> We have developed our own calibration tools (camera based closed loop
> calibration). PixelFlex can run either on a modified version of
> chromium (I modified crserver add the prewarp to the projection matrix.
> This was done as a quick and dirty solution done before the warp tile
> work was added into chromium), or with our own custom library. Our
> current work focuses on photometric calibration issues. Our code is
> pretty tied to our setup (a sony firewire camera), but I'm sure that my
> advisor would be willing to share our calibration code.
>
> http://www.cs.unc.edu/Research/ootf/index.htm
> http://www.cs.unc.edu/Research/ootf/projects/pixel.htm
> (unfortunely, the web page is a little out of date)
>
> -justin
> Graduate Student
> Department of Computer Science
> University of North Carolina-Chapel Hill
>
> Karl Rasche wrote:
>
> >Hey Mike,
> >
> >
> >
> >>>is that matrix applied as an affine transformation:
> >>>
> >>>
> >
> >
> >
> >>>Or is it applied as a fractional linear (i.e. perspective corrected)
> >>>transformation:
> >>>
> >>>
> >
> >It would be the latter, as the whole thing is just gobbed into the
> >projection matrix.
> >
> >On a somewhat related note, is anyone else out there running warped tiles?
> >I'm wondering about the usefullness of putting together good calibration
> >utilities
> >
> >karl
> >
> > [k a r l r a s c h e] "We have no tolerance for dysfunctional
> > PC's, and are swift to employ the floor
> > rkarl@... tool as a method of extracting the
> > meaty nut-pulp contained within XT cases
> > and old phone systems" --accrc.org
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Chromium-users mailing list
> >Chromium-users@...
> >https://lists.sourceforge.net/lists/listinfo/chromium-users
> >
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Chromium-users mailing list
> Chromium-users@...
> https://lists.sourceforge.net/lists/listinfo/chromium-users
>
--

We here at UNC-chapel hill are running a warped tile display (aka
pixelFlex), with ceiling mounted projectos. There is a paper about our
work in IEEE Visualization 2001. Since the paper, we have migrated of
off a large SGI onto a linux based cluster. People going to
Supercomputting in Baltimore should be able to see a pixelFlex display
at Sandia/CA's booth.
We have developed our own calibration tools (camera based closed loop
calibration). PixelFlex can run either on a modified version of
chromium (I modified crserver add the prewarp to the projection matrix.
This was done as a quick and dirty solution done before the warp tile
work was added into chromium), or with our own custom library. Our
current work focuses on photometric calibration issues. Our code is
pretty tied to our setup (a sony firewire camera), but I'm sure that my
advisor would be willing to share our calibration code.
http://www.cs.unc.edu/Research/ootf/index.htmhttp://www.cs.unc.edu/Research/ootf/projects/pixel.htm
(unfortunely, the web page is a little out of date)
-justin
Graduate Student
Department of Computer Science
University of North Carolina-Chapel Hill
Karl Rasche wrote:
>Hey Mike,
>
>
>
>>>is that matrix applied as an affine transformation:
>>>
>>>
>
>
>
>>>Or is it applied as a fractional linear (i.e. perspective corrected)
>>>transformation:
>>>
>>>
>
>It would be the latter, as the whole thing is just gobbed into the
>projection matrix.
>
>On a somewhat related note, is anyone else out there running warped tiles?
>I'm wondering about the usefullness of putting together good calibration
>utilities
>
>karl
>
> [k a r l r a s c h e] "We have no tolerance for dysfunctional
> PC's, and are swift to employ the floor
> rkarl@... tool as a method of extracting the
> meaty nut-pulp contained within XT cases
> and old phone systems" --accrc.org
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Chromium-users mailing list
>Chromium-users@...
>https://lists.sourceforge.net/lists/listinfo/chromium-users
>
>

Hey Mike,
Let me make a pre-pot-of-coffee stab at explaining the setup :)
> 1. the line "tilesort_spu.Conf('local_tile_spec', 1)" causes our system
> to display garbage. When I remove this line, the system runs as
> expected, applying the warping coeffs.
Setting tilesort_spu.localTileSpec [this is what that option sets] causes
the tiles to be transformed by the matrix provided for the display the
tile is part of. This transformed tile is used when bucketing.
It also automatically sets the bucket mode to WARPED_GRID.
cr_server.localTileSpec is what controls if the alignment matrix makes it
into the projection matrix. So, not setting tilesort_spu.localTileSpec
will still allow some correction to be done, but bucketing may be all
horked up.
When bucketing with WARPED_GRID, the bbox is tested for overlap against
the quad representing the tile which was computed earlier. I'm fairly sure
the overlap test will only hold for convex quads, though, if you need
concave support, its probably easier to poke your projector :)
I'm not quite sure what the effect would be when setting
cr_server.localTileSpec, but not tilesort_spu.localTileSpec.. Are you
setting 'Warped Grid' as well?
> 2. the line "tilesort_spu.Conf('bucket_mode', 'Warped Grid')" causes
> the MTU buffer to get extremely large. Using 'Uniform Grid' reduces the
> MTU back to normal, and our coeffs are still applied. This allows us to
> run myrinet.
I would think that running a uniform grid (or even a rectangular grid)
with tiles which are not uniform (and probably not rectangular) would
cause weirdness. I'll take a look at it.
> 3. In the file server_config.c, the forward warping trasformation is
> normailzed using a bounding box computed by projecting the corners of
> normalized destination space back into source space. I believe that
> this normalization is corrupting my calibration matrix.
This also happens in tilesortspu_config.c, when transforming tiles into
mural space. crHullInteriorBox() goes through a bunch of contortions to
fit a box inside the union of all the tiles, and it usually fails.
> I think what is needed is a clear geometric description of
> Chromium's calibration model. I suspect that my model and method may be
> different from yours. Tools would be great as well.
I'm doing something like the following:
- Pick a display to be the 'master'. The center of this display
will be the origin of our 'mural space'.
- Using point correspondances, find the extents of other displays
in mural space.
- Compute the transformation from a displays' normalized space
into mural space, and the inverse.
- Feed these transformations into cr.
This may not even be close to the Right thing to do, but it seems to work
fairly well here.
As for tools, even I don't like to use mine :) Its nagging me for a
friendler version. There is probably quite a bit that could be done in
this area, especially with all the hardware and OSes floating about..
Does that help any? Please let me know if there are things that should be
better explained.
karl
[k a r l r a s c h e] "We have no tolerance for dysfunctional
PC's, and are swift to employ the floor
rkarl@... tool as a method of extracting the
meaty nut-pulp contained within XT cases
and old phone systems" --accrc.org

Hi Karl,
Thanks for the reply. I did discover some things last night realted
to our system:
1. the line "tilesort_spu.Conf('local_tile_spec', 1)" causes our system
to display garbage. When I remove this line, the system runs as
expected, applying the warping coeffs.
2. the line "tilesort_spu.Conf('bucket_mode', 'Warped Grid')" causes
the MTU buffer to get extremely large. Using 'Uniform Grid' reduces the
MTU back to normal, and our coeffs are still applied. This allows us to
run myrinet.
3. In the file server_config.c, the forward warping trasformation is
normailzed using a bounding box computed by projecting the corners of
normalized destination space back into source space. I believe that
this normalization is corrupting my calibration matrix.
I think what is needed is a clear geometric description of
Chromium's calibration model. I suspect that my model and method may be
different from yours. Tools would be great as well.
Thanks,
Mike
Karl Rasche wrote:
>Hey Mike,
>
>>>is that matrix applied as an affine transformation:
>>>
>
>>>Or is it applied as a fractional linear (i.e. perspective corrected)
>>>transformation:
>>>
>
>It would be the latter, as the whole thing is just gobbed into the
>projection matrix.
>
>On a somewhat related note, is anyone else out there running warped tiles?
>I'm wondering about the usefullness of putting together good calibration
>utilities
>
>karl
>
> [k a r l r a s c h e] "We have no tolerance for dysfunctional
> PC's, and are swift to employ the floor
> rkarl@... tool as a method of extracting the
> meaty nut-pulp contained within XT cases
> and old phone systems" --accrc.org
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Chromium-users mailing list
>Chromium-users@...
>https://lists.sourceforge.net/lists/listinfo/chromium-users
>
>

Hey Mike,
> > is that matrix applied as an affine transformation:
> > Or is it applied as a fractional linear (i.e. perspective corrected)
> > transformation:
It would be the latter, as the whole thing is just gobbed into the
projection matrix.
On a somewhat related note, is anyone else out there running warped tiles?
I'm wondering about the usefullness of putting together good calibration
utilities
karl
[k a r l r a s c h e] "We have no tolerance for dysfunctional
PC's, and are swift to employ the floor
rkarl@... tool as a method of extracting the
meaty nut-pulp contained within XT cases
and old phone systems" --accrc.org

I'll give the mesa "incomplete" test a whirl. In the meantime,
I've determined that my texturing gets fouled up when the tilesort
spu is present.
I ran a couple of tests using a lightly modified crdemo.conf. The
mods include adding a print spu to the server node, and adding
the array spu so that my vertex array stuff would work. In one
test, I did not use the tilesort spu. The application works great.
In the other test, I used the tilesort spu, and frame 1 renders OK,
but frames 1+N show lack of texturing.
Looking at the output of the print spu, I am really surprised by
what I see in the dump when tilesort is involved. There is a lot
of weird OpenGL state activity present that was not in the
original application. Careful examination of the withTileSort
logfile clearly shows that texturing is disabled the second time
the quad is rendered. I never turned off texturing. It should be
disabled implicitly when a glPopAttrib occurs. In the second
frame, texturing is explicitly turned back on by OpenRM, but that
glEnable() doesn't appear to show up in this logfile. It is as
if the CR state tracking code went beserk and started to ignore
all my state changes. Note that these state changes are *not*
encapsulated in display lists. Only wads of geometry are encapsulated
into display lists.
As you look at the noTileSort logfile, as a baseline, you'll see
a lot of arguably unnecessary state changes. These are produced
by OpenRM, and it's good for me to see these changes in order to
improve the quality of OpenRM's state tracking/changing stuff.
The noTileSort logfile exactly reproduces the state changes
requested by the application. The withTileSort logfile is barely
recognizable as being the same application.
thanks,
wes
Brian Paul wrote:
>
> I'd use Mesa to debug this. When you have all your texture state
> set up but texturing still isn't happening it's usually because of
> texture "incompleteness" or "inconsistancy". For example, having
> a missing or mis-sized mipmap level will cause the texture to be
> flagged as incomplete, thus disabling texturing. There's lots of
> possible causes.
>
> In Mesa/src/texobj.c look for this code:
>
> /*
> * Report why a texture object is incomplete. (for debug only)
> */
> #if 0
> static void
> incomplete(const struct gl_texture_object *t, const char *why)
> {
> printf("Texture Obj %d incomplete because: %s\n", t->Name, why);
> }
> #else
> #define incomplete(a, b)
> #endif
>
> Change the #if 0 to #if 1, recompile, relink, etc. Mesa will print
> diagnostics if texture completeness is the problem.
>
> Running with a single tile would further simplify the testing.
> Also, you might try tilesortspu.Conf('bucket_mode', 'Broadcast').
>
--
Wes Bethel wbethel@...
R3vis Corporation http://www.r3vis.com/
Phone: 415-898-0814 FAX: 415-898-2814

We're using the drivers that Xig provides (www.xig.com). Unfortunately, I
don't know if I have enough information for them to get an idea of what's
going wrong. The core dump isn't very meaningful, and there seems to be
some kinda arithmetic error going on :-\
-Dave
On Thu, 17 Oct 2002, Michael Houston wrote:
> We've never really gone through the hassle of getting the ATI drivers
> "fixed". It took an incredible amount of work to get the Nvidia drivers
> working, and they still don't completely work under Windows (Sort-Last).
>
> Are you using the open source drivers or the ATI FireGL drivers? I
> would ping ATI about this. The way we got through this with NVidia was
> to set up a really good relationship with the linux driver folks and
> help them get Chromium setup.
>
> On a side note, Chromium does not run on the 9700 (R300) in Windows
> either....
>
> -Mike
>
> Sean Ahern wrote:
>
> >David Jones wrote:
> >
> >
> >>Has anyone used the ATI Radeon 8500 w/ Chromium under Linux. We were just
> >>trying out a perf test using Myrinet, but the Render spu(s) die very badly
> >>as you can see from the output below.
> >>
> >>This is using the latest cvs of chromium. It was built originally w/
> >>gm libs, but I was using tcpip for testing. I get this error even when
> >>using crdemo.conf on a local machine w/ tilesort. Stuff works fine w/ the
> >>pack spu, however.
> >>
> >>Any ideas?
> >>
> >>
> >...
> >
> >
> >>Floating exception (core dumped)
> >>
> >>
> >
> >Where's the core say it's failing?
> >
> >-Sean
> >
> >__
> >seanahern@...
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by: viaVerio will pay you up to
> >$1,000 for every account that you consolidate with us.
> >http://ad.doubleclick.net/clk;4749864;7604308;v?
> >http://www.viaverio.com/consolidator/osdn.cfm
> >_______________________________________________
> >Chromium-users mailing list
> >Chromium-users@...
> >https://lists.sourceforge.net/lists/listinfo/chromium-users
> >
> >
>
>

We've never really gone through the hassle of getting the ATI drivers
"fixed". It took an incredible amount of work to get the Nvidia drivers
working, and they still don't completely work under Windows (Sort-Last).
Are you using the open source drivers or the ATI FireGL drivers? I
would ping ATI about this. The way we got through this with NVidia was
to set up a really good relationship with the linux driver folks and
help them get Chromium setup.
On a side note, Chromium does not run on the 9700 (R300) in Windows
either....
-Mike
Sean Ahern wrote:
>David Jones wrote:
>
>
>>Has anyone used the ATI Radeon 8500 w/ Chromium under Linux. We were just
>>trying out a perf test using Myrinet, but the Render spu(s) die very badly
>>as you can see from the output below.
>>
>>This is using the latest cvs of chromium. It was built originally w/
>>gm libs, but I was using tcpip for testing. I get this error even when
>>using crdemo.conf on a local machine w/ tilesort. Stuff works fine w/ the
>>pack spu, however.
>>
>>Any ideas?
>>
>>
>...
>
>
>>Floating exception (core dumped)
>>
>>
>
>Where's the core say it's failing?
>
>-Sean
>
>__
>seanahern@...
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: viaVerio will pay you up to
>$1,000 for every account that you consolidate with us.
>http://ad.doubleclick.net/clk;4749864;7604308;v?
>http://www.viaverio.com/consolidator/osdn.cfm
>_______________________________________________
>Chromium-users mailing list
>Chromium-users@...
>https://lists.sourceforge.net/lists/listinfo/chromium-users
>
>

David Jones wrote:
> Has anyone used the ATI Radeon 8500 w/ Chromium under Linux. We were just
> trying out a perf test using Myrinet, but the Render spu(s) die very badly
> as you can see from the output below.
>
> This is using the latest cvs of chromium. It was built originally w/
> gm libs, but I was using tcpip for testing. I get this error even when
> using crdemo.conf on a local machine w/ tilesort. Stuff works fine w/ the
> pack spu, however.
>
> Any ideas?
...
> Floating exception (core dumped)
Where's the core say it's failing?
-Sean
__
seanahern@...