[Xorg] Chromium vs GLX protocol

Jens Owen jens at tungstengraphics.com
Thu Jul 29 07:20:33 PDT 2004

Brian Paul wrote:
> Jon Smirl wrote:
>> Slashdot is saying that SGI is going to port their clustered ATI
>> graphics to Linux in the near future. The SGI page says this code is
>> based on Chromium. I've read that the network protocol of Chromium is
>> far better than the GLX protocol, especially in the area of state
>> management. Does anyone have experience with both protocols and can
>> comment on how they compare?
> Sure...
>> If the Chromium protocol really is a lot better would it make sense to
>> evaluate shifting our focus from GLX to the Chromium protocol? In the
>> long  run the coming shift to things like X on GL and Glitz may
>> ultimately move a lot of network traffic from the X protocol to one of
>> the GL ones. If Chromium is significantly better wouldn't it be wiser
>> to change the X server GL protocol now rather than later?
> The Chromium command packer packs GL commands more densely than GLX. A 
> one-byte opcode is used for most commands and operands are packed 
> tightly in memory.  Opcodes are packed separate from the operands in a 
> unique way too.
> Chromium also has a state tracking system which can eliminate redundant 
> commands from being packed/sent.  It's pretty complicated though and 
> still a source of bugs.
> I wouldn't say that Chromium's packer is a *lot* better than GLX.  And I 
> wouldn't advocate switching to it.  GLX interoperability is important 
> and making such a switch would upset that.  I don't think the effort to 
> switch would be worth the trouble.  Performance-wise, I think the gains 
> would be quite modest.


How about supporting key pieces of Chromium in the X.org release in 
addition to GLX?  Could integrating OpenGL API redirection, for example, 
make for a cleaner solution than what Chromium does with "app faker" today?

          Jens Owen            /  \/\ _
   jens at tungstengraphics.com  /    \ \ \   Steamboat Springs, Colorado

More information about the xorg mailing list