Originally posted by mSparks
View Post
Announcement
Collapse
No announcement yet.
X.Org Server & XWayland Hit By Four More Security Issues
Collapse
X
-
Originally posted by oiaohm View Post
Posting over. This point has already been disproved not repeating self get lost now mSparks.
you might as well claim you disproved nvidia doesnt support/run opengl2 any more because all their cards are "only" opengl 4.6Last edited by mSparks; 09 April 2024, 05:42 PM.
Comment
-
Originally posted by mSparks View Postyou didn't disprove anything, you said webgl is limited to gles2, but since gles2 is a subset of opengl/glx - by definition glx supports all of gles2.
Android device is EGL. Angle has a EGL backend as well. Yes on Wayland Angle is EGL. Angle on X11 can be EGL or GLX. Firefox default backend on X11 is EGL not GLX.
Hi there! This is a guest post from Robert Mader, who contributed enormous improvements to Firefox’s graphics stack on Linux. TL;DR In the upcoming Firefox 94 release we will enable the EGL b…
Yes matter of time until chrome on Linux is EGL not GLX even for X11.
By khronos GLX and EGL are Platform Interface options. Here is the really fun part is gles2 is not a subset of GLX. gles2 is a optional part to be used with GLX/EGL/WGL... just like opengl is.
Back in the day you had GLX + opengl under Linux with no gles2 and then you also had GLX with gles2 and no opengl. There is a reason why Xwayland now provides option to chose between opengl and gles2 this allows coping some of the application expected behaviors better.
By khronos definition GLX only support GLX. GLX is a Platform Interface, Opengl and gles2 both sit on top of this platform interface and are not the platform interface.
GLX is not part of gles2 standard. gles2 is not a subset of GLX. GLX is a interface between opengl items and X11 nothing more. Just like EGL is another form of interface between opengl items and native platform.
mSparks you define of GLX is totally wrong. The standards that define EGL, GLX, WGL and so on don't include opengl or gles2.
Basically you example used Android since you used android there is no GLX there at all because that EGL. Even a demo on X11 Linux desktop if the browser is firefox or you have started chrome with EGL flag the webgl will not be on GLX at all but instead on EGL.
GLX is falling out of use very quickly coming a legacy only thing.
Basically stop posting obviously bullshit to anyone who knows how khronos set this out. Just because angle has GLX in it source code does not mean chrome always uses that bit.
mSparks I guess you missed that current day X11 has two platform support layers. EGL and GLX. EGL contains no network transparency at all.
- Likes 1
Comment
-
Originally posted by oiaohm View PostThe fact that GLX and EGL are not part of opengl gles standards but are their own standards is how mesa and nvidia drivers get to share the same code for opengl/glex implementations between the GLX and EGL when under X11.
GLES is a subset of GLES2, GLES2 is a subset of openGL, openGL is a list of function calls GLX can serialise, therefore GLES is a subset of a list of function calls GLX can serialise.
Do you actually know what serialisation and Remote Procedure Calls (RPC) are?
Comment
-
Originally posted by mSparks View PostGLX is a file format (an extension of X11 specifically for openGL function calls) for serialising openGL function calls over a network.One of the major tasks of recent OpenGL development was overcoming the bandwidth constraints between “client” (CPU) and “server” (GPU). Given modern techniques like Vertex Buffer Objects, Vertex Array Objects, Uniform Buffer Objects it is possible to render very complex scenes with only very few data sent from CPU to GPU. These savings in required bandwidth also means, that it was (is) perfectly possible to do remote rendering with OpenGL. ATM I’m developing a small library (for microcontroller...
Except there is a problem. GLX does not process Opengl functions 3.0 and newer.
Originally posted by mSparks View PostGLES is a subset of GLES2, GLES2 is a subset of openGL, openGL is a list of function calls GLX can serialise, therefore GLES is a subset of a list of function calls GLX can serialise
For what it is worth, there is no GLX protocol for OpenGL ES1 or ES2 and much of GL3 (indeed even much of GL2) has no official GLX protocol… VBO’s I think have some experimental protocol in MESA… but it has been experimental for a very, very long time now.
There is nothing added in GL3 or for GLES that got a GLX code to be encoded into.
mSparks without question you cannot serialize majority of GLES into GLX opcodes for network transport because GLX opcode don't exist covering majority of GLES . This is why GLES and Opengl are not a subset of GLX. GLX only implements a subset of Opengl 2.1 and GLES need more than this. Yes subset most of Opengl 2.1 is not implemented and less than 75% of Opengl 2.0 is implemented in GLX.
EGL/WGL/GLX... as in the Platform Interface all only implement a subset of opengl functionality fairly much never exceeding Opengl 2.1 and never GLES v1 let alone later versions newer functions. Its the direct to GPU functionality that allows all the later Opengl and GLES functionality.. Yes 2006 opengl at best for this stuff. Opengl ES/Gles in 2003 being designed for embedded is use the bar min of GLX to setup direct to GPU.
mSparks the reality here is that GLES cannot be sent over network by GLX because GLES cannot be encoded into GLX opcodes.
Basically this has nothing todo with RPC this is all about what i possible. GLX protocol does not contain GLES all version or Opengl 3.0 and newer. Since GLX does not contain these things it cannot be used to transmit them over the network.
Yes GLES and modern Opengl bypasses GLX as soon as it can. Encoding to opcodes has a performance cost.
- Likes 1
Comment
-
Originally posted by oiaohm View PostExcept there is a problem. GLX does not process Opengl functions 3.0 and newer.
Originally posted by oiaohm View PostYes GLES and modern Opengl bypasses GLX as soon as it can. Encoding to opcodes has a performance cost.
glx applications only output glx datastreams. gpu drivers generally interpret these directly - as does angle.
Comment
-
Originally posted by mSparks View PostWhy is it a problem? X forwarding has the same limitation and it was never a problem
Version 1.3 - 2 June 1999
Fun fact X11 forwarding of opengl for newer versions also operated in 2d. Yes local indirect rendering then sending 2d of that over the wire.
GPU instructions have not been sent over the network link for quite some time. You have to have a opengl 2.1 or lower application for this to be happening.
Originally posted by mSparks View Postglx applications only output glx datastreams. gpu drivers generally interpret these directly - as does angle.
Angle in fact used newer opengl functions.
This is a complete list of GLX functions used.
The GLX function used that kills your argument dead.
If glXCreateContextAttribsARB succeeds, it initializes the context
to the initial state defined by the OpenGL specification, and
returns a handle to it. This handle can be used to render to any GLX
surface (window, pixmap, or pbuffer) compatible with <config>,
subject to constraints imposed by the OpenGL API version of the
context.
Yes out of everything that is in GLX angle only uses 19 functions of GLX.
Older versions of GLX documentation makes out the only way to the screen is by GLX. The newer extensions to GLX provide these context handles that bipass
mSparks the simple reality it does not matter if it X11 forwarding. XPRA or RDP.... if the application you are using is Opengl 3.0 or newer you not sending GPU commands over the network. This is the change over to sending 2d data instead of 3d data. To be correct most cases with GLX you don't even get opengl 1.5 and 2.0 and 2.1 if you are using glx encoding instead you find yourself stuck with Opengl 1.4 this is not enough Opengl todo Angle.
These limitations are not a new thing mSparks. You have been purely deceived by 2d trickery that remote opengl works with newer applications. GLX opcodes transporting a current version at the time of opengl commands over network has not worked for decades.
All form of modern desktop graphical transport over network are 2d operations.
- Likes 1
Comment
-
Originally posted by oiaohm View PostThese limitations are not a new thing mSparks.
The key limitation for anything more advanced than early opengl is latency, similar to gles because of gpu limitations.
Could we have better than GLX? sure, but key developers were too busy wasting their time with wayland on ideas that turned out to be hyperbole.
Comment
-
Technically GLX doesn't "need" to be improved. It's mainly for networked X displays to draw with OpenGL post process. You technically, on your own desktop, never use GLX. That's why if you see the subset of function calls GLX has, it's VERY limited. If you run X through a terminal from a server via network login and then use a program running OpenGL over a network, then you will be using GLX.
It's mainly meant for small form factor units with severely limited GPUs in Terminals that mainly just draw a 2D display, and receive OS data in streaming format from a Terminal Server.
Comment
Comment