The AMD/ATI Bar & Grill

xmL · 2010-09-09 09:32:16

Hello,

I decided to give you a small description of autofglrx and its pros and cons.

DESCRIPTION:
Autofglrx runs at bootup and loads the module fglrx. If necessary, it will rebuild the module prior to loading it.

MECHANICS:
Autofglrx is a script that is invoked by the DAEMON array in rc.conf. It does not daemonize and thus is not running in the background. Basically it compares (exactly once per boot) the modification date of the module fglrx with either
* the kernel-package installation date
(or if not present)
* the .config file of the kernel.
Internally, it just uses the script catalyst_build_module to rebuild the module (if necessary). Thus catalyst_build_module and the hook-method can still be utilized.

PROS:
* Easy to set up
* No need for an entry in pacman.conf (SyncFirst is meant for an other purpose)
* Works out of the box for non-stock kernels
* No need for an initramdisk (e.g. nearly-full-static custom kernel)

CONS:
* Builds the module during boot process
* There are pathological cases where it might unnecessary rebuild the module
* It just works for custom kernels which obey the arch-naming-convention (or gentoo-way installed kernels)
* (Does not work, if fglrx is to be added into the initramdisk)

Now let me adress some other issues.

1. Autofglrx is not a daemon, like e.g. cpufreqd or gdm isn't - just like the hook-method is not a mkinitcpio-hook.

2. Autofglrx runs in about 50 ms on my machine (without rebuilding). Take speed considerations in this limit, you might want to check out the Gentoo Linux project instead. See the "Comparison of distributions" in the Arch Wiki project.

3. All needed variables are set. That's what the 3rd line is for.

In particular, there is nothing in or against favor of autofglrx compared to hook-method - choose for yourself what's best.

Greetings

xmL

Last edited by xmL (2010-09-12 08:11:20)

xmL · 2010-09-09 10:43:13

cyberpatrol wrote:

If fglrx is in the MODULES array in /etc/rc.conf, what is most likely the case for the most users, the old module for the old kernel gets loaded before the module is rebuilt, because the modules are loaded by /etc/rc.sysinit and the daemons are started by /etc/rc.multi which is started by init after /etc/rc.sysinit. So loading the module will fail and/or the module which is loaded at boot time won't work (correctly). So you definitely need to build the module before you reboot your system.

That's right. I suppose you add !fglrx to MODULES array and let autofglrx take the job of loading the module.

cyberpatrol wrote:

And think of cases in which someone needs to include the fglrx module into the initrd. In these cases you must rebuild the module with the hook method. Well, in these cases it could be necessary to run mkinitcpio twice. But that's a different issue.

That's also true. Autofglrx-method with fglrx in initram will fail. However it's pointless to put fglrx into initram when using the "nomodeset" kernel-flag. I will mention this point in the cons-list.

cyberpatrol wrote:

Like I said, a daemon is only for services which need to be accessible all the time, but not for single tasks which are only be accomplished every now and then.

This is a point everyone should consider, when choosing between hook- or autofglrx-method. (Remember autofglrx does not remain in memory.) However this argument does not make autofglrx sensless.
I think experienced users should use the hook-method while unexperienced should use autofglrx, because it does not change any config files (except rc.conf - which is quite natural). Also users without the need for initramdisks should consider autofglrx.

Last edited by xmL (2010-09-09 10:45:33)

Vi0L0 · 2010-09-09 14:16:31

cyberpatrol wrote:

Vi0L0 wrote:
That's why i'm asking for feedback.
And you asked me in a private e-mail what I think about it and asked me to comment.
So I did what you asked for.

I also ask you to look at the source .

cyberpatrol wrote:

Vi0L0 wrote:
If you won't test this daemon and you didn't even looked at the source then why you are wasting my time since i wrote that i will provide both methods of auto re-compiling?
Why should I test it and look at the source code?

Because if you look at the daemon's source then in it's first lines you will see that it's using 'catalyst_build_module' - you should know how does 'catalyst_build_module' work, because you are the person who convinced me to it.
Besides - what's so bad in looking at the source? I like it.

cyberpatrol wrote:

Vi0L0 wrote:
What? Stable? xD Buuahahahaaaa, ok now tell it on the IRC, tell it to people from bugs.archlinux.org
You are seriously a lucker.
No, I'm not a lucker. And I know Flyspray. And you won't find a software which doesn't have any bugs. But that hasn't anything to do with stable or unstable. Most of the people who have probably unstable systems are the [testing] users or users with esoteric hardware.

Issues happens all the time, sometimes it's arch maintainers fault - but it's all fine - they are only humans, we all are only humans - we makes mistakes.
My last issue (noticed in this week) touched wireshark-1.4.0-1 (from [extra] repo) which didn't start at all, without giving any error. Good that maintainer fixed it quiet fast.

cyberpatrol wrote:

Vi0L0 wrote:
But why you should get any issue with daemon? You really know almost nothing about this daemon.
I know general principles of a daemon, I know Arch's initsystem - and not only Arch's -, I know when modules are loaded and daemons are started, and I know when environment variables are set. And all that together tells me, that the daemon method can't work. And if it works then you are lucky.

Using daemon to build module isn't new discovery at all.
Look at virtualbox - it's using daemon to build it's modules in all linux distributions. Ubuntu, Fedora and Mandriva are additionally using DKMS to track kernel changes.
And you should know virtualbox - because you told me that we should convince it's maintainer to add hook's functionality into it. And i did it - i tried (i even provide working solution) - but wonder (who was virtualbox_bin maintainer in the time when i was trying, and is maintaining virtualbox-ose repo and is one of the most important arch devs) told me that he don't see advantages of using hook over daemon.

cyberpatrol wrote:

Vi0L0 wrote:
Plus i'm sure that hook won't work when you will downgrade 2.6.35.4 -> 2.6.35.3 if kernel26-headers will be installed before kernel26 (it is happening when you are downgrading ie. from [testing] repo to [stable] repos, forcing kernel26-headers in pacman.conf is working only when you are updating)
I haven't tried downgrading the kernel from [testing] to [core], yet. But I'm pretty sure, that the hook will work in this case, too, because kernel26-headers are downgraded, too, in this case, and I'm pretty sure that kernel26-headers are downgraded first if it's in SyncFirst in /etc/pacman.conf. Otherwise it's time to either fixing the hook or to filing a bug report about pacman and SyncFirst.

No, it's not the time to fill bug report, and i guess there will be no such time ever.
Because SyncFirst should NOT force to install package at first when downgrading. Why? Because it could tottally brake pacman when downgrading pacman in this way, and it will be a serious issue.
It will brake pacman because pacman is related with others packages and if you will downgrade pacman before those packages and without downgrading those packages together with pacman - pacman will brake, and won't work at all.
I know it because I had this (well known) issue once when updating, if pacman will be forced to be installed at first by SyncFirst also when downgrading - it will happen far far more often.

The only right way to fix this issue is i guess pacman's hook, but it's hard to tell when we will see such functionality.

cyberpatrol wrote:

Vi0L0 wrote:
- the module will be built without errors, but after reboot you will see black screen of tty.
I guess that the module will either be built correctly or not at all.

No, in this particular case module will be built correctly but it won't work.
Logically:
we have kernel26 and kernel26-headers 2.6.35.4 installed, and we want to downgrade to 2.6.35.3:
- while downgrading kernel26 will be installed at first;
- now headers (placed in /usr/src/linux-2.6.35-ARCH) weren't downgraded to 2.6.35.3, but 2.6.35.4 headers are present, and they are placed in same directory for whole 2.6.35-ARCH line;
- so fglrx hook will use those 2.6.35.4 headers, and will build module correctly.

Overall: daemons that only build a modules are well known in linux's world, while mkinitcpio hook to build a module isn't. Hook got some issues with building module, which aren't present in daemon (or they aren't known yet). So using daemon is the righ way.

Last edited by Vi0L0 (2010-09-09 15:42:38)

Vi0L0 · 2010-09-09 15:40:08

subzero316 wrote:

Vi0L0 wrote:
subzero316 wrote:
Any one checked on Firefox H/W acceleration? http://hacks.mozilla.org/2010/09/hardware-acceleration/
Why do you think it would work? Afaik linux isn't supporting Direct2D.
Because I actually read the Blog.
They claim composting is done by OpenGL which uses GPU.
Also Try this,
http://demos.hacks.mozilla.org/openweb/HWACCEL/
EDIT: http://demos.hacks.mozilla.org/openweb/CSSMAKESUSICK/

ok, i tested it using firefox-nightly on catalyst 10.7, i did clean install and erased my old ~/.mozilla directory.

Demos performance is horrible.
But it looks like flash isn't flickering when v-sync is enabled .

flamelab · 2010-09-09 15:57:30

There is no GPU acceleration for FF in Linux right now unfortunatelly.

Cdh · 2010-09-09 17:19:03

flamelab wrote:

There is no GPU acceleration for FF in Linux right now unfortunatelly.

Operation    Linux    Windows XP    Windows Vista/7    Mac OS X
Content     XRender     None     Direct2D     Quartz1
Compositing     OpenGL     Direct 3D     Direct 3D     OpenGL

OpenGL compositing sounds like acceleration to me. People here need to specify what "gpu acceleration" means.

Vi0L0 · 2010-09-09 19:04:45

xmL wrote:

cyberpatrol wrote:
If fglrx is in the MODULES array in /etc/rc.conf, what is most likely the case for the most users, the old module for the old kernel gets loaded before the module is rebuilt, because the modules are loaded by /etc/rc.sysinit and the daemons are started by /etc/rc.multi which is started by init after /etc/rc.sysinit. So loading the module will fail and/or the module which is loaded at boot time won't work (correctly). So you definitely need to build the module before you reboot your system.
That's right. I suppose you add !fglrx to MODULES array and let autofglrx take the job of loading the module.

True, you can remove fglrx from MODULES when you are using autofglrx, but it's not really necessary.
Assume that fglrx module has been loaded by sysinit, and autofglrx daemon is checking does it need to rebuild fglrx module:
- if there's no need to rebuild - it will load (with modprobe) previously built fglrx module, which is the same module that was loaded by sysinit - so everything is ok, system is working fine;
- if it need to rebuild - it will remove older fglrx module loaded by sysinit (with rmmod), it will build new fglrx module and load it (with modprobe) - everything is ok, system is working fine.
And like i said - i tested it all already.

xmL wrote:

cyberpatrol wrote:
And think of cases in which someone needs to include the fglrx module into the initrd. In these cases you must rebuild the module with the hook method. Well, in these cases it could be necessary to run mkinitcpio twice. But that's a different issue.
That's also true. Autofglrx-method with fglrx in initram will fail. However it's pointless to put fglrx into initram when using the "nomodeset" kernel-flag. I will mention this point in the cons-list.

initrd users would probably have to run own mkinitcpio either way. So they actually don't need any type of auto-recompilation, they just need 'catalyst_build_module new_kernel_version'.

Last edited by Vi0L0 (2010-09-09 19:38:54)

subzero316 · 2010-09-10 04:38:08

Vi0L0 wrote:

ok, i tested it using firefox-nightly on catalyst 10.7, i did clean install and erased my old ~/.mozilla directory.
Demos performance is horrible.
But it looks like flash isn't flickering when v-sync is enabled .

Have a go at this too. http://jagriffin.wordpress.com/2010/08/ … grafx-bot/
It is an Add-on which Tests and sends report to Mozilla. I'll test it and when I get off work.

mDuo13 · 2010-09-10 04:42:25

Hey guys, sorry to say it but I'm outta here; I just installed my new GTX 460 and it sure works nicely. It's been fun, thanks Vi0L0 and everyone else for all the help you've provided. For those of you who've got the opportunity to hop to the other side of the pond: it really is better here (sorry ATI, I'd still use you on Windows!) and for those who're stuck with what you've got... best of luck.

flamelab · 2010-09-10 09:36:29

Cdh wrote:

flamelab wrote:
There is no GPU acceleration for FF in Linux right now unfortunatelly.
Operation    Linux    Windows XP    Windows Vista/7    Mac OS X
Content     XRender     None     Direct2D     Quartz1
Compositing     OpenGL     Direct 3D     Direct 3D     OpenGL
OpenGL compositing sounds like acceleration to me. People here need to specify what "gpu acceleration" means.

GPU acceleration within a browser is to accelerate all of it's components, like fonts, the new <canvas> etc, through the GPU.

Well, that will happen on Windows with FF 4.x and IE9. On IE8, the fonts are accelerated through Direct2D.

On Linux, we don't have such thing. The compositing is not used within the window but around and on the window. Within the window, we have only the Xorg rendering which uses the CPU.

We have an initial GPU acceleration within Chromium right now, but it is yet experimental.

On FF we could have GPU acceleration through OpenGL or Glitz, but Cairo is not yet ready.

For Chromium, read this link: https://sites.google.com/a/chromium.org … -in-chrome

Last edited by flamelab (2010-09-10 09:44:45)

Vi0L0 · 2010-09-10 17:57:09

Autofgrx Daemon - new, better, faster version

xmL and me just discovered new way of checking was kernel updated.
It base on uname -v (which is telling when kernel was built).

We are now adding `uname -v` information to the fglrx module itself while it's compilation (so it's storing information about kernel's built time) - look at install_module() function of catalyst_build_module script: adding such information is safe because it's added to module's description.
Then autofglrx daemon is comparing that information with `uname -v` of just booted kernel.
And if there is a difference - it's rebuilding fglrx module.

This new solution is more safe, code of autofglrx is much shorter and transparent, and autofglrx itself is more than 2x faster in checking process.
Now autofglrx is starting (and killing itself) in <20ms if there's no need to rebuild fglrx module.

So here are PKGBUILDs and other needed files to build new packages:
- catalyst 10.7
- catalyst 10.8
Feel free to test it.

Note: i didn't add hooks functionality into it, but i assure you i will when daemon will land in aur/repo.

There's only one "issue" with this new solution i noticed:
catalyst_build_module new_kernel_version
or
catalyst_build_module all
wont work as it should when using daemon (module will be built also after booting new/other kernel), it's happening because catalyst_build_module will take `uname -v` information of kernel that is running at the moment and put it into all fglrx modules.

But it's not real issue at all since you are wasting more time on typing 'catalyst_build_module all' and then compiling a module(s) than a daemon which is just compiling. Beside i don't see why you even should to use that commands when using daemon.

Note: this new solution won't hurt hook method at all.

mDuo13 wrote:

Hey guys, sorry to say it but I'm outta here; I just installed my new GTX 460 and it sure works nicely. It's been fun, thanks Vi0L0 and everyone else for all the help you've provided. For those of you who've got the opportunity to hop to the other side of the pond: it really is better here (sorry ATI, I'd still use you on Windows!) and for those who're stuck with what you've got... best of luck.

Good luck mate

Last edited by Vi0L0 (2010-09-10 18:40:11)

DarksideEE7 · 2010-09-10 22:32:58

So has anyone tried this package:

pyrit 0.3.0-3

http://aur.archlinux.org/packages.php?ID=29030

I really wanted to test the compute capabilities of my 4870X2, plus it would be nice to see if I can crack my own WPA2-PSK password.

Also anyone know of any other good openCL or ATI stream compatible programs? There is just so much untapped power in this 4870X2 when not gaming.....it's itching to be used!

xmL · 2010-09-11 06:52:07

You might want to check out boinc. I think the Folding@Home project has a beta-version, that can compute on ati cards. See:
http://folding.stanford.edu/English/FAQ-ATI. Maybe other projects support ati cards too.

cyberpatrol · 2010-09-11 21:19:39

xmL wrote:

PROS:
* Easy to set up
* No need for an entry in pacman.conf (which is not the arch way)
* Works out of the box for non-stock kernels
* No need for an initramdisk (e.g. nearly-full-static custom kernel)

Building/compiling a module or anything else at boot time is not the Arch way, too, and also not the Linux way, because booting a system is to get the system up and running and nothing else particularly not such a critical task of compiling and again particularly not a kernel module.

Editing pacman.conf is the arch way because that's why there is a pacman.conf and a SyncFirst variable.

xmL wrote:

CONS:
* Builds the module during boot process
* There are pathological cases where it might unnecessary rebuild the module
* It just works for custom kernels which obey the arch-naming-convention (or gentoo-way installed kernels)
* (Does not work, if fglrx is to be added into the initramdisk)
Now let me adress some other issues.
1. Autofglrx is not a daemon, like e.g. cpufreqd or gdm isn't - just like the hook-method is not a mkinitcpio-hook.
2. Autofglrx runs in about 50 ms on my machine (without rebuilding). Take speed considerations in this limit, you might want to check out the Gentoo Linux project instead. See the "Comparison of distributions" in the Arch Wiki project.
3. All needed variables are set. That's what the 3rd line is for.

There are other big CONS:
* Booting takes longer even if it's only 50 ms. This takes 50 ms, the next script/daemon takes 50 ms, the next again takes 55 ms, etc. Booting takes longer and longer. If the module needs to be built it takes any longer. And booting a system should be done as fast as possible neither 50 ms longer if it's not necessary.
* Such critical tasks like compiling anything particularly kernel modules should *not* be done at boot time because there are not every system variables and compiler options set. They are only set after login.
* If building the module fails you really can get serious issues which probably can't be fixed or at least only with a LiveCD. This is not the case with the hook method.
* Putting fglrx to MODULES is the way to get a module loaded and *not* !fglrx and loading the module in a DAEMONS script. This is redundant code.

xmL wrote:

In particular, there is nothing in or against favor of autofglrx compared to hook-method - choose for yourself what's best.

There is everything against autofglrx, because autofglrx does critical tasks at boot time which probably can't (easily) be fixed at this time and can lead to a unbootable system so that a login is not possible, so that it needs to be fixed from a LiveCD.

And autofglrx goes against almost every Linux and Arch policies and standards.

Last edited by cyberpatrol (2010-09-11 21:20:49)

cyberpatrol · 2010-09-11 22:18:24

Vi0L0 wrote:

I also ask you to look at the source .

And I explained you more than once why this is not necessary.

Btw., xmL confirmed that one of the two methods I could thought of was the right one. And I explained why this is not the recommended way for building anything.

Vi0L0 wrote:

Because if you look at the daemon's source then in it's first lines you will see that it's using 'catalyst_build_module' - you should know how does 'catalyst_build_module' work, because you are the person who convinced me to it.

And what? Yes, catalyst_build_module is a real good script. But that mustn't be run at boot time. That's the problem. The problem is not this script, the problem is, that it's run and the kernel module is built at boot time. I don't want to repeat myself again. I already explained why.

Vi0L0 wrote:

Besides - what's so bad in looking at the source? I like it.

In this case, just because I have other things to do and I already explained why this daemon method is not the recommended way. And these reasons are independent from the source code. And, like I said, xmL has confirmed that one of the two possible versions I mentioned without reading the code is the way how autofglrx works. So why should I read the source code?

Vi0L0 wrote:

Issues happens all the time, sometimes it's arch maintainers fault - but it's all fine - they are only humans, we all are only humans - we makes mistakes.
My last issue (noticed in this week) touched wireshark-1.4.0-1 (from [extra] repo) which didn't start at all, without giving any error. Good that maintainer fixed it quiet fast.

And what has wireshark, a tool which is installed and run at runtime and not at boottime, to do with building/compiling a kernel module at boottime? Nothing.

Vi0L0 wrote:

Using daemon to build module isn't new discovery at all.
Look at virtualbox - it's using daemon to build it's modules in all linux distributions. Ubuntu, Fedora and Mandriva are additionally using DKMS to track kernel changes.

But this "daemon" - in fact it's not a daemon but an init or rc script, these are different things, and autofglrx is also not a daemon but an init resp. rc script - is *not* run at boot time but to be executed manually *after* the system is rebooted and the user/root is logged in.

And the disadvantage over the hook method is, that it has to be invoked manually and that the modules are not built automatically after the kernel update, which is the case with the hooks.

So, please, don't mix up two different things.

Vi0L0 wrote:

And you should know virtualbox - because you told me that we should convince it's maintainer to add hook's functionality into it. And i did it - i tried (i even provide working solution) - but wonder (who was virtualbox_bin maintainer in the time when i was trying, and is maintaining virtualbox-ose repo and is one of the most important arch devs) told me that he don't see advantages of using hook over daemon.

There is an advantage: The module is rebuilt automatically after updating the kernel, which is not the case with the init script.
And the post install message of virtualbox_bin explicitly says, that the rc script /etc/rc.d/vboxdrv should be run *after* the next reboot with the new kernel. Btw., the only parameter with which /etc/rc.d/vboxdrv can be started is not start but setup. So this init script can't be run at boot time, because the scripts in the DAEMONS array are always started with the parameter start. That's also a big difference and I guess, that he did this explictly to avoid this script being added to the DAEMONS array and the kernel module being rebuilt at boot time.

But if you'd adopt this method to catalyst then you'd throw the advantages of the hook method - rebuilding the module automatically after the kernel update - over.

Vi0L0 wrote:

No, it's not the time to fill bug report, and i guess there will be no such time ever.
Because SyncFirst should NOT force to install package at first when downgrading. Why? Because it could tottally brake pacman when downgrading pacman in this way, and it will be a serious issue.
It will brake pacman because pacman is related with others packages and if you will downgrade pacman before those packages and without downgrading those packages together with pacman - pacman will brake, and won't work at all.
I know it because I had this (well known) issue once when updating, if pacman will be forced to be installed at first by SyncFirst also when downgrading - it will happen far far more often.
The only right way to fix this issue is i guess pacman's hook, but it's hard to tell when we will see such functionality.

Well, that's not a problem either, because, like I said, everybody who uses [testing] and everybody who downgrades from [testing] to [core] should know what he is doing. So everybody who is doing this should be able to fix the related issues manually. So you don't need to take care of them.

Vi0L0 wrote:

No, in this particular case module will be built correctly but it won't work.
Logically:
we have kernel26 and kernel26-headers 2.6.35.4 installed, and we want to downgrade to 2.6.35.3:
- while downgrading kernel26 will be installed at first;
- now headers (placed in /usr/src/linux-2.6.35-ARCH) weren't downgraded to 2.6.35.3, but 2.6.35.4 headers are present, and they are placed in same directory for whole 2.6.35-ARCH line;
- so fglrx hook will use those 2.6.35.4 headers, and will build module correctly.

Like I said, everybody who is using [testing] or is downgrading the kernel and the kernel headers should know what he is doing and should know that he needs to run catalyst_build_module manually after the downgrade. If in doubt, put a hint about this to the wiki.

Vi0L0 wrote:

Overall: daemons that only build a modules are well known in linux's world, while mkinitcpio hook to build a module isn't. Hook got some issues with building module, which aren't present in daemon (or they aren't known yet). So using daemon is the righ way.

I'm using Linux for many years now. I used several distros. But I *never once* saw an initscript which compiles a module at boot time.

One compromise would be that you adopt the virtualbox method to catalyst but really the way it is implemented in virtualbox. That is, the init script must not have a start parameter but only a setup parameter, so that it can't be executed at boot time by rc.multi or by running `/etc/rc.d/autofglrx start` (or however this script is then called) but must be invoked manually at the command line by running ´/etc/rc.d/autofglrx setup`. And this script shouldn't load the module, it should only build or remove it.

In this case you should add a reminder to the post install messages.

This method would probably be a bit cleaner as the hook method although not that user-friendly. If this is implemented this way you could remove the hook method from the package.

But a kernel module must not be built at boot time.

Last edited by cyberpatrol (2010-09-11 22:24:47)

cyberpatrol · 2010-09-11 22:23:02

Vi0L0 wrote:

It base on uname -v (which is telling when kernel was built).

Don't forget the people who have more than one kernel installed and need to rebuild this module before they reboot the kernels.
uname only respects the actually loaded kernel but not other kernels which are installed.

Vi0L0 · 2010-09-12 03:31:42

I just talked with some archlinux project members and they told me that autofglrx daemon isn't bad. Ofcourse there could be better solution, but they didn't mention any.

@cyberpatrol:
<sight> i thought that we already got this discussion behind us...
You are repeatting yourself, and i really dunno how can i make my posts simpler. But ok...

cyberpatrol wrote:

xmL wrote:
PROS:
* Easy to set up
* No need for an entry in pacman.conf (which is not the arch way)
* Works out of the box for non-stock kernels
* No need for an initramdisk (e.g. nearly-full-static custom kernel)
Building/compiling a module or anything else at boot time is not the Arch way, too, and also not the Linux way, because booting a system is to get the system up and running and nothing else particularly not such a critical task of compiling and again particularly not a kernel module.

cyberpatrol wrote:

Vi0L0 wrote:
Overall: daemons that only build a modules are well known in linux's world, while mkinitcpio hook to build a module isn't. Hook got some issues with building module, which aren't present in daemon (or they aren't known yet). So using daemon is the righ way.
I'm using Linux for many years now. I used several distros. But I *never once* saw an initscript which compiles a module at boot time.

Building/compiling a kernel module at boot time by a daemon is provided in virtualbox in many linux distributions. Look at virtualbox packages at virtualbox's download page, or virtualbox packages provided in repositories of ie. ubuntu or fedora.
(their vboxdrv daemon got start/stop/other options)

cyberpatrol wrote:

Vi0L0 wrote:
Using daemon to build module isn't new discovery at all.
Look at virtualbox - it's using daemon to build it's modules in all linux distributions. Ubuntu, Fedora and Mandriva are additionally using DKMS to track kernel changes.
But this "daemon" - in fact it's not a daemon but an init or rc script, these are different things, and autofglrx is also not a daemon but an init resp. rc script - is *not* run at boot time but to be executed manually *after* the system is rebooted and the user/root is logged in.

cyberpatrol wrote:

Vi0L0 wrote:
And you should know virtualbox - because you told me that we should convince it's maintainer to add hook's functionality into it. And i did it - i tried (i even provide working solution) - but wonder (who was virtualbox_bin maintainer in the time when i was trying, and is maintaining virtualbox-ose repo and is one of the most important arch devs) told me that he don't see advantages of using hook over daemon.
There is an advantage: The module is rebuilt automatically after updating the kernel, which is not the case with the init script.
And the post install message of virtualbox_bin explicitly says, that the rc script /etc/rc.d/vboxdrv should be run *after* the next reboot with the new kernel. Btw., the only parameter with which /etc/rc.d/vboxdrv can be started is not start but setup. So this init script can't be run at boot time, because the scripts in the DAEMONS array are always started with the parameter start. That's also a big difference and I guess, that he did this explictly to avoid this script being added to the DAEMONS array and the kernel module being rebuilt at boot time.

You are wrong - it is a daemon in other distributions.
You are just looking at crippled archlinux version which doesn't have start/stop funcionality.
arch's vboxdrv daemon cannot be useful daemon atm because it doesn't have 'check was kernel updated' function. Daemon without such function would rebuild module with every kernel's boot. So there was no sense of adding start/stop into this vboxdrv.

Our daemon has got 'check was kernel updated' function.

cyberpatrol wrote:

There are other big CONS:
* Booting takes longer even if it's only 50 ms. This takes 50 ms, the next script/daemon takes 50 ms, the next again takes 55 ms, etc. Booting takes longer and longer. If the module needs to be built it takes any longer. And booting a system should be done as fast as possible neither 50 ms longer if it's not necessary.

Actually autofglrx is taking only 20ms on my machine, and even if it's 50ms it's still very very good time, i've never seen so fast daemon before.

Ofcourse you are right - this solution isn't perfect, but hook also isn't because if hook fails (it happened to me many times) you need to type 'catalyst_build_module some_new_kernel_version' - and typing it is taking more time than running autofglrx daemon 300 times.

cyberpatrol wrote:

* Such critical tasks like compiling anything particularly kernel modules should *not* be done at boot time because there are not every system variables and compiler options set. They are only set after login.

Like i said all needed variables (provided by uname command) are seted before loging here. Please read my posts more carefully.

cyberpatrol wrote:

* If building the module fails you really can get serious issues which probably can't be fixed or at least only with a LiveCD. This is not the case with the hook method.

cyberpatrol wrote:

xmL wrote:
In particular, there is nothing in or against favor of autofglrx compared to hook-method - choose for yourself what's best.
There is everything against autofglrx, because autofglrx does critical tasks at boot time which probably can't (easily) be fixed at this time and can lead to a unbootable system so that a login is not possible, so that it needs to be fixed from a LiveCD.

If building fails (but it won't) you can't get any serious issue. Autoflgrx daemon will be killed, other daemons will start (ofcourse except X/DM), and you will see tty's login screen where you can fix it easilly by providing right kernel package or kernel headers (because it's all about headers) (optionally you can check is module building correctly with 'catalyst_build_module some_new_kernel_version') and reboot.

cyberpatrol wrote:

Vi0L0 wrote:
Issues happens all the time, sometimes it's arch maintainers fault - but it's all fine - they are only humans, we all are only humans - we makes mistakes.
My last issue (noticed in this week) touched wireshark-1.4.0-1 (from [extra] repo) which didn't start at all, without giving any error. Good that maintainer fixed it quiet fast.
And what has wireshark, a tool which is installed and run at runtime and not at boottime, to do with building/compiling a kernel module at boottime? Nothing.

(we were talking about general stability and issues, and you quoted my words out of context)

That was just a sample and last seen (by me) issue. It could (and is) touching also other sofware like kernel itself (look how many people had problems with booting after update on bugs.archlinux).
And i won't call stable a system which is loosing it's funcionality just because of update.

cyberpatrol wrote:

Vi0L0 wrote:
No, it's not the time to fill bug report, and i guess there will be no such time ever.
Because SyncFirst should NOT force to install package at first when downgrading. Why? Because it could tottally brake pacman when downgrading pacman in this way, and it will be a serious issue.
It will brake pacman because pacman is related with others packages and if you will downgrade pacman before those packages and without downgrading those packages together with pacman - pacman will brake, and won't work at all.
I know it because I had this (well known) issue once when updating, if pacman will be forced to be installed at first by SyncFirst also when downgrading - it will happen far far more often.
The only right way to fix this issue is i guess pacman's hook, but it's hard to tell when we will see such functionality.
Well, that's not a problem either, because, like I said, everybody who uses [testing] and everybody who downgrades from [testing] to [core] should know what he is doing. So everybody who is doing this should be able to fix the related issues manually. So you don't need to take care of them.

Actually it's not only problem with downgrading, it could also happen with normall (without switching repos) updating. And happened, i remember it well because i catch serious issue : pacman was totally broken - pacman was updated at first and it wasn't working at all with older packages. The solution was to type 'pacman -Sy && pacman -Suu' instead of normall 'pacman -Syu' to avoid pacman's package update in first place.

It's not easy to note that hook actually built module for other kernel-headers when it's not refusing any error, but instead it's telling that everything went fine.

cyberpatrol wrote:

One compromise would be that you adopt the virtualbox method to catalyst but really the way it is implemented in virtualbox. That is, the init script must not have a start parameter but only a setup parameter, so that it can't be executed at boot time by rc.multi or by running `/etc/rc.d/autofglrx start` (or however this script is then called) but must be invoked manually at the command line by running ´/etc/rc.d/autofglrx setup`. And this script shouldn't load the module, it should only build or remove it.
In this case you should add a reminder to the post install messages.
This method would probably be a bit cleaner as the hook method although not that user-friendly. If this is implemented this way you could remove the hook method from the package.

What?! That would be totally insane!
If i implement vboxdrv daemon functionality (like no start) to autofglrx daemon then you will be catching tty's login screen with every main (and sometimes not-main) kernel's update! Simply because if you will run vboxdrv daemon after kernel's update (and before reboot) - then vboxdrv will build module for kernel that's running at the moment of running vboxdrv (or even will not build module if kernel catched main update - because haders for `uname -r` kernel won't exist).
It definitelly will NOT build working module for just updated kernel.

cyberpatrol wrote:

Vi0L0 wrote:
It base on uname -v (which is telling when kernel was built).
Don't forget the people who have more than one kernel installed and need to rebuild this module before they reboot the kernels.
uname only respects the actually loaded kernel but not other kernels which are installed.

So what?!
Daemon is starting after kernel's boot and it's taking `uname -v` of just booted kernel. Thats why it's working fine with many kernels.
It's really trivial to understand.

Also: why you are always thinking that anybody who is using autofglrx daemon need to rebuild flglrx module before reboot?
Like i clearly said - daemon won't work with 'catalyst_build_module some_new_kernel_version' nor 'catalyst_build_module all'....

Last edited by Vi0L0 (2010-09-12 06:08:28)

cyberpatrol · 2010-09-12 07:43:16

@Vi0L0: You really don't want to understand me, do you?

I haven't seen such alleged init scripts or daemons for virtualbox in other distros. But if they really build the virtualbox module at boot time it's simply poorly implemented. That other distros do something the way they are doing it, doesn't automatically mean that it is good. And other distros don't have anything like the mkinitcpio hooks which actually is meant for rebuilding the initrd. And there are distros which don't even have a initrd. So you can't compare different distros with each other in this respect.

And I haven't seen, yet, one single init script that builds a module or anything else at boot time in many years.

Once again, building anything at boot time is just a no go.

Arch's init scripts, btw., have start-stop functionality, but they must be explicitly implemented in the scripts like in any other distro.

Like I said in the AUR comments for virtualbox_bin, don't compare catalyst with virtualbox as they are totally different.

I don't answer to the rest you've written, because I don't want to repeat myself again.

Either keep the hook, which is more user-friendly, or use the init script, which is slightly clearer but less user-friendly, but with only the parameters setup and probably remove and without a parameter start. And this init script must not load the module, it must only rebuilt and/or remove the module.

And you are mixing up two different terms: daemon and init script/rc script (init script and rc script are the same)

A daemon is a software (binary) which is started, stays permanently in RAM and provides a service like web servers, e-mail servers, cups, etc.
An init script or rc script is a script (text file) that is started by the init process at boot time. Init scripts are usually meant for setting up the system or starting, stopping and restarting daemons, but can theoretically do anything else. And because init scripts are usually meant for starting and stopping daemons the array in /etc/rc.conf in which these scripts are listed is called DAEMONS, but there are primarily only init scripts/rc scripts in it.

And regarding a possible implementation of the module rebuilding as a daemon I explained it already, too, why this is not a good thing. It's just because it would be a waste of system resources. So this would be a no go, too.

If you still don't understand me, please, ask me. But I think I already explained everything that can be explained.

Vi0L0 · 2010-09-12 13:40:34

@cyberpatrol:
I do understand you. You are right in some cases, and your posts here are useful.
I can see it's wasting system's resources (a little).
I can see it could be not so safe - that's why i asked for testing.

But i won't erase autofglrx so easily because it's working better than a hook for me and xmL. So i believe it can be useful also for others (because it is working and is working so fast).

I will keep hook mathod anyway because it's good enough and is working for some time.
I definitelly won't provide daemon without start option because - like i prooved at the bottom of my prev post - it's very stupid idea.

And yes - i know what are daemons and scripts. I was just using one (arch) naming convention to be more understandable.

Last edited by Vi0L0 (2010-09-12 13:54:30)

dcc24 · 2010-09-12 14:02:44

Wow, I've just read the entire autofglrx discussion. Just some points:

- I'm using 3 kernels; 2.6.34/35/36rc3.
- Switching the kernel's at grub prompt does NOT break fglrx. It simply rebuilds it for the current kernel and it only does this once.
- Arch devs said this method isn't bad.
- Adding 20ms (I've timed it with a little script) to your boot is OK!

Congrats to Vi0L0 for not getting frustrated by this pointless discussion, when the other party even refuses to look at the code or TEST the damn thing.

venky80 · 2010-09-12 15:11:47

I just have these questions for my r600 (ATI MOBILITY RADEON HD3670) and latest catalyst
--Is the 2D performance smooth?
--Is the 3D performance smooth?
--Would I get hardware acceleration for videos?
--would I get hardware acceleration for flash?

Is there a good howto for installing catalyst and removing it? Could that be added to the first post?

cyberpatrol · 2010-09-12 15:13:48

dcc24 wrote:

- Adding 20ms (I've timed it with a little script) to your boot is OK!

This is not good, because those 20ms are unnecessary most of the time the system is started, and because it takes much longer to booting the system if the kernel module needs to be updated.

And if your system already needs about 1,5 minutes to boot, because you have a fully encrypted TB harddisk, then you really don't want to wait any longer for an unnecessary script, not even 20 ms.

Vi0L0 · 2010-09-12 15:21:00

venky80 wrote:

Is there a good howto for installing catalyst and removing it? Could that be added to the first post?

You will find it all on ATi Catalyst Wiki page.

cyberpatrol · 2010-09-12 15:51:16

Vi0L0 wrote:

I do understand you. You are right in some cases, and your posts here are useful.
I can see it's wasting system's resources (a little).
I can see it could be not so safe - that's why i asked for testing.

It's wasting system resources not only a little.
It's not that's not only not so safe, it can break and the user's compile options aren't set at this time. So the user probably get's a less performant module. And it can really break your system resp. Xorg which can itself prohibit logging in, if it crashes. Compiling at boot time can work well if you are lucky, but only if you are lucky.

Once again: Boot time is not the time for compiling anything.

Vi0L0 wrote:

But i won't erase autofglrx so easily because it's working better than a hook for me and xmL. So i believe it can be useful also for others (because it is working and is working so fast).

It's for sure not faster than the hook, because building the module takes the same time regardless of how you invoke the rebuilding. And that's what you always forget. And I really doubt that the hook is working worse than the init script.

Vi0L0 wrote:

I will keep hook mathod anyway because it's good enough and is working for some time.
I definitelly won't provide daemon without start option because - like i prooved at the bottom of my prev post - it's very stupid idea.

This is definitely not a stupid idea, it's a very good idea to provide this init script without a start option. You proved nothing, yet.

Vi0L0 wrote:

And yes - i know what are daemons and scripts. I was just using one (arch) naming convention to be more understandable.

No, they are not more understandable, in fact mixing up the terms daemon and init script is ambiguous. And it's not a naming convention and also not an Arch naming convention. Only the array in Arch's /etc/rc.conf in which the init scripts which shall be executed at boot time are listed is called DAEMONS just because it needs a name and because an init script usually starts a daemon.

So, please, don't mix up both terms.

Some questions:
Q: How many times is a (desktop) system booted (every day)?
A: Probably many times.

Q: How many times is a kernel updated?
A: Once every couple of weeks or months.

Q: How many times needs an external kernel module being updated?
A: As often as a kernel is updated.

Q: How many times you need to "check" if the module needs to be updated?
A: As often as a kernel is updated.

Q: How many times is such a check done at boot time?
A: Every time the system is booted.

Q: How many times is such a check at boot time unnecessary?
A: Most of the time. Number of system starts - number of kernel updates = number of unnecessary checks

Q: What's faster? 20 ms or 0 ms?
A: 0 ms.

Q: How long does it take to rebuild this module?
A: I haven't timed it, yet, but far longer than 20 ms.

Q: When does an admin usually have more time to wait for a module being compiled? When he starts the system or when he takes time to update a kernel?
A: When he takes the time to update the kernel.

Q: What can an admin do during rebuilding the module at boot time and when the system is completely running?
A: When the system is running, everything he wants due to multitasking. At boot time, nothing due to not, yet, fully usable multitasking.
(And don't tell me anything about the @ in the DAEMONS array. Starting init scripts parallel and in background can also make problems and usually makes booting slower.)

Q: When is the full build environment with every compiler option set up? At boot time or after the login?
A: After the login.

Q; When is the system stable running? At boot time or after the login?
A: After the login.

Q: How many times do you install the kernel and kernel headers from [testing]? And how many times do you downgrade the kernel and the kernel headers from [testing] to [core]?
A: You need to give the answer yourself, but I doubt that this is so many times. And I doubt that you are not able to manually invoke catalyst_build_module after the kernel downgrade.

I could ask several other questions. You see there are only disadvantages of this init script.

And, yes, there are absolutely no issues with the hook, except for a possible kernel downgrade. See the last question.

Last edited by cyberpatrol (2010-09-12 15:52:17)

Cdh · 2010-09-12 16:12:52

venky80 wrote:

I just have these questions for my r600 (ATI MOBILITY RADEON HD3670) and latest catalyst
--Is the 2D performance smooth?

I have a HD 4670.
How do you define "smooth"? Resizing and dragging around opaque windows and scrolling should be good, what else is important for you?

venky80 wrote:

--Is the 3D performance smooth?

Actually with the newest catalyst in 10.8 which makes 3d not so smooth when vsync is enabled, but without vsync I had no issues so far.

venky80 wrote:

--Would I get hardware acceleration for videos?

No. Video acceleration is only available on Cards with UVD2 and this is built in only since 4xxx.

venky80 wrote:

--would I get hardware acceleration for flash?

Noone will get that because flash has no hardware acceleration. gnash has vaapi support, but your card doesn't.

venky80 wrote:

Is there a good howto for installing catalyst and removing it? Could that be added to the first post?

I believe everything is there:
http://wiki.archlinux.org/index.php/ATI … positories
Just add the repository, do pacman -S catalyst and put fglrx in your rc.conf MODULES. Then create a xorg.conf with aticonfig --initial and start X (after modprobing fglrx!).

Arch Linux

#2351 2010-09-09 09:32:16

Re: The AMD/ATI Bar & Grill

#2352 2010-09-09 10:43:13

Re: The AMD/ATI Bar & Grill

#2353 2010-09-09 14:16:31

Re: The AMD/ATI Bar & Grill

#2354 2010-09-09 15:40:08

Re: The AMD/ATI Bar & Grill

#2355 2010-09-09 15:57:30

Re: The AMD/ATI Bar & Grill

#2356 2010-09-09 17:19:03

Re: The AMD/ATI Bar & Grill

#2357 2010-09-09 19:04:45

Re: The AMD/ATI Bar & Grill

#2358 2010-09-10 04:38:08

Re: The AMD/ATI Bar & Grill

#2359 2010-09-10 04:42:25

Re: The AMD/ATI Bar & Grill

#2360 2010-09-10 09:36:29

Re: The AMD/ATI Bar & Grill

#2361 2010-09-10 17:57:09

Re: The AMD/ATI Bar & Grill

#2362 2010-09-10 22:32:58

Re: The AMD/ATI Bar & Grill

#2363 2010-09-11 06:52:07

Re: The AMD/ATI Bar & Grill

#2364 2010-09-11 21:19:39

Re: The AMD/ATI Bar & Grill

#2365 2010-09-11 22:18:24

Re: The AMD/ATI Bar & Grill

#2366 2010-09-11 22:23:02

Re: The AMD/ATI Bar & Grill

#2367 2010-09-12 03:31:42

Re: The AMD/ATI Bar & Grill

#2368 2010-09-12 07:43:16

Re: The AMD/ATI Bar & Grill

#2369 2010-09-12 13:40:34

Re: The AMD/ATI Bar & Grill

#2370 2010-09-12 14:02:44

Re: The AMD/ATI Bar & Grill

#2371 2010-09-12 15:11:47

Re: The AMD/ATI Bar & Grill

#2372 2010-09-12 15:13:48

Re: The AMD/ATI Bar & Grill

#2373 2010-09-12 15:21:00

Re: The AMD/ATI Bar & Grill

#2374 2010-09-12 15:51:16

Re: The AMD/ATI Bar & Grill

#2375 2010-09-12 16:12:52

Re: The AMD/ATI Bar & Grill

Board footer