View Full Version : How do you become an AMD Catalyst Beta Tester?
Laughing1
07-25-2009, 03:49 AM
I would like to know. :confused:
Ex-Cyber
07-25-2009, 04:24 AM
This was discussed in another thread. Basically, you become a beta tester by demonstrating that you would make a good one (quality reporting/assistance on http://ati.cchtml.com/ for example) and then expressing interest in becoming a beta tester.
Wouldn't it be more easy when there would be an official beta section directly on the ati/amd homepage?
nanonyme
07-25-2009, 10:15 AM
Wouldn't it be more easy when there would be an official beta section directly on the ati/amd homepage?http://ati.amd.com/products/catalyst/betatester.html Note that it implies signing an NDA.
bridgman
07-25-2009, 11:19 AM
I think that form is actually for the Windows beta program, hope to find out next week. The procedure is similar though...
Michael
07-25-2009, 11:27 AM
http://ati.amd.com/products/catalyst/betatester.html Note that it implies signing an NDA.
Linux version requires an NDA too.
Melcar
07-25-2009, 11:48 AM
The easiest way is to spend some time at the bug tracker. (http://ati.cchtml.com/)
Eventually someone from the program (or most likely a developer himself, since they are always reading the bug entries) will extend you an invitation.
A NDA for a simple 3d driver is a bit extreme. That are no programming docs that need to be secured. Just drivers to test. What's so bad if somebody would like to discuss issues in a public board? There are always issues with the drivers, a bit more more or less to discuss would really no big deal.
Qaridarium
07-26-2009, 07:46 AM
A NDA for a simple 3d driver is a bit extreme. That are no programming docs that need to be secured. Just drivers to test. What's so bad if somebody would like to discuss issues in a public board? There are always issues with the drivers, a bit more more or less to discuss would really no big deal.
thats a good point....
bridgman
07-26-2009, 01:17 PM
The NDA also allows us to communicate more about driver internals and future plans to the beta test group than we can to the public.
Then don't communicate and just put em on the website.
Qaridarium
07-26-2009, 02:05 PM
Then don't communicate and just put em on the website.
some Thinks are so easy....
PuckPoltergeist
07-26-2009, 02:43 PM
The NDA also allows us to communicate more about driver internals and future plans to the beta test group than we can to the public.
Can't it be split into public beta and closed beta? As Kano wrote, put the beta drivers onto the website (marked as beta) and the closed beta will remain as it is with additional NDA and communication about whatever needed.
How do you become an AMD Catalyst Beta Tester?
Install AMD Catalyst.
bridgman
07-26-2009, 03:39 PM
OK, let me try this one more time.
The "beta program" started off with "real" beta drops (functionally complete, all features working but might still have bugs) but over the years we started providing earlier access into development, to the point where todays "beta testers" basically have a pipe into our upstream development builds, often getting access to code 4-6 weeks before "beta".
You see or hear about new features in those early development builds, think they are "betas" because of the program name, and conclude that a "public beta" program would solve your problems, or at least those related to support for new kernels and X servers. When we don't give you public betas, you draw conclusions ranging from us being ignorant and incompetent to us being pawns of a certain large software company and committed to the destruction of Linux.
Your logic is sound, but you are basing the conclusion on bad assumptions. The key point here is that public betas would *not* get you the kind of early support you want, since what would qualify as a beta is usually only a couple of weeks ahead of the final release. What you would need is "public release of early development builds" which is something completely different.
Every additional release we create takes time away from other improvements in the driver. If you were really getting "early development build" features in the final beta releases then I agree that might be a good tradeoff, but that is simply not what would happen.
I really believe that calls for public betas right now are missing the point, for the simple reason that they would *not* give you the new functionality you are expecting. If you focus on the real issue -- earlier support for new kernels and X servers -- I think we have more options for helping.
cutterjohn
07-26-2009, 03:42 PM
I would like to know. :confused:install catalyst on linux...
Qaridarium
07-26-2009, 09:39 PM
OK, let me try this one more time.
The "beta program" started off with "real" beta drops (functionally complete, all features working but might still have bugs) but over the years we started providing earlier access into development, to the point where todays "beta testers" basically have a pipe into our upstream development builds, often getting access to code 4-6 weeks before "beta".
You see or hear about new features in those early development builds, think they are "betas" because of the program name, and conclude that a "public beta" program would solve your problems, or at least those related to support for new kernels and X servers. When we don't give you public betas, you draw conclusions ranging from us being ignorant and incompetent to us being pawns of a certain large software company and committed to the destruction of Linux.
Your logic is sound, but you are basing the conclusion on bad assumptions. The key point here is that public betas would *not* get you the kind of early support you want, since what would qualify as a beta is usually only a couple of weeks ahead of the final release. What you would need is "public release of early development builds" which is something completely different.
Every additional release we create takes time away from other improvements in the driver. If you were really getting "early development build" features in the final beta releases then I agree that might be a good tradeoff, but that is simply not what would happen.
I really believe that calls for public betas right now are missing the point, for the simple reason that they would *not* give you the new functionality you are expecting. If you focus on the real issue -- earlier support for new kernels and X servers -- I think we have more options for helping.
the real point is.... 9.8 is perfekt for the most people beta or not right now.....
wait for a mond to relase a perfekt driver right now?????
i can'T see any bug in this driver....
i play heroes on newerth BETA with it 20 times no crash no bug no problem..
i work i play i watch movies i surfing in the internet no bug...
thats not an beta thats God-like Jesus powered supernova driver...
and yes i know there are still bugs in it like slow flash movies with composit one...
but... ALL people needs to wait 1 mond for an super-giga-terra driver only becourse of some studit irrelevant nonsence nonimportand bugs???
and again this crap-litle-bugs the people life witout Kernel 2.6.30 support witout gread wine support.. witout all the powerfull improvments.. ? ?
install catalyst on linux...
Is there an echo in here?
monraaf
07-27-2009, 09:41 AM
the real point is.... 9.8 is perfekt for the most people beta or not right now.....
wait for a mond to relase a perfekt driver right now?????
i can'T see any bug in this driver....
i play heroes on newerth BETA with it 20 times no crash no bug no problem..
i work i play i watch movies i surfing in the internet no bug...
thats not an beta thats God-like Jesus powered supernova driver...
Dude, I can remember since 9.2 or 9.3 with each beta you telling how great the beta is and that this time AMD finally got it right. But when it was actually released it turned out to be not so great after all... Stop telling lies and raising peoples expectations, 9.8 is buggy and you know it.
Qaridarium
07-27-2009, 01:13 PM
Dude, I can remember since 9.2 or 9.3 with each beta you telling how great the beta is and that this time AMD finally got it right. But when it was actually released it turned out to be not so great after all... Stop telling lies and raising peoples expectations, 9.8 is buggy and you know it.
you don't respect the improfes of the driver?
the only Point of the beta driver is .. that the actual beta i better than catalyst 9-7
better means more stability more wine support better kernel support better composit support.
in the past i only was wrong in the timing.
some old betas has more features than the release after that becourse they want to improve the new features first and release it later.
best example is the UVD2 part of the driver,,
after the rework/rerelease the linux UVD2 part will be better than the windows one..
MartjeB
07-27-2009, 01:57 PM
Is there an echo in here?
Is there an echo here?
I just had to do it ;)
monraaf
07-27-2009, 03:45 PM
best example is the UVD2 part of the driver,,
after the rework/rerelease the linux UVD2 part will be better than the windows one..
What you are talking about? Are you saying that with the 9.8 driver you can actually use the UVD2 feature to get accelerated H264 decoding?
If not then what are you saying?
Is there an echo here?
I just had to do it ;)
Well, you screwed it up. Echoes don't drop random words.
energyman
07-28-2009, 06:30 AM
please calm down. What would you have gained, if 9.7 would have been 'open beta' 4 weeks before its release?
Probably nothing. The only difference: you would have known earlier that you still need to patch the driver. Nothing else.
And Qaridarium - where do you get all your informations? And why should we believe you, that the 'betas' are better in any aspect? Betas are always buggy - I am saying that as someone running a ~arch gentoo system, with gcc from a testing overlay, qt from svn, kde 4.3.60 svn... why should the AMD betas be magically different? The reason for running betas is to catch bugs. If there aren't any bugs, AMD would probably skip the beta stage and release the sweet error free version right away. But lo and behold, there are still bugs in the released drivers, which makes claims of perfect betas.. suspect.
cutterjohn
07-28-2009, 08:06 AM
Is there an echo in here?Yeah, I just opened the thread and read the first post, and the answer seemed to be obvious ;) :D :p
Melcar
07-28-2009, 10:49 AM
OK, let me try this one more time.
The "beta program" started off with "real" beta drops (functionally complete, all features working but might still have bugs) but over the years we started providing earlier access into development, to the point where todays "beta testers" basically have a pipe into our upstream development builds, often getting access to code 4-6 weeks before "beta".
You see or hear about new features in those early development builds, think they are "betas" because of the program name, and conclude that a "public beta" program would solve your problems, or at least those related to support for new kernels and X servers. When we don't give you public betas, you draw conclusions ranging from us being ignorant and incompetent to us being pawns of a certain large software company and committed to the destruction of Linux.
Your logic is sound, but you are basing the conclusion on bad assumptions. The key point here is that public betas would *not* get you the kind of early support you want, since what would qualify as a beta is usually only a couple of weeks ahead of the final release. What you would need is "public release of early development builds" which is something completely different.
Every additional release we create takes time away from other improvements in the driver. If you were really getting "early development build" features in the final beta releases then I agree that might be a good tradeoff, but that is simply not what would happen.
I really believe that calls for public betas right now are missing the point, for the simple reason that they would *not* give you the new functionality you are expecting. If you focus on the real issue -- earlier support for new kernels and X servers -- I think we have more options for helping.
Basically that's it. For the people expecting early support from the BETAs I'm sorry to say that you would be very disappointed. Those driver revision often have bugs, stuff that's broken, and even sometimes stuff that's missing.
bridgman
07-28-2009, 11:46 AM
One other point is that since the upstream builds have only gone through regular development-level regression testing we simply don't *know* how good or bad they are, so "just releasing the good ones" is not an option.
Qaridarium
07-28-2009, 01:43 PM
What you are talking about? Are you saying that with the 9.8 driver you can actually use the UVD2 feature to get accelerated H264 decoding?
If not then what are you saying?
no i don't saying this.
i say in the future there will be an libery and VLC/KAFFEINE whatever cann use this to accelerated Viedoes...
in windows only nonopensource software cann use this feature like POWERDVD or somsing else Comercial software with NDA and some other...
Qaridarium
07-28-2009, 01:53 PM
please calm down. What would you have gained, if 9.7 would have been 'open beta' 4 weeks before its release?
Probably nothing. The only difference: you would have known earlier that you still need to patch the driver. Nothing else.
And Qaridarium - where do you get all your informations? And why should we believe you, that the 'betas' are better in any aspect? Betas are always buggy - I am saying that as someone running a ~arch gentoo system, with gcc from a testing overlay, qt from svn, kde 4.3.60 svn... why should the AMD betas be magically different? The reason for running betas is to catch bugs. If there aren't any bugs, AMD would probably skip the beta stage and release the sweet error free version right away. But lo and behold, there are still bugs in the released drivers, which makes claims of perfect betas.. suspect.
"suspect" yes suspect for me see an working driver for ME!
but "suspect" for me over 2 years now be on the ati side of life most time stable fails completly for me!
i buy an 4350 and 8-9 do not work... 8.10 work.. 8-10 do not work.. 8-11 do not work 8-12 do not work.... 9-1 work bad... 9-2 work…..
then i Buy an 4670.. and again.. 9-2 do not work... 9-3 do not work.. 9-4 work... and so one!
this is very suspectet!
but on beta side.. 4350 the 8-11(do not work) come out the beta 9-1work...
and second exampel..with the 4670 9-2/9-3 (do not work) beta 9-4 work
very very suspect!!!!
" I am saying that as someone running a ~arch gentoo system, with gcc from a testing overlay, qt from svn, kde 4.3.60 svn... why should the AMD betas be magically different?"
i long time run debian SID... but yes i gif it up now i run ubuntu 9.04 and 9.10 Yes Arch linux is not an good idear for the catalyst...
but an 9.04 with kernel 2.6.30 and ati beta right now work much better than the orginal 9.04.-
Qaridarium
07-28-2009, 01:58 PM
One other point is that since the upstream builds have only gone through regular development-level regression testing we simply don't *know* how good or bad they are, so "just releasing the good ones" is not an option.
the comunity can test this very very fast for me i have 3 testing maschines!
if 1 driver are dirty.. i know it realy fast!
i only use the good ones..
i never stay on an bad driver...
downgrade or upgrade never never use bad drivers!
if there is an openbeta you cann get tons of fast testresults in no time!
deanjo
07-28-2009, 02:52 PM
in windows only nonopensource software cann use this feature like POWERDVD or somsing else Comercial software with NDA and some other...
Wrong MPC-HC supports the UVD2 decoder in windows just fine and is fully opensource.
http://mpc-hc.sourceforge.net/download-media-player-classic-hc.html
http://mpc-hc.sourceforge.net/DXVASupport.html
nanonyme
07-29-2009, 09:07 AM
Wrong MPC-HC supports the UVD2 decoder in windows just fine and is fully opensource.
http://mpc-hc.sourceforge.net/DXVASupport.htmlYeah, well, thanks to Microsoft, there really is only one video acceleration API on Windows, DXVA. You mostly only have to have your program support it and you should get video acceleration with all cards from all vendors. I guess the problem on Linux side was mostly missing someone to say "you do it this way, pronto" and everyone was free to make up their own solutions.
LavosPhoenix
08-03-2009, 02:27 PM
Why not have the beta support actually open to users, so they can use a driver with the latest kernel and maybe have working support for them without having to wait a month or more for that support?
energyman
08-03-2009, 03:40 PM
because than people would complain that the beta driver locks up their box or destroyed their data?
RealNC
08-03-2009, 04:49 PM
I fail to understand what's stopping anyone from ignoring complains about a driver that says "beta - it might destroy your data and lock up".
energyman
08-03-2009, 06:22 PM
because the people will complain loudly and other people will use it to attack amd? it is a loose loose situation. If you ignore them, you get more flak. If you try to cater to them, you don't need betas.
Is there a fglrx driver that does not lock up with latest kernels or some dual gfx configs?
Is there a fglrx driver that does not lock up with latest kernels or some dual gfx configs?
You should add that your dual gfx problem is a Hybrid Crossfire configuration and the notebook doesn't allow you to disable one of the chips. Crossfire is working fine as far as I know.
Well it has to work with it, that kind of config is not excluded in the fglrx readme.
Well it has to work with it, that kind of config is not excluded in the fglrx readme.
I agree but you should have added those pieces of information nevertheless.
legume
08-03-2009, 08:32 PM
no i don't saying this.
i say in the future there will be an libery and VLC/KAFFEINE whatever cann use this to accelerated Viedoes...
in windows only nonopensource software cann use this feature like POWERDVD or somsing else Comercial software with NDA and some other...
http://mpc-hc.sourceforge.net/
can use dxva to decode h.264 with uvd.
Edit: Oops I missed that this has already been mentioned.
RealNC
08-03-2009, 08:54 PM
because the people will complain loudly and other people will use it to attack amd? it is a loose loose situation. If you ignore them, you get more flak. If you try to cater to them, you don't need betas.
Yeah sure. The world is full with companies doing public betas out there (including AMD's major graphics competitor NVidia), but no, AMD is special. It's gonna bring them down.
lol.
bridgman
08-03-2009, 10:15 PM
How many of the companies doing public betss are also doing monthly releases ?
RealNC
08-03-2009, 10:22 PM
You're right. NVidia does weekly releases :D
@bridgman
Absolutely nobody needs defined monthly releases. You need new releases when there are bugs in old releases. If you update em daily, weekly, monthly or never is just the question of how annoying the included bugs are.
energyman
08-04-2009, 05:27 AM
Yeah sure. The world is full with companies doing public betas out there (including AMD's major graphics competitor NVidia), but no, AMD is special. It's gonna bring them down.
lol.
and nvidia sees a lot of complaining on nvnews.
Of course many ppl complain, but those who are happy don't use the board.
energyman
08-04-2009, 06:51 AM
and people who are happy with fglrx don't complain here
Well i support my own distro for years now, the complains about nvidia are minimal. Users need sometimes xorg.conf finetuning when the monitor does not report EDID correctly but thats all in most cases. But the problems you get with fglrx are absolutely annoying.
Qaridarium
08-04-2009, 07:24 AM
You're right. NVidia does weekly releases :D
LOOOOOOOOL realy funny....
cutterjohn
08-04-2009, 09:54 AM
I fail to understand what's stopping anyone from ignoring complains about a driver that says "beta - it might destroy your data and lock up".WTH?! The release drivers already do that!
I asked several times about dropping the monthly releases, but was told that it wouldn't really help anything.
Dunno how nvidia can support so many OSes as well as they do... while AMD just kind of waves at ever OS but Windows, and then plays the "but we released the specs" card...
energyman
08-04-2009, 11:00 AM
because for years people complained and told AMD/ATI 'release the specs and we will care about the rest'. They released the specs and people like you still complain.
...
cutterjohn
08-05-2009, 09:36 AM
because for years people complained and told AMD/ATI 'release the specs and we will care about the rest'. They released the specs and people like you still complain.
...That's because I could care less if they release the specs or not. I'm just inerested in actually functional drivers, like nVidia manages to supply on a regular basis for nearly a decade now.
energyman
08-05-2009, 05:02 PM
tell that to the poor sods on nvnews who are lucky enough to have non working setups.
'nearly a decade'.. yeah, I remember people being forced to flash their cards, because the card bios was incompatible with the nvidia drivers...
cutterjohn
08-09-2009, 07:24 AM
tell that to the poor sods on nvnews who are lucky enough to have non working setups.
'nearly a decade'.. yeah, I remember people being forced to flash their cards, because the card bios was incompatible with the nvidia drivers...Interesting, but it seems like they likely bought cards from a crappy OEM, as I've owned about 10 different nVidia based GPUs over the last 8 or 9 years and never had a problem. Although my last three were all from eVGA. (I've ALWAYS used the generic nVidia release drivers with those boards. Also have a 9800M GS nb which is just happy as pie to use the generic drivers... unlike my AMD GPU based nb... well even "using" those catalyst is more like a beta under linux anyways as there alreayd is data loss until you are aware of when the fault is likely to occur... even then if you're not CONSTANTLY attentive...)
The only problem that I've had with nVidia hardware was the onboard 1Gbps ethernet on the nForce4 chipsets which always seemed to eventually crap out, but I just ignored it and used a PCI 100Mbps ethernet card, as that's all my home network supports anyways.
energyman
08-09-2009, 07:36 AM
if asus&co are crappy oems - sure
cutterjohn
08-13-2009, 09:49 AM
Sometimes they are actually, but I've used worse than ASUS cards, i.e. budget type, and didn't have problems. It's likely that ASUS probably thought they knew more than they did and tinkered with the BIOS as well as playing with clocks while the cards that I've had probably pretty much used bog standard reference BIOS...
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.