From: Brian P. <bri...@tu...> - 2008-01-15 18:30:16
|
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 >>>> Chr...@li... >>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev >> > > |