Looking over the bug and error reports the past six months shows the majority of them coming from hardware and software configurations I do not and cannot not test (and probably would not want to run either). Would it make any difference to post a list of 'official' configurations which we develop and test?
Linux with Nvidia binary drivers Windows with ATI and Nvidia hardware and binary drivers OSX with ATI and Nvidia hardware
Maybe list a minimum GPU (Radeon 9000, Geforce 4, etc) and OS versions?
While we won't do anything to block GEM from running on other configurations this statement would spell out what we have the resources to target. Anything not on the list we cannot reasonably test and people should know that those might not run as expected and problems may not get fixed.
Or is this just officious?
Hallo, chris clepper hat gesagt: // chris clepper wrote:
Looking over the bug and error reports the past six months shows the majority of them coming from hardware and software configurations I do not and cannot not test (and probably would not want to run either). Would it make any difference to post a list of 'official' configurations which we develop and test?
Being responsible for some of these reports with my Matrox and Intel gfx hardware, I would of course be quite sad if direct support for these would be officially dropped (like the Ogre-people did it).
But apart from my personal view I would also like to mention that I encounter especially Intel hardware quite regularily in workshops I teach: Not everyone has a NVidia chip there, and Intel still is the largest gfx chip vendor by numbers. As we also teach with Linux live CDs: these cannot ship binary drivers so it requires an additional step (or many of them) to set everything up.
Dropping support for any driver that is not binary in my view would feel wrong for a GPL project IMO, although I can fully understand that the time of the Gem developers is limited and support simply may not be possible in real life.
I'm willing to help getting Gem work properly on the chips I own by testing (which I already do) and also other things that are in reach of my abilities. Just tell me what's needed.
Ciao
Frank Barknecht wrote:
Hallo, chris clepper hat gesagt: // chris clepper wrote:
Looking over the bug and error reports the past six months shows the majority of them coming from hardware and software configurations I do not and cannot not test (and probably would not want to run either). Would it make any difference to post a list of 'official' configurations which we develop and test?
Being responsible for some of these reports with my Matrox and Intel gfx hardware, I would of course be quite sad if direct support for these would be officially dropped (like the Ogre-people did it).
But apart from my personal view I would also like to mention that I encounter especially Intel hardware quite regularily in workshops I teach: Not everyone has a NVidia chip there, and Intel still is the largest gfx chip vendor by numbers. As we also teach with Linux live CDs: these cannot ship binary drivers so it requires an additional step (or many of them) to set everything up.
Dropping support for any driver that is not binary in my view would feel wrong for a GPL project IMO, although I can fully understand that the time of the Gem developers is limited and support simply may not be possible in real life.
i think both of you are right. and that there is no real contradiction between the both of you (even though probably both of you would disagree here...)
i think that it is only fair for the "end-user" to have an idea on which platforms (hard and soft) the developers work and on which configuration a certain release is known to work. this has nothing to do with "dropping support" for free drivers.
however, it hasa lot to do, with drivers claiming to support special features which in fact they don't support (most problems have been with rectangle-textures not working correctly).
ideally the list of "known good" hardware would hold intel hardware too.
I'm willing to help getting Gem work properly on the chips I own by testing (which I already do) and also other things that are in reach of my abilities. Just tell me what's needed.
the simplest thing would be to give me one of your intel gfx cards ;-)
i appreciate your offer and wil eventually come back to it...
mfg.asdr IOhannes
Ciao
On 1/10/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
i think that it is only fair for the "end-user" to have an idea on which platforms (hard and soft) the developers work and on which configuration a certain release is known to work. this has nothing to do with "dropping support" for free drivers.
This is exactly my point stating that the developers have limited resources and target certain configurations explicitly. While other setups may work we have no way to know that when testing code. As it is we cover a huge range of systems with minimal resources and I do not feel that we are too restrictive in our coverage.
On Jan 10, 2007, at 9:16 AM, chris clepper wrote:
On 1/10/07, IOhannes m zmoelnig zmoelnig@iem.at wrote: i think that it is only fair for the "end-user" to have an idea on which platforms (hard and soft) the developers work and on which configuration a certain release is known to work. this has nothing to do with "dropping support" for free drivers.
This is exactly my point stating that the developers have limited resources and target certain configurations explicitly. While other setups may work we have no way to know that when testing code. As it is we cover a huge range of systems with minimal resources and I do not feel that we are too restrictive in our coverage.
Is there a way that people can help with this? Or even some way to automate this? I can host machines online no problem, if that's helpful.
.hc
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
however, it hasa lot to do, with drivers claiming to support special features which in fact they don't support (most problems have been with rectangle-textures not working correctly).
ideally the list of "known good" hardware would hold intel hardware too.
One thing that comes to my mind in this regard would be a kind of easy to use test suite to find out where some cards fail or behave strangely. At best it would be automated, but even a collection of specific patches would be a good start.
I'm willing to help getting Gem work properly on the chips I own by testing (which I already do) and also other things that are in reach of my abilities. Just tell me what's needed.
the simplest thing would be to give me one of your intel gfx cards ;-)
Well, it's "hardcoded" into my laptop. But I can send you a Matrox G450, if you like? I'll order it directly on Ebay for 10 Euro. ;)
Ciao
-
chris clepper -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig