[Bf-committers] OpenGL Profiles Project?

Mathew Burrack mburrack at yahoo.com
Wed Oct 6 17:15:35 CEST 2010 

The irony is that, at least IMHO, the specific example you gave actually supported my idea of *not* having user intervention.

Specifically, you're putting the burden on the user to determine whether their graphics card supports GL_POINTS correctly or not. End users don't want to bother with that; they just want to get modeling!

> You can try to get this all sorted out by smart guessing,
> but in the  
> end it pays off to have the user make a decision what's
> acceptable, or  
> where other methods are preferred.

Except that we're not talking really about what's "preferred", but rather what actually *works*. A user is not going to *want* to pick to use GL_POINTS if it doesn't work on their card, and if it *does* work, they won't really care if they use it or not (and they probably will want to if it improves performance, but in that case, they don't care "hey, I want to use my card's GL_POINTS support", they only care about "hey, I want it to run faster").

And yes, the initial exceptions list would basically be populated by the hacks/workarounds in the existing code. That gives you the same functionality we have now, so the "guess" is no worse than what we had before. 

Now, ideally, we should expose the "profiles" support in Python, and if someone wants to write an (optional) extension to expose a UI for the profiles, they're free to do so. But the average user, even if they *do* know about such things, I don't think would *want* to deal with it all.


What I envision is something like this: a global struct that stores the OpenGL "profile". Most would be bitfields or booleans, like I suggested before (the only reason to put it into a struct would be for future expansion, in case a tweak requires something more than a simple boolean flag--say, a max bitdepth for the depth buffer, or a tweak for the fog equations, which is something I *always* found varied from GPU to GPU). The OGL backend code then changes from checking for extensions to checking the appropriate fields in the "profile" struct, which should be simple enough to start with (and the "tweaks" defined in said profile can be derived to start with from what existing extensions or hacks we check for). 

The profile should be initialized based on OGL capabilities/extensions on startup, then checked against the "exceptions" configuration file. The exceptions file could be a set of pattern matching for vendor/device/driver strings (not just flat-out strcmp, since there are tweaks that can apply to entire classes of GPUs), with each set listing the tweaks to make to the profile (force some flags on, force some off, clamp some values to a certain limit, etc.) Once the profile has been tweaked by any matching exceptions, we init the OGL subsystem.

The code could also store what exception set from the exceptions file matched the current profile. If/when the Python API is called to change a value in the profile, we automatically write out the updated exceptions to the exception file. That way, developers (and hard-core users) have a way of tweaking the exceptions file without manually editing it, and plus they can check the tweaks in real-time. If someone tweaks their particular setup to a "better" profile, all they have to do is submit the updated exceptions file as a patch, and we merge in the new set of exceptions (after any appropriate testing, of course).

* Note: it'd be a really good idea to write out the updated exceptions *AFTER* we've applied them to the OGL subsystem. That way, if the tweak causes a crash, the bad tweak won't be written out.


Again, this is all IMHO, but it seems to me that the previous idea was placing most of the burden on GPU capabilities testing on the user, and not only that but *each* user, instead of users being able to benefit from other user's discoveries and updated exceptions. The only practical result you'll get from that kind of system is a bunch of angry, frustrated users.

--mcn

> 
> On 5 Oct, 2010, at 20:28, Mathew Burrack wrote:
> 
> > I actually had to write similar code back in the day
> for realMYST/ 
> > URU for handling the peculiarities of various graphics
> cards (and  
> > back then, there were a TON more of them!). Having the
> user select a  
> > profile still doesn't make sense; instead, all it
> really takes is a  
> > bitfield of what capabilities you want to run with,
> which the OGL  
> > code checks (are GL_POINTS supported? If that bit is
> set, go that  
> > path, else go the fallback path, etc).
> >
> > In an ideal world, all you have to do is populate that
> bitfield with  
> > what you can detect from GL_EXTENSIONS, etc.
> Obviously, though, that  
> > never really works. So instead, you have a list of
> "exceptions",  
> > keyed off of the reported device name, vendor name,
> and driver  
> > version, that says "force this bit off" or "force this
> bit on". The  
> > startup code populates the bitfield based on what it
> detects, then  
> > checks the list of exceptions for bits to "fix" based
> on the card  
> > detected.
> >
> > That way, the user never has to select anything, and
> the code  
> > automatically does what it's supposed to, and
> enabling/disabling  
> > certain functionality based on a graphics card
> misbehaving is a  
> > simple matter of adding a line or two to the exception
> file (which  
> > can easily be tweaked based on bug reports from
> various users based  
> > on their gfx card; what's more, testing the fix with
> that user is  
> > dead simple, since all you have to do is send them a
> new exceptions  
> > list).
> >
> > ...worked on realMYST/URU just fine, at least :)
> >
> > -Mathew
> >
> > --- On Tue, 10/5/10, Tom M <letterrip at gmail.com>
> wrote:
> >
> >> From: Tom M <letterrip at gmail.com>
> >> Subject: Re: [Bf-committers] OpenGL Profiles
> Project?
> >> To: "bf-blender developers" <bf-committers at blender.org>
> >> Date: Tuesday, October 5, 2010, 11:00 AM
> >> It might be worth looking at how Ogre
> >> and possibly CrystalSpace handle this.
> >>
> >> LetterRip
> >>
> >> On Tue, Oct 5, 2010 at 9:29 AM, Ton Roosendaal
> <ton at blender.org>
> >> wrote:
> >>> Hi,
> >>>
> >>> The sad truth is that the implementation of
> Opengl,
> >> driver versions,
> >>> bugs in drivers, all make Opengl not work as
> smooth as
> >> it could be.
> >>>
> >>> The idea of a Profile is that you can setup
> per-system
> >> settings that
> >>> match the used hardware. These could be topics
> like:
> >>> - FSA
> >>> - Buffer swap methods
> >>> - Bitmap support
> >>> - mipmap settomgs
> >>> - GLSL support levels
> >>> - VBO (I guess)
> >>> - dual graphics cards (?)
> >>> - multi monitor setups, or stereo
> >>> - ....
> >>>
> >>> This should not to be automatically checked
> on,
> >> because most cards
> >>> support it more or less. The profile is to
> ensure you
> >> can get maximum
> >>> performance and best quality user experience.
> >>>
> >>> What is also possible it to extend our bgl
> calls
> >> (like
> >>> bglBegin(GL_POINTS)), which wraps specific
> problematic
> >> calls in Opengl
> >>> to match what we expect. The choosen profile
> can work
> >> that way without
> >>> polluting the code with checks, making it all
> local in
> >> a single C file
> >>> or so.
> >>>
> >>> If you check in our code, the places where
> opengl
> >> extension or vendor
> >>> strings are being checked is probably a good
> >> indication where we have
> >>> issues.
> >>>
> >>> Hope this info helps. Be warned it's not the
> best
> >> beginner code
> >>> project, good understanding of opengl on
> various
> >> systems, and on how
> >>> Blender uses opengl is required. And don't
> forget
> >> Mesa!
> >>>
> >>> Thanks,
> >>>
> >>> -Ton-
> >>>
> >>>
> >>
> ------------------------------------------------------------------------
> >>> Ton Roosendaal  Blender
> Foundation   ton at blender.org
> >>  www.blender.org
> >>> Blender Institute   Entrepotdok
> 57A  1018AD
> >> Amsterdam   The Netherlands
> >>>
> >>> On 5 Oct, 2010, at 8:50, Mathew Burrack
> wrote:
> >>>
> >>>> Not to butt in here, but what exactly is
> the point
> >> of the OpenGL
> >>>> profiles? To simplify setting up OpenGL
> display
> >> settings? What's
> >>>> wrong with auto-detecting what the card is
> capable
> >> of and just using
> >>>> that? Is the goal to avoid settings that
> are buggy
> >> on certain cards?
> >>>>
> >>>> It just seems to me like the end users
> would want
> >> it to Just Work
> >>>> and not care (or even necessarily know
> about) the
> >> difference between
> >>>> the profiles, and would just end up
> picking the
> >> first one that
> >>>> worked, not necessarily the best one.
> >>>>
> >>>> (Just trying to understand the goal here
> :)
> >>>>
> >>>> --mcn
> >>>>
> >>>>
> >>>> --- On Mon, 10/4/10, Knapp <magick.crow at gmail.com>
> >> wrote:
> >>>>
> >>>>> From: Knapp <magick.crow at gmail.com>
> >>>>> Subject: Re: [Bf-committers] OpenGL
> Profiles
> >> Project?
> >>>>> To: "bf-blender developers" <bf-committers at blender.org>
> >>>>> Date: Monday, October 4, 2010, 11:12
> PM
> >>>>> Might start by doing a hardware poll
> >>>>> among the users. Perhaps on the
> >>>>> Blender.org site and also a few of the
> other
> >> bigger blender
> >>>>> sites. I
> >>>>> would bet that you could find a much
> narrower
> >> design goal
> >>>>> that way.
> >>>>>
> >>>>> I will start out here. Nvidia Gforce
> 7600 GS.
> >> A nice card
> >>>>> for blender
> >>>>> but I am hoping to update soon.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> _______________________________________________
> >>>> Bf-committers mailing list
> >>>> Bf-committers at blender.org
> >>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >>>
> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

More information about the Bf-committers mailing list