Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
On Wed, Jan 21, 2015 at 8:23 AM, brita britalme...@gmail.com wrote: Upgrading the minimum to 2.1 does not mean that Blender does not use higher OpenGL features. It can always query for the ogl version and use the available features, resulting, for example, in more performance. There is no need of a separate build. Should we strictly use extensions for anything newer? That would have almost the same effect as using a higher version while making it more clear what we support. The question is if versions older than 2.1 can be dropped in order for developers not having to loose their time coding fallback methods for (very!) older versions. Yes yes yes! Or not forget/neglect to code a fallback for something I *assume* is available on a random user's system. Check for 2.1+ at startup and so many assumptions are verified. The much smaller number of useful GL extensions is easier to remember to check. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
I want to give my opinion on this as well, since I also sometimes run absurdly old hardware. I am sometimes stuck on an old laptop, a Panasonic Toughbook CF-50 from ~2000. Pentium M 1.7 GHz single-core processor, upgraded to have 1 GB of ram, ATI 9600 GPU with a whopping 64 MB of vram. On that note, when I ran Windows, I had a terrible time running Blender for more than 10 minutes at a time and with any more than about 10k polys. It would eventually start blanking out regions of inactive UI until I manually reactivated and forced a redraw of the region, which would then get wiped out when I move to another region (ie 3d view from properties). I have a little more luck with Fedora 20 with XFCE, although it's still unusable for anything beyond simple modeling. I think it's pretty safe to say that 14-year-old hardware simply cannot keep up with realistic needs of a 3D artist, whether for production or for just playing around. I would say it's safe to upgrade to OGL 2.1+ and simply ignore anything older. I would really like to make the devs' lives much easier by abandoning such archaic bricks as this. On 01/21/2015 11:42 AM, Mike Erwin wrote: On Wed, Jan 21, 2015 at 8:23 AM, brita britalme...@gmail.com wrote: Upgrading the minimum to 2.1 does not mean that Blender does not use higher OpenGL features. It can always query for the ogl version and use the available features, resulting, for example, in more performance. There is no need of a separate build. Should we strictly use extensions for anything newer? That would have almost the same effect as using a higher version while making it more clear what we support. The question is if versions older than 2.1 can be dropped in order for developers not having to loose their time coding fallback methods for (very!) older versions. Yes yes yes! Or not forget/neglect to code a fallback for something I *assume* is available on a random user's system. Check for 2.1+ at startup and so many assumptions are verified. The much smaller number of useful GL extensions is easier to remember to check. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Upgrading the minimum to 2.1 does not mean that Blender does not use higher OpenGL features. It can always query for the ogl version and use the available features, resulting, for example, in more performance. There is no need of a separate build. The question is if versions older than 2.1 can be dropped in order for developers not having to loose their time coding fallback methods for (very!) older versions. Or.. if there is a valid reason for a considerable number of people to use 2.1, to need to keep using it, and not being able to upgrade, and to need the latest Blender. which seems far fetched Another question is if with this bump Blender can move out of the fixed function pipeline. Psy-fy ? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
rB6339ba1ee2b06174fa6 could make it in, but I personally don't really care. Greetings, - Julian - Hey, Here's the list of revisions so far. Only few nastier fixes to be backported, rest of them are rather nice to have. That's why mailing the list, to get feedback from the nice to have commit authors about inclusion into 2.73. = To be ported for sure = jens: c1f54bcdcca40ef74fac2fa269824f612b4ed8d8 Campbell: 0fcf9b26725863030023f4529acfd6fa2bec2969 cadcb12292c54cb7aeb2aaf91e7ea3bad87e9616 Sergey: 9e57babd8d946317feb5dbd7601ae01bb68d3130 7bb29c55287468dde964ac16c4b47ffad498e974 Bastien: cf178f71ac47453e635d5adc07b33a7539b9ac5e 2b226d95786fd5e8dd846ffbe990c3e1bb1fd35e Antony: e0cf86a9e219dcd71e5d67b8f2999d41e7f8c492 eb2e4577f4c763bf79a0a139d5c20c810b954185 = Questionable = Julien: 703bb0f62dbcd2a6ddebd1faae238790c0e19a46 ? 76b4fad6dbda1b10c8db1acec49c30386c9d9a94 ? 6339ba1ee2b06174fa6e5157999b59e4e093ff1f ? Sergey: 836ea4b70f8811144e4ccb0a15003c7ab7ef244e ? Campbell 2b595579e360108c309609f3734466d5641eef67 ? 01c04333f5226703178fa027e8ce0de02dff982b ? Antony: 3253ed9e26dd146d11f5bf9ff1a2dce3dbf744ec ? -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin -- Message: 4 Date: Tue, 30 Dec 2014 16:49:01 +0100 From: Antony Riakiotakis kal...@gmail.com Subject: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1 To: bf-blender developers bf-committers@blender.org Message-ID: caeszqutwieri9w7jn+sh-u6wqxcy_jjkqm+x5gpah0hphtd...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hello again, The times of fixed function OpenGL pipeline have been very fun and happy, with coders trying to ingeniously hack the fixed function parameters to do the things they wanted. But I believe we are getting to the point where fixed function OpenGL starts holding us back. We already require GLSL support for some of the fancier features of blender, but probably it's time to feel free to consider shaders as the primary display mechanism if we want to, without needing to code fallbacks to a fixed function alternative. Especially anything that requires mixing multiple textures (such as texture painting with masks or brush overlays) or attributes in a non standard way is difficult without shaders. This is scheduled to happen as part of the viewport refactor, but having the hardware requirements there will enable us to do more improvements now. The proposal is not about throw away every legacy path next release, rather than assuming that users will need to have access to newer hardware from now on if they wish to access core features. Shader availability can be tested to avoid crashes but no alternative rendering path should be provided for those not meeting the requirements. -- Message: 5 Date: Wed, 31 Dec 2014 04:39:37 -0500 From: Mike Erwin significant@gmail.com Subject: Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1 To: bf-blender developers bf-committers@blender.org Message-ID: cahf3-vc7ret3cto3eipacm0gkzzzuh-y0k-uqwyrjjzshad...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hear, hear! Setting OpenGL 2.1 as a foundation gives us a large feature set to work with, reducing our reliance on extensions that might or might not be available at run time. For example VBOs and GLSL 1.2 are *guaranteed* to be there so we won't need conditional checks or ARB suffixes for those functions/enums. When would be an appropriate time to require 2.1? As in refuse to run if less than this? I have a growing list of still-nice-to-have extensions that have not been adopted into core OpenGL as of 2.1. Half the list is on this machine and the rest on Windows -- I'll put together a full post on this topic soon. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire On Tue, Dec 30, 2014 at 10:49 AM, Antony Riakiotakis kal...@gmail.com wrote: Hello again, The times of fixed function OpenGL pipeline have been very fun and happy, with coders trying to ingeniously hack the fixed function parameters to do the things they wanted. But I believe we are getting to the point where fixed function OpenGL starts holding us back. We already require GLSL support for some of the fancier features of blender, but probably it's time to feel free to consider shaders
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
On Sun, Jan 18, 2015 at 11:16 AM, h...@jupama.org wrote: This topic leads me to two questions: - upgrade to OpenGL 2.1: the OpenGL is currently at version 4.5. Is it impossible to maintain the same version in blender? This would severely limit blender's audience. Only Windows Linux running proprietary vendor drivers on *new* graphics cards are able to run GL 4.5. The laptop I'm using right now says GL 4.4 even with the latest drivers! 2.1 has been around long enough that it is essentially universal. Yes we'll miss out on some nice capabilities. We have been using features from later versions of GL but not always in a consistent way. Part of the project is eye candy, part is improved performance, and just as important is setting a higher baseline and making the code consistent and safe. - and my endless quest of finding out the relation between OpenGL, GLSL, GHOST. Does GHOST uses the OpenGL libraries directly? or does it call GLSL. GHOST sets up OpenGL contexts in platform-specific ways. Other than that GHOST does not use GL or GLSL for its own purposes. Thanks for your time. Regards Hewi Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Better view-port performance, with wide compatibility is better IMHO then amazing performance no one can use, how hard would it be to have a High OpenGL build as a separate entity? 2.1 - for normal builds 4.4 - High end build would that be much harder to maintain? On Sun, Jan 18, 2015 at 11:28 AM, Mike Erwin significant@gmail.com wrote: On Sun, Jan 18, 2015 at 11:16 AM, h...@jupama.org wrote: This topic leads me to two questions: - upgrade to OpenGL 2.1: the OpenGL is currently at version 4.5. Is it impossible to maintain the same version in blender? This would severely limit blender's audience. Only Windows Linux running proprietary vendor drivers on *new* graphics cards are able to run GL 4.5. The laptop I'm using right now says GL 4.4 even with the latest drivers! 2.1 has been around long enough that it is essentially universal. Yes we'll miss out on some nice capabilities. We have been using features from later versions of GL but not always in a consistent way. Part of the project is eye candy, part is improved performance, and just as important is setting a higher baseline and making the code consistent and safe. - and my endless quest of finding out the relation between OpenGL, GLSL, GHOST. Does GHOST uses the OpenGL libraries directly? or does it call GLSL. GHOST sets up OpenGL contexts in platform-specific ways. Other than that GHOST does not use GL or GLSL for its own purposes. Thanks for your time. Regards Hewi Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Here's a snippet from what I'm working on, since checking for GL version
was brought up in meeting. I like the float version better, but here's both:
#if 0
*bool* versionAtLeast(*int* major, *int* minor)
{
*int* actual_major, actual_minor;
*const* *char** version_str = (*const* *char**)glGetString(GL_VERSION);
*if* (sscanf(version_str, %d.%d, actual_major, actual_minor) != 2)
*return* *false*;
printf(version %d.%d\n, actual_major, actual_minor);
*return* actual_major major || (actual_major == major actual_minor
= minor);
}
#else
*bool* versionAtLeast(*float* desired_version)
{
*float* actual_version;
*const* *char** version_str = (*const* *char**)glGetString(GL_VERSION);
*if* (sscanf(version_str, %f, actual_version) != 1)
*return* *false*;
printf(version %.1f\n, actual_version);
*return* actual_version = desired_version;
}
#endif
*void* showOpenGLInfo()
{
puts(--- OpenGL version ---);
// if (versionAtLeast(2,1))
*if* (versionAtLeast(2.1))
puts(GL version ok);
*else*
puts(GL version TOO LOW);
printf(GLSL %s\n, (*char**) glGetString(GL_SHADING_LANGUAGE_VERSION));
puts((*char**) glGetString(GL_VENDOR));
puts((*char**) glGetString(GL_RENDERER));
puts(--- OpenGL extensions ---);
*char** multiple = (*char**) glGetString(GL_EXTENSIONS);
*char** single;
*while* (single = strsep(multiple, ), strlen(single))
puts(single);
// query unchanging limits *once* at startup
GLint value;
glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, value);
printf(GL_MAX_ELEMENTS_VERTICES: %d\n, value);
glGetIntegerv(GL_MAX_ELEMENTS_INDICES, value);
printf(GL_MAX_ELEMENTS_INDICES: %d\n, value);
glGetIntegerv(GL_MAX_TEXTURE_SIZE, value);
printf(GL_MAX_TEXTURE_SIZE: %d\n, value);
// puts(--- renderer info ---);
// long info;
// CGLGetParameter( contextObj, kCGLCPGPUVertexProcessing, info );
// printf(vertex processing in %s\n, info ? GPU : software);
// CGLGetParameter( contextObj, kCGLCPGPUFragmentProcessing, info );
// printf(fragment processing in %s\n, info ? GPU : software);
}
In next release, before making 2.1 mandatory, we could check and do
*something* if the target system isn't up to snuff. Message in the info
header?. Pop up a message box?
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
On Wed, Dec 31, 2014 at 6:07 AM, John James kiso...@gmail.com wrote:
Is it possible to make an installation check of future requirements and
display a strong warning (that is not easily bypassed by just clicking
Next) that there is a plan to make them obsolete. This will enable users
to prepare beforehand and also give them possibility to object. If 50% are
still using the old features should they be faced with the fact No new
updates for You!? I am for the use of the latest features of the hardware
when they are present by the way :)
2014-12-31 11:55 GMT+02:00 Martijn Berger martijn.ber...@gmail.com:
Hi everyone,
This is a great idea and should be effected as soon as possible ( 2.74 ).
As in practice blender does not run really well on graphics hardware that
is more then 10 years old anyway.
We can save ourselves a lot of bug reports and headaches by just adding a
check for this and warning users when we find less then OpenGL 2.1.
I am all for trying to keep blender accessible to a as large as possible
group of users.
But I think it is safe to say that anyone should have access to OpenGL
2.1
capable hardware as this translates to 10-11 year old hardware.
On Tue, Dec 30, 2014 at 4:49 PM, Antony Riakiotakis kal...@gmail.com
wrote:
Hello again,
The times of fixed function OpenGL pipeline have been very fun and
happy, with coders trying to ingeniously hack the fixed function
parameters to do the things they wanted.
But I believe we are getting to the point where fixed function OpenGL
starts holding us back. We already require GLSL support for some of
the fancier features of blender, but probably it's time to feel free
to consider shaders as the primary display mechanism if we want to,
without needing to code fallbacks to a fixed function alternative.
Especially anything that requires mixing multiple textures (such as
texture painting with masks or brush overlays) or attributes in a non
standard way is difficult without shaders.
This is scheduled to happen as part of the viewport refactor, but
having the hardware requirements there will enable us to do more
improvements now.
The proposal is not about throw away every legacy path next release,
rather than assuming that users will need to have access to newer
hardware from now on if they wish to access core features. Shader
availability can be tested to avoid crashes but no alternative
rendering path should be provided for those not meeting the
requirements.
___
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Hear, hear! Setting OpenGL 2.1 as a foundation gives us a large feature set to work with, reducing our reliance on extensions that might or might not be available at run time. For example VBOs and GLSL 1.2 are *guaranteed* to be there so we won't need conditional checks or ARB suffixes for those functions/enums. When would be an appropriate time to require 2.1? As in refuse to run if less than this? I have a growing list of still-nice-to-have extensions that have not been adopted into core OpenGL as of 2.1. Half the list is on this machine and the rest on Windows -- I'll put together a full post on this topic soon. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire On Tue, Dec 30, 2014 at 10:49 AM, Antony Riakiotakis kal...@gmail.com wrote: Hello again, The times of fixed function OpenGL pipeline have been very fun and happy, with coders trying to ingeniously hack the fixed function parameters to do the things they wanted. But I believe we are getting to the point where fixed function OpenGL starts holding us back. We already require GLSL support for some of the fancier features of blender, but probably it's time to feel free to consider shaders as the primary display mechanism if we want to, without needing to code fallbacks to a fixed function alternative. Especially anything that requires mixing multiple textures (such as texture painting with masks or brush overlays) or attributes in a non standard way is difficult without shaders. This is scheduled to happen as part of the viewport refactor, but having the hardware requirements there will enable us to do more improvements now. The proposal is not about throw away every legacy path next release, rather than assuming that users will need to have access to newer hardware from now on if they wish to access core features. Shader availability can be tested to avoid crashes but no alternative rendering path should be provided for those not meeting the requirements. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Hi everyone, This is a great idea and should be effected as soon as possible ( 2.74 ). As in practice blender does not run really well on graphics hardware that is more then 10 years old anyway. We can save ourselves a lot of bug reports and headaches by just adding a check for this and warning users when we find less then OpenGL 2.1. I am all for trying to keep blender accessible to a as large as possible group of users. But I think it is safe to say that anyone should have access to OpenGL 2.1 capable hardware as this translates to 10-11 year old hardware. On Tue, Dec 30, 2014 at 4:49 PM, Antony Riakiotakis kal...@gmail.com wrote: Hello again, The times of fixed function OpenGL pipeline have been very fun and happy, with coders trying to ingeniously hack the fixed function parameters to do the things they wanted. But I believe we are getting to the point where fixed function OpenGL starts holding us back. We already require GLSL support for some of the fancier features of blender, but probably it's time to feel free to consider shaders as the primary display mechanism if we want to, without needing to code fallbacks to a fixed function alternative. Especially anything that requires mixing multiple textures (such as texture painting with masks or brush overlays) or attributes in a non standard way is difficult without shaders. This is scheduled to happen as part of the viewport refactor, but having the hardware requirements there will enable us to do more improvements now. The proposal is not about throw away every legacy path next release, rather than assuming that users will need to have access to newer hardware from now on if they wish to access core features. Shader availability can be tested to avoid crashes but no alternative rendering path should be provided for those not meeting the requirements. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Is it possible to make an installation check of future requirements and display a strong warning (that is not easily bypassed by just clicking Next) that there is a plan to make them obsolete. This will enable users to prepare beforehand and also give them possibility to object. If 50% are still using the old features should they be faced with the fact No new updates for You!? I am for the use of the latest features of the hardware when they are present by the way :) 2014-12-31 11:55 GMT+02:00 Martijn Berger martijn.ber...@gmail.com: Hi everyone, This is a great idea and should be effected as soon as possible ( 2.74 ). As in practice blender does not run really well on graphics hardware that is more then 10 years old anyway. We can save ourselves a lot of bug reports and headaches by just adding a check for this and warning users when we find less then OpenGL 2.1. I am all for trying to keep blender accessible to a as large as possible group of users. But I think it is safe to say that anyone should have access to OpenGL 2.1 capable hardware as this translates to 10-11 year old hardware. On Tue, Dec 30, 2014 at 4:49 PM, Antony Riakiotakis kal...@gmail.com wrote: Hello again, The times of fixed function OpenGL pipeline have been very fun and happy, with coders trying to ingeniously hack the fixed function parameters to do the things they wanted. But I believe we are getting to the point where fixed function OpenGL starts holding us back. We already require GLSL support for some of the fancier features of blender, but probably it's time to feel free to consider shaders as the primary display mechanism if we want to, without needing to code fallbacks to a fixed function alternative. Especially anything that requires mixing multiple textures (such as texture painting with masks or brush overlays) or attributes in a non standard way is difficult without shaders. This is scheduled to happen as part of the viewport refactor, but having the hardware requirements there will enable us to do more improvements now. The proposal is not about throw away every legacy path next release, rather than assuming that users will need to have access to newer hardware from now on if they wish to access core features. Shader availability can be tested to avoid crashes but no alternative rendering path should be provided for those not meeting the requirements. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Hello again, The times of fixed function OpenGL pipeline have been very fun and happy, with coders trying to ingeniously hack the fixed function parameters to do the things they wanted. But I believe we are getting to the point where fixed function OpenGL starts holding us back. We already require GLSL support for some of the fancier features of blender, but probably it's time to feel free to consider shaders as the primary display mechanism if we want to, without needing to code fallbacks to a fixed function alternative. Especially anything that requires mixing multiple textures (such as texture painting with masks or brush overlays) or attributes in a non standard way is difficult without shaders. This is scheduled to happen as part of the viewport refactor, but having the hardware requirements there will enable us to do more improvements now. The proposal is not about throw away every legacy path next release, rather than assuming that users will need to have access to newer hardware from now on if they wish to access core features. Shader availability can be tested to avoid crashes but no alternative rendering path should be provided for those not meeting the requirements. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
