Re: Chromium, DMX and OpenGL 2.0

Chris Burns wrote:
> 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.

Yes, that's a good example to follow.


> 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)?

It's necessary for tilesort to work, for example.  In other cases, like 
a sort-last config, you could probably get by without it.


> 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,

I believe nolist means the function should not get compiled into display 
lists.  glGet* functions are examples.


> 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" ?

Some functions, like glPixelStore are interpreted on the client-side 
only and aren't packed into the protocol stream.  Though, I seem to 
recall we might be packing glPixelStore commands for some reason in 
Chromium.

Other functions aren't packed but instead converted into other calls 
which are packed.  For example, I think glTexEnvi is converted to glTexEnvf.

I guess in general, look for other existing functions similar to the 
ones you have questions about.

-Brian


> 
> 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
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
> 
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/