[Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing

[Courtney Goeltzenleuchter]

I've added a viewport_array-rc2 branch to my github repository with updates
from the feedback so far. Also includes a commit from Ian to Add varying
slot for viewport index.

Courtney


On Fri, Nov 22, 2013 at 3:51 PM, Courtney Goeltzenleuchter <
courtney at lunarg.com> wrote:

> Got it.
>
>
> On Fri, Nov 22, 2013 at 2:55 PM, Chris Forbes <chrisf at ijw.co.nz> wrote:
>
>> It's just that last block that were messed up -- rest was context.
>>
>> Sorry for any confusion.
>>
>>
>> On Sat, Nov 23, 2013 at 10:06 AM, Courtney Goeltzenleuchter <
>> courtney at lunarg.com> wrote:
>>
>>> Hi Chris,
>>>
>>> I'm using this version of the spec:
>>> http://www.opengl.org/registry/specs/ARB/viewport_array.txt
>>>
>>> On Thu, Nov 21, 2013 at 4:41 PM, Chris Forbes <chrisf at ijw.co.nz> wrote:
>>>
>>>> I was just comparing to the list in the ARB_viewport_array spec.
>>>>
>>>>
>>>> On Fri, Nov 22, 2013 at 11:33 AM, Courtney Goeltzenleuchter <
>>>> courtney at lunarg.com> wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Where are you getting your defines?
>>>>> I copied them from include/GL/gl.h
>>>>> #define GL_VIEWPORT 0x0BA2
>>>>> /* Scissor box */
>>>>> #define GL_SCISSOR_BOX 0x0C10
>>>>> #define GL_SCISSOR_TEST 0x0C11
>>>>> #define GL_SCISSOR_TEST 0x0C11
>>>>> #define GL_DEPTH_RANGE 0x0B70
>>>>>
>>>>> Ah, FIRST_VERTEX looks different.
>>>>> #define GL_FIRST_VERTEX_CONVENTION        0x8E4D
>>>>>
>>>>> I'll add PROVOKING_VERTEX
>>>>>
>>>>> Looks like UNDEFINED_VERTEX was wrong as well.
>>>>> (include/GL/glext.h) #define GL_UNDEFINED_VERTEX               0x8260
>>>>>
>>>>>  I was modelling one of the other extension xml files and they had
>>>>> similar defines, though I could see no effect including or excluding them.
>>>>>
>>>>> Should I just get rid of the definitions for values that already exist
>>>>> in gl.h or glext.h?
>>>>>
>>>>> Courtney
>>>>>
>>>>>
>>>>> On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes <chrisf at ijw.co.nz>wrote:
>>>>>
>>>>>> I'm surprised the build system accepts the conflicting second
>>>>>> definition of SCISSOR_BOX at all, actually -- that's weird.
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes <chrisf at ijw.co.nz>wrote:
>>>>>>
>>>>>>> I mean some of the values don't match the spec :)
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter <
>>>>>>> courtney at lunarg.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes <chrisf at ijw.co.nz>wrote:
>>>>>>>>
>>>>>>>>> Oops -- the 8E4E is obviously correct. Artifact of me switching
>>>>>>>>> how I
>>>>>>>>> was commenting halfway through.
>>>>>>>>>
>>>>>>>>> On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes <chrisf at ijw.co.nz>
>>>>>>>>> wrote:
>>>>>>>>> > These are bogus:
>>>>>>>>> >
>>>>>>>>> > +    <enum name="SCISSOR_BOX" value="0x0C10"/>
>>>>>>>>> > +    <enum name="VIEWPORT" value="0x0BA2"/>
>>>>>>>>> > +    <enum name="DEPTH_RANGE" value="0x0B70"/>
>>>>>>>>> > +    <enum name="SCISSOR_TEST" value="0x0C11"/>
>>>>>>>>> > +    <enum name="FIRST_VERTEX_CONVENTION" value="0x0C10"/>
>>>>>>>>>
>>>>>>>>
>>> In the spec I'm using I see:
>>>
>>> New Tokens
>>>
>>>     Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
>>>     GetDoublev and GetInteger64v:
>>>
>>>         MAX_VIEWPORTS                                   0x825B
>>>         VIEWPORT_SUBPIXEL_BITS                          0x825C
>>>         VIEWPORT_BOUNDS_RANGE                           0x825D
>>>         LAYER_PROVOKING_VERTEX                          0x825E
>>>         VIEWPORT_INDEX_PROVOKING_VERTEX                 0x825F
>>>
>>>     Accepted by the <pname> parameter of GetIntegeri_v:
>>>
>>>         *SCISSOR_BOX                                     0x0C10*
>>>
>>>     Accepted by the <pname> parameter of GetFloati_v:
>>>
>>>         *VIEWPORT                                        0x0BA2*
>>>
>>>     Accepted by the <pname> parameter of GetDoublei_v:
>>>
>>>         *DEPTH_RANGE                                     0x0B70*
>>>
>>>     Accepted by the <pname> parameter of Enablei, Disablei, and IsEnabledi:
>>>
>>>         *SCISSOR_TEST                                    0x0C11*
>>>
>>> Thus my confusion regarding "bogus" values.
>>>
>>>     Returned in the <data> parameter from a Get query with a <pname> of
>>>     LAYER_PROVOKING_VERTEX or VIEWPORT_INDEX_PROVOKING_VERTEX:
>>>
>>>         FIRST_VERTEX_CONVENTION                         0x8E4D
>>>         LAST_VERTEX_CONVENTION                          0x8E4E
>>>         PROVOKING_VERTEX                                0x8E4F
>>>         UNDEFINED_VERTEX                                0x8260
>>>
>>>
>>>
>>>
>>>>
>>>>>>>> What do you mean by "bogus"?
>>>>>>>> I was emulating other extension xml files. Are these not needed
>>>>>>>> because they are already defined in gl_ext.h?
>>>>>>>>
>>>>>>>>
>>>>>>>>> >
>>>>>>>>> > 0x8E4D
>>>>>>>>> >
>>>>>>>>> > +    <enum name="LAST_VERTEX_CONVENTION" value="0x8E4E"/>
>>>>>>>>> >
>>>>>>>>> > 0x8E4E
>>>>>>>>> >
>>>>>>>>> > add: <enum name="PROVOKING_VERTEX" value="0x8E4F"/>
>>>>>>>>> >
>>>>>>>>> > +    <enum name="UNDEFINED_VERTEX" value="0x8E4F"/>
>>>>>>>>> >
>>>>>>>>> > 0x8260
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Courtney Goeltzenleuchter
>>>>>>>> LunarG
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Courtney Goeltzenleuchter
>>>>> LunarG
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Courtney Goeltzenleuchter
>>> LunarG
>>>
>>>
>>
>
>
> --
> Courtney Goeltzenleuchter
> LunarG
>
>


-- 
Courtney Goeltzenleuchter
LunarG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131125/d06c7243/attachment.html>