- Original Message -
> On 03/10/2014 02:52 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On 03/10/2014 03:09 PM, Ian Romanick wrote:
> >>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
> No way. This will break existing applications on Linux.
> >>
> >> How so?
On 03/10/2014 02:52 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On 03/10/2014 03:09 PM, Ian Romanick wrote:
>>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
No way. This will break existing applications on Linux.
>>
>> How so? Before, for example, we had glCompileShaderARB
On 03/10/2014 02:39 PM, Brian Paul wrote:
> On 03/10/2014 03:09 PM, Ian Romanick wrote:
>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
>>> No way. This will break existing applications on Linux.
>
> How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and
> glCompileShader(GLuint)
- Original Message -
> On 03/10/2014 03:09 PM, Ian Romanick wrote:
> > On 03/10/2014 02:06 PM, Ian Romanick wrote:
> >> No way. This will break existing applications on Linux.
>
> How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and
> glCompileShader(GLuint) libGL en
How come? GLhandleARB is still a GLuint on Linux. And calling one vs the other
works just as well.
How does merely un-aliasing the entrypoints break anything?
Jose
- Original Message -
> No way. This will break existing applications on Linux.
>
> On 03/08/2014 05:10 PM, Brian Paul wr
On 03/10/2014 03:09 PM, Ian Romanick wrote:
On 03/10/2014 02:06 PM, Ian Romanick wrote:
No way. This will break existing applications on Linux.
How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and
glCompileShader(GLuint) libGL entrypoints and GLhandleARB=GLuint. After
t
On 03/10/2014 02:06 PM, Ian Romanick wrote:
> No way. This will break existing applications on Linux.
This also breaks the libGL <-> DRI driver ABI. These function entry
points have been aliased for... a decade? I can't understand why we'd
break our own ABI because of something silly that Apple
No way. This will break existing applications on Linux.
On 03/08/2014 05:10 PM, Brian Paul wrote:
> For example, we now we have separate dispatch functions for
> glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
>
> With this change and the previous ones we should be able to build/run
On 10/03/14 14:50, Brian Paul wrote:
On 03/09/2014 02:30 PM, Emil Velikov wrote:
On 09/03/14 01:10, Brian Paul wrote:
For example, we now we have separate dispatch functions for
glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
With this change and the previous ones we should be abl
On 03/10/2014 08:50 AM, Brian Paul wrote:
On 03/09/2014 02:30 PM, Emil Velikov wrote:
On 09/03/14 01:10, Brian Paul wrote:
For example, we now we have separate dispatch functions for
glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
With this change and the previous ones we should b
On 03/09/2014 02:30 PM, Emil Velikov wrote:
On 09/03/14 01:10, Brian Paul wrote:
For example, we now we have separate dispatch functions for
glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
With this change and the previous ones we should be able to build/run
on MacOS again (where G
On 09/03/14 01:10, Brian Paul wrote:
> For example, we now we have separate dispatch functions for
> glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
>
> With this change and the previous ones we should be able to build/run
> on MacOS again (where GLhandleARB is a void pointer, not a G
For example, we now we have separate dispatch functions for
glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
With this change and the previous ones we should be able to build/run
on MacOS again (where GLhandleARB is a void pointer, not a GLuint).
Bugzilla: https://bugs.freedesktop.org
13 matches
Mail list logo
