-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (I corrected the CC address for the lsb-desktop list. It was incorrectly listed as being at lists.freedesktop.org, so none of this thread has made it to the list where the discussion should be.)
Allen Akin wrote: > On Thu, Sep 29, 2005 at 01:54:00PM -0400, Adam Jackson wrote: > | The deeper issue here is whether it's actually useful to require some > minimum > | level of functionality even when large swaths of it will be software. If I > | don't have cube map support in hardware, do I really want to try it in > | software? Is that a useful experience for developers or for users? > > For OpenGL at least, history suggests the answer is usually "yes." The > argument goes back to the pre-1.0 days, when texture mapping was only > available on fairly exotic hardware. The decision was made to require > it in the standard, and it turned out to be valuable on pure software > implementations because (1) it was fast enough to be usable for a > surprisingly large range of apps; (2) people with older hardware still > had the option to use it, rather than having that option closed off > up-front by the people defining the standard, and they found uses that > were worthwhile; (3) development could occur on older hardware for > deployment on newer hardware; (4) it served as a reference for hardware > implementations and a debugging tool for apps. > > This experience was repeated with a number of other features as OpenGL > evolved. > > If there's no consensus in the ARB about the desirability of a given > piece of functionality, it tends to be standardized as an extension (or > very rarely as a subset, like the Imaging Operations). Extensions are > optional, so they provide middle ground. But eventually, if a piece of > functionality proves valuable enough to achieve consensus, it moves into > the OpenGL core and software implementations become mandatory. This represents a goal of OpenGL to lead the hardware. The idea is that most current version of OpenGL defines the features that the next generation of hardware will have standard. In terms of making functionality available and leading developers, this is a really good strategy to take. However, that's not (or at least shouldn't be) our goal. Our goal is to define the minimum that is required to be available on our platform. As such, that should reflect what actually exists on our platform. From talking to people at the various distros, the most common piece of graphics hardware is the Intel i830 chipset (and derived chips like i845G, i855GM, etc.). That hardware is only capable of OpenGL 1.3. If all applications were well behaved (i.e., allowed users to enable or disable the use of individual hardware features like DOT3 texture environment or shadow maps), this wouldn't be a problem. That is sadly not the case. I think there is an alternative middle ground here that will satisfy most people's concerns. I propose that we require 1.2 as the minimum supported version. I also propose that we provide a standard mechanism to "demand" that the driver advertise a user specified version up to 1.5. For example, a user might run an app like: LIBGL_FORCE_VERSION=1.5 ./a.out When 'a.out' queries the version string, it will get 1.5 even if the driver has to do software fallbacks for the new 1.5 functionality. This will prevent the unexpected performance cliff I mentioned in another e-mail, and it will still provide more modern functionality to users that need / want it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDPEkjX1gOwKyEAw8RAtP4AJ9qf8IwVNDc+DCEek5Zfg5dPFuT6wCfQMdd wlSNVXShsZTgPAUzY4sicT8= =xRsC -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
