Re: [Chromium-dev] Chromium, DMX and OpenGL 2.0

[Chris B. <cb...@ta...>]

Chromium folks,

So I've decided to implement the extensions related to GLSL rather  
than the 2.0 spec.  I'm guessing it'll be similar to the way the  
GL_ARB_vertex_program and GL_ARB_fragment_program extensions are  
implemented.

Given that, I noticed that Chromium keeps track of a lot of the state  
related to the fragment_program and vertex_program extensions within  
the state_tracker. Is it necessary that this approach be followed for  
the GLSL shader extensions to get them working, or is this essentially  
there for good performance (but not strictly necessary)?

Also, I'm not clear on what all of the "props" and "chromium" props  
values in the APIspec.txt file really mean. In particular, i dont'  
understand what "nolist" means and whether a given function should use  
it, and I'm not sure how to determine whether a given function should  
be tagged "pack" or "extpack".  It seems to me that all functions need  
to be packed at some point, why would you label a function "nopack" ?

Chris~


On Jan 14, 2008, at 3:16 PM, Brian Paul wrote:

> Adding to the core is basically equivalent to adding extensions in  
> this case.  Both involve adding new entrypoints and the underlying  
> code.
>
> -Brian
>
> Chris Burns wrote:
>> I've read the document about adding OpenGL extensions to Chromium.  
>> I'm not sure what exactly the differences are in adding an  
>> extension versus adding core routines, since there is no guide to  
>> extending Chromium to new versions of OpenGL.
>> As it happens, my immediate need is for GLSL shader support, which  
>> is available through an ARB extension (not currently implemented in  
>> Chromium), as well as the 2.x core API. Do you know that it would  
>> be simpler to simply add support for this extension rather than  
>> adding the functionality as core routines?
>> Chris~
>> On Jan 11, 2008, at 8:35 AM, Brian Paul wrote:
>>> Brian Paul wrote:
>>>> Chris Burns wrote:
>>>>> Hi,
>>>>>
>>>>> I am working with a PC linux cluster that's using DMX and Chromium
>>>>> 1.9  to run OpenGL apps on a 3x3 tiled wall display. The problem  
>>>>> I'm
>>>>> having  is that there seems to be an issue with OpenGL 2.0.
>>>>> Specifically, I  get a NULL pointer back when I try to call
>>>>> glCreateShader with either  GL_VERTEX_SHADER or  
>>>>> GL_FRAGMENT_SHADER.
>>>>>
>>>>> If I re-login to the machine without DMX and run only on the head
>>>>> node  of the cluster, everything runs fine. Chromium doesn't  
>>>>> seem to
>>>>> make  much difference either way.
>>>>>
>>>>> Does anyone know if DMX is somehow not compatible with the latest
>>>>> OpenGL API routines, or could show me where I need to look to find
>>>>> out  why I'm getting NULL?
>>>>
>>>> The problem is Chromium does not support OpenGL 2.x.
>>>>
>>>> It would be a fair-sized task (a couple weeks?) to implement but if
>>>> you're game, I could give some pointers.
>>>
>>> Several people have asked me for more details off-list.  Let's  
>>> keep the
>>> 2.0 discussion on the list.  Maybe several people can cooperate on  
>>> it.
>>>
>>> Here's my previous reply:
>>>
>>>
>>> The glapi_parser/APIspec.txt file defines all the GL functions.   
>>> You'd
>>> begin by adding the GL 2.0 functions.  Then, when you run 'make'  
>>> quite a
>>> few python scripts will use the spec file to generate various .c  
>>> files.
>>> There will be some failures where hand-coded functions will probably
>>> be needed.  Hand-coded functions are usually listed in "special"  
>>> files.
>>>
>>> I think there's a doc/ file that talks about how to add support  
>>> for new
>>> GL extensions.  That probably has some tips too.
>>>
>>> -Brian
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>>> _______________________________________________
>>> Chromium-dev mailing list
>>> Chr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>