My Intel onboard 82915G/GV/910GL Express Chipset Family Graphics Controller used to run glxgears at blinding speeds with FC4 and I didn't even have to install a driver for it on my eMachines T5026. It just worked great out of the box on FC4. Now with FC5 (in the absence of glxgears which apparently I can't get on FC5) my 3d graphics and screensavers run jerkily and seem sluggish. Firefox 1.5 rendering time is abysmal compared to Firefox 1.0.7 on FC4 on this same machine. It has a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
Stanton Finley http://stanton-finley.net/
Stanton Finley wrote:
My Intel onboard 82915G/GV/910GL Express Chipset Family Graphics Controller used to run glxgears at blinding speeds with FC4 and I didn't even have to install a driver for it on my eMachines T5026.
The driver comes with FC5 of course. Not sure why you think you need to install a driver elsewhere.
It just worked great out of the box on FC4. Now with FC5 (in the absence of glxgears which apparently I can't get on FC5)
Except that you are wrong, and glxgears is part of FC5.
my 3d graphics and screensavers run jerkily and seem sluggish. Firefox 1.5 rendering time is abysmal compared to Firefox 1.0.7 on FC4 on this same machine. It has a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
That's why it is a test release, to find bugs. Don't use test releases if you expect flawless OS operation and perfect performance.
Testers & Developers,
I think somewhere along the way netizens appear to think that Rawhide is stable ( or at least for public consumption). I'd think we need to discuss how we can provide more constructive information for developers and send a clear message to non-testers that Rawhide (a.k.a FC5 ) is not for general use.
I really don't have any suggestion has to how we can achieve the latter without offending people, but I'm sure someone will. As for the Former, I'm sure I've seen some documentation on how to write constructive e-mails on fedoraproject.org in relation to testing Rawhide and going about debugging.
Maybe there's some way of redirecting people to the testing documentation before posting ( or at least posting the right details with associated attachments and what not).
I hope this can inspire some constructive ideas to help us all.
Peter Tiggerdine.
On Mon, 2006-02-27 at 21:21 -0500, Mike A. Harris wrote:
Stanton Finley wrote:
My Intel onboard 82915G/GV/910GL Express Chipset Family Graphics Controller used to run glxgears at blinding speeds with FC4 and I didn't even have to install a driver for it on my eMachines T5026.
The driver comes with FC5 of course. Not sure why you think you need to install a driver elsewhere.
It just worked great out of the box on FC4. Now with FC5 (in the absence of glxgears which apparently I can't get on FC5)
Except that you are wrong, and glxgears is part of FC5.
my 3d graphics and screensavers run jerkily and seem sluggish. Firefox 1.5 rendering time is abysmal compared to Firefox 1.0.7 on FC4 on this same machine. It has a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
That's why it is a test release, to find bugs. Don't use test releases if you expect flawless OS operation and perfect performance.
-- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian.
You could tell them to
change enablerepo=0 on the devel repos and then change enablerepo=1 on the base repos and not use that box for 3 weeks.
and then say that there are a lot of gifted people working on the (shrinking) bug list.
or you could say
RTFD ;-) (the wink would probably smooth any ruffled feathers)
When my friends ask I tell them to specifically wait for livna to go to 5 or migrate to ogg like I did. I know this seems flippant, but I think there is an profound insight in that idea.
-- --------------------- |_|0|_| |_|_|0| |0|0|0|
On Tue, 2006-02-28 at 13:58 +1000, Peter Tiggerdine wrote:
Maybe there's some way of redirecting people to the testing documentation before posting ( or at least posting the right details with associated attachments and what not).
Mailman can be setup to send a certain email (I think) when someone joins the list, and can include documentation, a link, or whatever so at least they were warned when joining.
You can lead a horse to water, but you can't make them drink. Happens all the time and not much you can do about it.
On Tue, Feb 28, 2006 at 01:58:01PM +1000, Peter Tiggerdine wrote:
Testers & Developers, I think somewhere along the way netizens appear to think that Rawhide is stable ( or at least for public consumption). I'd think we need to discuss how we can provide more constructive information for developers and send a clear message to non-testers that Rawhide (a.k.a FC5 ) is not for general use.
A good point. How about renaming the repository? "Rawhide" does not convey anything about the stability or usefulness of the contents. Something like "Unstable" or "Testing" or "BleedingEdge" or "UseAtYourOwnRiskDammit" would at least convey something.
On 2/28/06, Charles Curley charlescurley@charlescurley.com wrote:
A good point. How about renaming the repository? "Rawhide" does not convey anything about the stability or usefulness of the contents. Something like "Unstable" or "Testing" or "BleedingEdge" or "UseAtYourOwnRiskDammit" would at least convey something.
1) rawhide is just a nickname at this point. the tree is named "development" in the mirrors and in the yum configuration files.
2) I very seriously doubt changing thre tree name will change the word-of-mouth behavior which drives people to imply that the test releases and the development tree updates are stable.
3)The necessary boiler plate to inform users of the development tree, exists in the fedora-devel.repo file as a lengthy comment, which no one will ever actually read.
4) The underlying problem is the average package quality in the development tree is too good leading up to a final release. This leads to inflated expectations from novice testers who walk into the ongoing testing process. They then write personal testimonials of the stability of the tree, based on their very narrow personal experience, which mislead other people into thinking the tree will be "stable" for other people regardless of details in terms of the configuration and hardware they tested, skewing the expectations of any potential tester.
5)The solution to the problem of inappropriately high-expectations on the development tree is obviously to delibrately poison the development tree on a more regular basis, instead of doing it just after a final release is out the door. The key to projecting an image of progress to the unwashed is low expectations.. not higher standards. The more broken the development tree feels on a daily basis, to a tester who isn't fully invested in the true nature of the development process and wants to continue to falsely believe that there is an attainable monotonicly increasing ideal of stability which can be applied to the development tree, the more astonishing a working final release will appear to them. I can scream that the development tree will eat your children and destroy not only your data but your neighbor's data until I'm blue in the face... but for people who don't want to hear the warning.. they will choose not to hear the warning... and the only way for them to learn is to actually have rawhide eat their data. So i say.. every week there should be a delibrate package update in the development tree which destroys data. Thrown into the package pool at random, with an appropriate changelog entry so those of us who read the daily rawhide reports will know exactly which package to exclude.
-jef"tough love"spaleta
/etc/yum.repos.d/fedora-devel.repo # These packages are untested and still under development. This # repository is used for updates to test releases, and for # development of new releases. # # This repository can see significant daily turn over and can see major # functionality changes which cause unexpected problems with other # development packages. Please use these packages if you want to work # with the Fedora developers by testing these new development packages. # # fedora-test-list@redhat.com is available as a discussion forum for # testing and troubleshooting for development packages in conjunction # with new test releases. # # fedora-devel-list@redhat.com is available as a discussion forum for # testing and troubleshooting for development packages in conjunction # with developing new releases. # # Reportable issues should be filed at bugzilla.redhat.com # Product: Fedora Core # Version: devel
Once upon a time, Charles Curley charlescurley@charlescurley.com said:
A good point. How about renaming the repository? "Rawhide" does not convey anything about the stability or usefulness of the contents. Something like "Unstable" or "Testing" or "BleedingEdge" or "UseAtYourOwnRiskDammit" would at least convey something.
It has been "development" since Fedora Core started. "Rawhide" is the nickname based on the old Red Hat Linux dev tree; I think the only reference is in the core/development/README file (which apparently nobody reads).
On 28.02.2006 15:52, Chris Adams wrote:
It has been "development" since Fedora Core started. "Rawhide" is the nickname based on the old Red Hat Linux dev tree; I think the only reference is in the core/development/README file (which apparently nobody reads).
nobody is reading the README because it is not displayed via HTTP
http://download.fedora.redhat.com/pub/fedora/linux/core/development/ at least i can not see it.
http://download.fedora.redhat.com/pub/fedora/linux/core/development/README
no problem with ftp, but i doubt that the none readers use ftp :-(
$ lftp ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/ Verzeichniswechsel OK, cwd=/pub/fedora/linux/core/development lftp download.fedora.redhat.com:/pub/fedora/linux/core/development> ls -rw-r--r-- 1 ftp ftp 3101 Nov 04 2003 README drwxrwsr-x 2 ftp ftp 184320 Feb 28 07:49 SRPMS drwxr-xr-x 9 ftp ftp 4096 Feb 28 07:49 i386 drwxrwsr-x 9 ftp ftp 4096 Feb 28 07:49 ia64 drwxrwsr-x 2 ftp ftp 4096 Feb 28 07:28 isos drwxrwsr-x 10 ftp ftp 4096 Feb 28 07:49 ppc drwxrwsr-x 8 ftp ftp 4096 Feb 28 07:49 ppc64 drwxrwsr-x 8 ftp ftp 4096 Feb 28 07:49 s390 drwxrwsr-x 8 ftp ftp 4096 Feb 28 07:49 s390x drwxrwsr-x 9 ftp ftp 4096 Feb 28 07:50 x86_64
and you can less it
lftp download.fedora.redhat.com:/pub/fedora/linux/core/development> less README
Rolling, Rolling, Rolling........
In an effort to improve communications with the development community, enable Linux users to test bleeding-edge technology, speed development, and improve the quality of future Fedora Core releases (as well as to end world hunger and eliminate human conflict), the Fedora Project will be releasing development versions of the Fedora Core Operating System on a regular basis.
Dubbed "Raw Hide", the releases will have version numbers independent of Fedora Core's version. Raw Hide 1.0 will appear on download.fedora.redhat.com.
How Raw Hide is a Team Effort
The success of Linux and its rapid adoption by an increasing number of users for mission-critical applications has resulted in a growing number of developers. In addition to helping new users discover Linux, this development community continues to bring new features, tools, and utilities to Linux. As the Linux development community continues to push the rapid evolution of Linux, infrequently released Linux distributions have a difficult --Mehr--
Charles Curley wrote:
On Tue, Feb 28, 2006 at 01:58:01PM +1000, Peter Tiggerdine wrote:
Testers & Developers, I think somewhere along the way netizens appear to think that Rawhide is stable ( or at least for public consumption). I'd think we need to discuss how we can provide more constructive information for developers and send a clear message to non-testers that Rawhide (a.k.a FC5 ) is not for general use.
A good point. How about renaming the repository? "Rawhide" does not convey anything about the stability or usefulness of the contents. Something like "Unstable" or "Testing" or "BleedingEdge" or "UseAtYourOwnRiskDammit" would at least convey something.
Technically, it was renamed 2 years ago to "Fedora Development", however since the developmental repository for Red Hat Linux was named "rawhide" for 8-10 years or so, the name rawhide has stuck in the minds of many developers, and users.
One observation I've made though that this is changing slowly, is that I haven't seen anyone file a bug report against rawhide in bugzilla for a long time. People are pretty much universally using "Fedora devel" or one of the test versions when they file.
"Fedora development" conveys "use at own risk, this is unstable" quite adequately IMHO. At least as adequately as any other software project out there which has a public development version. During installation a brief dialog pops up on screen to inform you it is a test version, and not the full released OS. You have to click "Install anyway" or similar to proceed.
How much more blatant does it need to be?
On 2/28/06, Mike A. Harris mharris@mharris.ca wrote:
How much more blatant does it need to be?
No official documentation uses the phrases "will eat your babies" So there's tons of headroom in the blatant metric left.
-jef
Mike A. Harris (mharris@mharris.ca) said:
my 3d graphics and screensavers run jerkily and seem sluggish. Firefox 1.5 rendering time is abysmal compared to Firefox 1.0.7 on FC4 on this same machine. It has a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
That's why it is a test release, to find bugs. Don't use test releases if you expect flawless OS operation and perfect performance.
However, if it's *significantly* less performance, it could certainly signify something that's wrong.
Bill
On Mon, Feb 27, 2006 at 10:59:54PM -0500, Bill Nottingham wrote:
Mike A. Harris (mharris@mharris.ca) said:
my 3d graphics and screensavers run jerkily and seem sluggish. Firefox 1.5 rendering time is abysmal compared to Firefox 1.0.7 on FC4 on this same machine. It has a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
That's why it is a test release, to find bugs. Don't use test releases if you expect flawless OS operation and perfect performance.
However, if it's *significantly* less performance, it could certainly signify something that's wrong.
Current kernels still have slab debugging on (Because we still have bugs that this is tripping up that need whacking). The increased overhead of this sucks up memory bandwidth, and I wouldn't be surprised if shared-memory video chipsets feel some pain.
Dave
Dave Jones wrote:
On Mon, Feb 27, 2006 at 10:59:54PM -0500, Bill Nottingham wrote:
Mike A. Harris (mharris@mharris.ca) said:
a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
That's why it is a test release, to find bugs. Don't use test releases if you expect flawless OS operation and perfect performance.
However, if it's *significantly* less performance, it could certainly signify something that's wrong.
Current kernels still have slab debugging on (Because we still have bugs that this is tripping up that need whacking). The increased overhead of this sucks up memory bandwidth, and I wouldn't be surprised if shared-memory video chipsets feel some pain.
With glxgears, I see the gears update about 15 times in 10 seconds, and the results are (AMD athlon 2600+, 512ram, nvidia fx5600)# glxgears 888 frames in 5.4 seconds = 165.811 FPS 798 frames in 5.0 seconds = 158.416 FPS 912 frames in 5.7 seconds = 161.284 FPS 798 frames in 5.0 seconds = 158.274 FPS 798 frames in 5.1 seconds = 155.004 FPS It's hard to tell if this is just a stobing effect ;-)
I think it was at least an order of magnitude higher in FC4 - from memory approximately 5000 f/s (but perhaps only with the nvidia (non-open) driver).
Bill: this would seem to fit the *significantly* term: is this what others see ? Dave: card is a separate memory (128MB) card: it seems that this may be expected until the debugging is disable ?
DaveT.
David Timms (dtimms@bigpond.net.au) said:
With glxgears, I see the gears update about 15 times in 10 seconds, and the results are (AMD athlon 2600+, 512ram, nvidia fx5600)# glxgears 888 frames in 5.4 seconds = 165.811 FPS 798 frames in 5.0 seconds = 158.416 FPS 912 frames in 5.7 seconds = 161.284 FPS 798 frames in 5.0 seconds = 158.274 FPS 798 frames in 5.1 seconds = 155.004 FPS It's hard to tell if this is just a stobing effect ;-)
I think it was at least an order of magnitude higher in FC4 - from memory approximately 5000 f/s (but perhaps only with the nvidia (non-open) driver).
Bill: this would seem to fit the *significantly* term: is this what others see ?
Actually, this wouldn't - the default nv driver doesn't support 3D acceleration - the nvidia (non-open) driver does. So it's comparing apples to oranges.
Bill
On 2/28/06, David Timms dtimms@bigpond.net.au wrote:
Dave Jones wrote:
On Mon, Feb 27, 2006 at 10:59:54PM -0500, Bill Nottingham wrote:
Mike A. Harris (mharris@mharris.ca) said:
a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
That's why it is a test release, to find bugs. Don't use test releases if you expect flawless OS operation and perfect performance.
However, if it's *significantly* less performance, it could certainly signify something that's wrong.
Current kernels still have slab debugging on (Because we still have bugs that this is tripping up that need whacking). The increased overhead of this sucks up memory bandwidth, and I wouldn't be surprised if shared-memory video chipsets feel some pain.
With glxgears, I see the gears update about 15 times in 10 seconds, and the results are (AMD athlon 2600+, 512ram, nvidia fx5600)# glxgears 888 frames in 5.4 seconds = 165.811 FPS 798 frames in 5.0 seconds = 158.416 FPS 912 frames in 5.7 seconds = 161.284 FPS 798 frames in 5.0 seconds = 158.274 FPS 798 frames in 5.1 seconds = 155.004 FPS It's hard to tell if this is just a stobing effect ;-)
I think it was at least an order of magnitude higher in FC4 - from memory approximately 5000 f/s (but perhaps only with the nvidia (non-open) driver).
Are you able to run glxgears with the nv (open-source) driver? It does not work for me (x86_64 PCI-e 6600 GT): $ glxgears X Error of failed request: GLXBadContext Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 22 Current serial number in output stream: 22
Same as Partha noted with an ATi card. Interesting that both of our systems are 64-bit. I also cannot get my GLUT programs to work. They give the same error, with the minor difference that the above 22s are both 29 with the GLUT programs.
Jonathan
Jonathan Berry wrote:
On 2/28/06, David Timms dtimms@bigpond.net.au wrote:
Dave Jones wrote:
On Mon, Feb 27, 2006 at 10:59:54PM -0500, Bill Nottingham wrote:
Mike A. Harris (mharris@mharris.ca) said:
a 3 GHz P4 processor for heaven's sake. It should run FC5 like the wind.
That's why it is a test release, to find bugs. Don't use test releases if you expect flawless OS operation and perfect performance.
However, if it's *significantly* less performance, it could certainly signify something that's wrong.
Current kernels still have slab debugging on (Because we still have bugs that this is tripping up that need whacking). The increased overhead of this sucks up memory bandwidth, and I wouldn't be surprised if shared-memory video chipsets feel some pain.
With glxgears, I see the gears update about 15 times in 10 seconds, and the results are (AMD athlon 2600+, 512ram, nvidia fx5600)# glxgears 888 frames in 5.4 seconds = 165.811 FPS 798 frames in 5.0 seconds = 158.416 FPS 912 frames in 5.7 seconds = 161.284 FPS 798 frames in 5.0 seconds = 158.274 FPS 798 frames in 5.1 seconds = 155.004 FPS It's hard to tell if this is just a stobing effect ;-)
I think it was at least an order of magnitude higher in FC4 - from memory approximately 5000 f/s (but perhaps only with the nvidia (non-open) driver).
Are you able to run glxgears with the nv (open-source) driver? It does not work for me (x86_64 PCI-e 6600 GT):
Yes, the above slow results are with nv (ie default installer chosen driver / config) - there is no error, however it appears that the gears are not being clearly updated on the screen; CPU use goes to 100% but I think that would be normal :) from /var/log/X log: (II) LoadModule: "nv" (II) Loading /usr/lib/xorg/modules/drivers/nv_drv.so (II) Module nv: vendor="X.Org Foundation" compiled for 7.0.0, module version = 1.0.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.8 ... (II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2, ... (--) Chipset GeForce FX 5600 found ... (II) NV(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits
DaveT
On 2/27/06, Dave Jones davej@redhat.com wrote:
Current kernels still have slab debugging on (Because we still have bugs that this is tripping up that need whacking). The increased overhead of this sucks up memory bandwidth, and I wouldn't be surprised if shared-memory video chipsets feel some pain.
Would it be enough to install and boot into the latest fc4 update kernel to make a rough attempt to isolate the affect of enabled kernel debugging from xorg driver issues? or has there been too much shift in the rawhide kernel from rev 1831 for that comparison to be useful at all?
-jef
On Wed, Mar 01, 2006 at 12:39:09PM -0500, Jeff Spaleta wrote:
On 2/27/06, Dave Jones davej@redhat.com wrote:
Current kernels still have slab debugging on (Because we still have bugs that this is tripping up that need whacking). The increased overhead of this sucks up memory bandwidth, and I wouldn't be surprised if shared-memory video chipsets feel some pain.
Would it be enough to install and boot into the latest fc4 update kernel to make a rough attempt to isolate the affect of enabled kernel debugging from xorg driver issues? or has there been too much shift in the rawhide kernel from rev 1831 for that comparison to be useful at all?
Not something I've tested personally, so I've not got a definitive answer. I'd put money on things like udev complaining about the kernel being not new enough. Other than that though, should be ok-ish. Maybe.
Dave
On 3/1/06, Dave Jones davej@redhat.com wrote:
Not something I've tested personally, so I've not got a definitive answer. I'd put money on things like udev complaining about the kernel being not new enough. Other than that though, should be ok-ish. Maybe.
I can garuntee you that udev doesn't complain, on a 32bit system at least. I ended up reverting back to the fc4 update kernel to test for some wierdness with my usb hub in recent rawhide kernels and to narrow down in which kernel rev the specific regression i was seeing started. You can find my specific regression report in the 'zilla.
-jef
Mike A. Harris wrote:
Stanton Finley wrote:
My Intel onboard 82915G/GV/910GL Express Chipset Family Graphics Controller used to run glxgears at blinding speeds with FC4 and I didn't even have to install a driver for it on my eMachines T5026.
The driver comes with FC5 of course. Not sure why you think you need to install a driver elsewhere.
It just worked great out of the box on FC4. Now with FC5 (in the absence of glxgears which apparently I can't get on FC5)
Except that you are wrong, and glxgears is part of FC5.
glx-utils by chance? I thought that the program was gone altogether myself.
yum install glx-utils
glxgears and glxinfo are now both present.
Jim
Jim Cornette wrote:
Mike A. Harris wrote:
Stanton Finley wrote:
My Intel onboard 82915G/GV/910GL Express Chipset Family Graphics Controller used to run glxgears at blinding speeds with FC4 and I didn't even have to install a driver for it on my eMachines T5026.
The driver comes with FC5 of course. Not sure why you think you need to install a driver elsewhere.
It just worked great out of the box on FC4. Now with FC5 (in the absence of glxgears which apparently I can't get on FC5)
Except that you are wrong, and glxgears is part of FC5.
glx-utils by chance? I thought that the program was gone altogether myself.
yum install glx-utils
glxgears and glxinfo are now both present.
Jim
except .... glxgears X Error of failed request: GLXBadContext Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 22 Current serial number in output stream: 22
uname -a : 2.6.15-1.1977_FC5 #1 SMP Thu Feb 23 14:55:24 EST 2006 x86_64 x86_64 x86_64 GNU/Linux Video: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) (not shared memory)
Mike A. Harris wrote:
Stanton Finley wrote:
It just worked great out of the box on FC4. Now with FC5 (in the absence of glxgears which apparently I can't get on FC5)
Except that you are wrong, and glxgears is part of FC5.
iff its installed: I had to manually install (I guess this is based on installer choices and hence why some people dont have it installed ?). # rpm -qf /usr/bin/glxgears glx-utils-6.4.2-5
David Timms wrote:
Mike A. Harris wrote:
Stanton Finley wrote:
It just worked great out of the box on FC4. Now with FC5 (in the absence
of glxgears which apparently I can't get on FC5)
Except that you are wrong, and glxgears is part of FC5.
iff its installed: I had to manually install (I guess this is based on installer choices and hence why some people dont have it installed ?). # rpm -qf /usr/bin/glxgears glx-utils-6.4.2-5
If you think it should be installed by default, file a bug report against anaconda or comps.
Mike A. Harris wrote:
David Timms wrote:
Mike A. Harris wrote:
Except that you are wrong, and glxgears is part of FC5.
iff its installed: I had to manually install (I guess this is based on installer choices and hence why some people dont have it installed ?). # rpm -qf /usr/bin/glxgears glx-utils-6.4.2-5
If you think it should be installed by default, file a bug report against anaconda or comps.
Of general interest: perhaps not. But if there is some extremely cool, show off, kick ass, make you want to go and stick Fedora on a machine this second 3d gl demo (that isn't too big), that could be installed by default ;)
However, the size is tiny (16k+16k) for gears and info, so for a GUI install I reckon it should be included. It's at least a basic GL test tool which is proof of GL before trying some games / screen savers etc.
I'll file the request if there is any one else who would agree its needed ??
DaveT.
On Thu, 2006-03-02 at 00:13 +1100, David Timms wrote:
Mike A. Harris wrote:
David Timms wrote:
Mike A. Harris wrote:
Except that you are wrong, and glxgears is part of FC5.
iff its installed: I had to manually install (I guess this is based on installer choices and hence why some people dont have it installed ?). # rpm -qf /usr/bin/glxgears glx-utils-6.4.2-5
If you think it should be installed by default, file a bug report against anaconda or comps.
Of general interest: perhaps not. But if there is some extremely cool, show off, kick ass, make you want to go and stick Fedora on a machine this second 3d gl demo (that isn't too big), that could be installed by default ;)
Go and write one! please! I've wanted one for ages... then get in Extras, then we can get it in Core... If one already exists, suggestions/links would be welcome.
However, the size is tiny (16k+16k) for gears and info, so for a GUI install I reckon it should be included. It's at least a basic GL test tool which is proof of GL before trying some games / screen savers etc.
I'll file the request if there is any one else who would agree its needed ??
IMHO glxgears is actually something of a poor benchmark, as it's measuring how fast a certain specific set of operations work, and IIRC those operations don't reflect the way a typical 3D game would be implemented, or other ops you'd want e.g. for desktop bling. Is it wrong to optimize a benchmark so that it runs faster? ...and would it be wrong to optimize the drivers so that they detect glxgears and special-case it :-)
But for now if it's the best we've got, I'd suggest filing the request, (with those caveats), perhaps even to refactor it into its own package? Maybe something for the FC6 timeframe
Dave
David Malcolm wrote:
However, the size is tiny (16k+16k) for gears and info, so for a GUI install I reckon it should be included. It's at least a basic GL test tool which is proof of GL before trying some games / screen savers etc.
I'll file the request if there is any one else who would agree its needed ??
IMHO glxgears is actually something of a poor benchmark, as it's measuring how fast a certain specific set of operations work, and IIRC
People will use anything as a benchmark, just as they use bogomips, MIPS and hdparm. Generally, they're no more than a general indication of performance, but valuable nonetheless. Better numbers usually mean better performance, good to highlight problems, not enough to choose the ultimate winner.
If bad numbers from glxgears mean poor performance, then it fits the same mould.
David Timms wrote:
Mike A. Harris wrote:
David Timms wrote:
Mike A. Harris wrote:
Except that you are wrong, and glxgears is part of FC5.
iff its installed: I had to manually install (I guess this is based on installer choices and hence why some people dont have it installed ?). # rpm -qf /usr/bin/glxgears glx-utils-6.4.2-5
If you think it should be installed by default, file a bug report against anaconda or comps.
Of general interest: perhaps not. But if there is some extremely cool, show off, kick ass, make you want to go and stick Fedora on a machine this second 3d gl demo (that isn't too big), that could be installed by default ;)
However, the size is tiny (16k+16k) for gears and info, so for a GUI install I reckon it should be included. It's at least a basic GL test tool which is proof of GL before trying some games / screen savers etc.
I'll file the request if there is any one else who would agree its needed ??
I think it's reasonable for it to be installed by default. It always was before afterall. Many people look for it, enough to justify it being installed by default, such as any of the other X related "*info" tools.
It's probably not intentional that it's not installed by default right now, but more likely just nobody noticed before now and nobody reported it as a bug or request.
Not sure if it is too late now to change the list of things that get installed by default or not, but filing a bug would be the first step.
;)
Mike A. Harris wrote:
David Timms wrote:
Mike A. Harris wrote:
David Timms wrote:
However, the size is tiny (16k+16k) for gears and info, so for a GUI install I reckon it should be included. It's at least a basic GL test tool which is proof of GL before trying some games / screen savers etc.
I'll file the request if there is any one else who would agree its needed ??
I think it's reasonable for it to be installed by default. It always was before afterall. Many people look for it, enough to justify it being installed by default, such as any of the other X related "*info" tools.
It's probably not intentional that it's not installed by default right now, but more likely just nobody noticed before now and nobody reported it as a bug or request.
Not sure if it is too late now to change the list of things that get installed by default or not, but filing a bug would be the first step.
;)
zilla'd de bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183600 DaveT.
-
Bill Nottingham -
Charles Curley -
Chris Adams -
Dave Jones -
David Malcolm -
David Timms -
Jef Spaleta -
Jim Cornette -
John courie -
John Summerfield -
Jonathan Berry -
Mike A. Harris -
Mike Chambers -
Partha Bagchi -
Peter Tiggerdine -
shrek-m＠gmx.de -
Stanton Finley