Linux Graphics Stack Questions

CuriousLittlePenguin · 02-08-2013, 03:40 PM

Hi,

Being a relative beginner in Linux I find it quite difficult to get acquainted with the Linux graphics stack. Googling for the past week or two got me far but many questions are still left unanswered and I was hoping to get help on this forum.

First, does a diagram exist which would show the stack? I found this but it is relatively old: http://dri.sourceforge.net/doc/images/control_flow.jpg Is it still valid? And would X.org implementation of the X server change anything (the diagram assumes XFree86)?
Diagram referenced in 1 shows a way for an application to access the GPU directly by using MMIO and an OpenGL rendering library. I have two question about how this works:
a) This OpenGL library is obviously not Mesa since that is contained in the X server. So what is it? QT for example?
b) Where does the application get the knowledge it needs to communicate with the GPU? Doesn't this communication have to go through a driver of some sort?
Again referring to the diagram mentioned in point 1, why is there a DRI module inside the X server? Is it not the main purpose of a DRI for applications to avoid going through X server to access the GPU and go straight to the GPU (actually to its kernel drivers)? So the orange path shown on the left in the mentioned diagram (the one with DRILib and DRMLib)?
What is a graphics card driver made up of? I read this:
http://yangman.ca/blog/2009/10/linux...ack-explained/
a) So if one is referring to a graphics card's kernel driver is this always a DRM driver?
b) Could someone please give an example of what DDX does and why that particular function is device dependent? The article only mentions mode setting (which I do not understand why it is device dependent). However as I understand it mode setting is now being moved into kernel (KMS) so DDX is probably not needed for that anymore, correct? What else does it do?
Does anyone know of a similar diagram as mentioned in item 1 which explains DirectFB structure?
a) Where does DirectFB fit into the graphics stack? Does it run parallel to the X server in referenced diagram? So is it between kernel and an application which is not an X application?
b) Does one need special drivers to use DirectFB or are DRM and DRI drivers the only things which are needed?

I would like to thank anyone answering above questions in advance and hope I will not be the only one benefiting from them.

jpollard · 02-09-2013, 01:01 PM

Quote:

Originally Posted by CuriousLittlePenguin

Hi,

Being a relative beginner in Linux I find it quite difficult to get acquainted with the Linux graphics stack. Googling for the past week or two got me far but many questions are still left unanswered and I was hoping to get help on this forum.

First, does a diagram exist which would show the stack? I found this but it is relatively old: http://dri.sourceforge.net/doc/images/control_flow.jpg Is it still valid? And would X.org implementation of the X server change anything (the diagram assumes XFree86)?

It looks fairly reasonable.

Quote:

Diagram referenced in 1 shows a way for an application to access the GPU directly by using MMIO and an OpenGL rendering library. I have two question about how this works:
a) This OpenGL library is obviously not Mesa since that is contained in the X server. So what is it? QT for example?
b) Where does the application get the knowledge it needs to communicate with the GPU? Doesn't this communication have to go through a driver of some sort?

Depends on the use - The X client library is the mesa client - it generates the X calls to the X server which carries out the OpenGL operation.

Driver of some sort - there must be an utility library (I believe the X GL client library can do that). If the GPU handles the OpenGL functions directly, then the client library can allocate the screen area and use it. If the GPU doesn't do it, then the functions go through the X servers Mesa implementation. Thus the functions still work, just slower.

Quote:

Again referring to the diagram mentioned in point 1, why is there a DRI module inside the X server? Is it not the main purpose of a DRI for applications to avoid going through X server to access the GPU and go straight to the GPU (actually to its kernel drivers)? So the orange path shown on the left in the mentioned diagram (the one with DRILib and DRMLib)?

So that the X operations can be processed as fast as possible. To do that means it has to talk to the direct rendering engine, if for no other reason, than to coordinate GPU processing.

Quote:

What is a graphics card driver made up of? I read this:
http://yangman.ca/blog/2009/10/linux...ack-explained/
a) So if one is referring to a graphics card's kernel driver is this always a DRM driver?
b) Could someone please give an example of what DDX does and why that particular function is device dependent? The article only mentions mode setting (which I do not understand why it is device dependent). However as I understand it mode setting is now being moved into kernel (KMS) so DDX is probably not needed for that anymore, correct? What else does it do?

Can't help with those.

Quote:

Does anyone know of a similar diagram as mentioned in item 1 which explains DirectFB structure?
a) Where does DirectFB fit into the graphics stack? Does it run parallel to the X server in referenced diagram? So is it between kernel and an application which is not an X application?
b) Does one need special drivers to use DirectFB or are DRM and DRI drivers the only things which are needed?

DirectFB doesn't involve the X server at all. It is designed more for standalone operations (like a phone, though applicable to any embedded use). More info on DirectFB at http://en.wikipedia.org/wiki/DirectFB

I would like to thank anyone answering above questions in advance and hope I will not be the only one benefiting from them.[/QUOTE]

CuriousLittlePenguin · 02-16-2013, 11:10 AM

Thank you very much for your response jpollard and appologies for my late response.

If I may, I would like to ask some additional questions about the Linux graphics stack:

Could anyone provide a simple example of what a lowest level kernel graphics driver receives as an input, what it ouptuts to the GPU and where it outputs it to? Would this be a good simplified example: Input: Draw a rectangle between points 0,0 and 300,300; Output: a command to the GPU's processor to write a command to draw a rectangle into its command buffer and two points into GPU's memory; this would be output to the PCIe for example. I'm fishing here so I hope my example will not confuse anyone in case it is completely wrong.
I am still in the dark about question 4 from my previous post. I can not get a clear picture about how a graphics driver is built. I am currently under the impression that there is in fact only one true graphics driver and that is the low level kernel driver. Other drivers such as DRI and DDX are then only interfaces to that driver which are installed if needed (for example if using X server or DRI). Am I correct in assuming this? And if so, where does the DRM fit in?
How can Linux graphics driver updates be done without restarting the system (only restarting X server is enough on a PC)? This speaks against my assumption above about one main kernel driver. If restarting X is indeed enough this implies only DDX is upgraded after a driver update wheras the kernel driver stays the same. Or is it loaded as module and is unloaded and the updated one loaded back when the X server restarts?

Thank you.

jpollard · 02-16-2013, 12:02 PM

Quote:

Originally Posted by CuriousLittlePenguin

Thank you very much for your response jpollard and appologies for my late response.

If I may, I would like to ask some additional questions about the Linux graphics stack:

Could anyone provide a simple example of what a lowest level kernel graphics driver receives as an input, what it ouptuts to the GPU and where it outputs it to? Would this be a good simplified example: Input: Draw a rectangle between points 0,0 and 300,300; Output: a command to the GPU's processor to write a command to draw a rectangle into its command buffer and two points into GPU's memory; this would be output to the PCIe for example. I'm fishing here so I hope my example will not confuse anyone in case it is completely wrong.

The last time I looked, it didn't work that way. What happened (I was looking at the X server at the time) was that the driver only provided mapped access to the video card control registers. Drawing could then be done via memory mapped I/O to/from a buffer in the X server (slow), or by display commands taken from a memory mapped buffer. The I/O was directly to/from the video card. I believe this is still done, but now through the direct rendering module (DRM) so that more cards can be supported generically.

Quote:

I am still in the dark about question 4 from my previous post. I can not get a clear picture about how a graphics driver is built. I am currently under the impression that there is in fact only one true graphics driver and that is the low level kernel driver. Other drivers such as DRI and DDX are then only interfaces to that driver which are installed if needed (for example if using X server or DRI). Am I correct in assuming this? And if so, where does the DRM fit in?

It can depend on the definition of "driver". A driver is used in two different contexts - interacting directly with device registers in the kernel... and interacting directly between the device and the application. The video drivers get vague in this case. The kernel drivers focus more on coordinating access to the device, but the user space drivers spend their time doing the actual work.

Quote:

How can Linux graphics driver updates be done without restarting the system (only restarting X server is enough on a PC)? This speaks against my assumption above about one main kernel driver. If restarting X is indeed enough this implies only DDX is upgraded after a driver update wheras the kernel driver stays the same. Or is it loaded as module and is unloaded and the updated one loaded back when the X server restarts?

Quote:

Thank you.

It depends on which driver level you referr to. If the driver being updated is the usermode portion of the X server, then just logging out will cause the old driver to be discard, as the X server restarts for the new login window (which will load the new driver as it starts). This has been traditional for quite a while to remove problems of a corrupted X server (that may be running) from causing password/control leaks to a new user.

For kernel level drivers, it USUALLY requires a reboot. If the specific driver is not active, then it may be unloaded and the updated one loaded (see lsmod, rmmod, insmod/modprobe). This is frequently the case for drivers of USB devices.

It is POSSIBLE to do for drivers for the USB controllers, but whether they are built as a module or not is up to the distribution. In the case of USB, the core driver is named "usbcore" when a module, but some distributions (such as Fedora) have them builtin. To update a driver in this case requires a new kernel.

Using "lsmod" you can see the list of drivers, and how they relate. On my system I get:

Code:

$ lsmod
Module                  Size  Used by
usblp                  18747  0 
nls_utf8               12558  0 
udf                    89460  0 
crc_itu_t              12614  1 udf
vfat                   17412  0 
fat                    56229  1 vfat
tcp_lp                 12664  0 
usb_storage            60382  0 
bnep                   19588  2 
bluetooth             317756  7 bnep
rfkill                 21343  2 bluetooth
fuse                   78045  3 
ebtable_nat            12808  0 
ebtables               30689  1 ebtable_nat
ipt_MASQUERADE         12881  3 
iptable_nat            13384  1 
nf_nat                 25379  2 ipt_MASQUERADE,iptable_nat
xt_CHECKSUM            12550  1 
iptable_mangle         12696  1 
bridge                 91176  0 
stp                    12869  1 bridge
llc                    14091  2 bridge,stp
be2iscsi               81680  0 
iscsi_boot_sysfs       15642  1 be2iscsi
bnx2i                  54594  0 
cnic                   67009  1 bnx2i
uio                    19029  1 cnic
cxgb4i                 32910  0 
cxgb4                 108295  1 cxgb4i
cxgb3i                 32973  0 
libcxgbi               56554  2 cxgb4i,cxgb3i
tpm_bios               13529  0 
cxgb3                 155460  1 cxgb3i
mdio                   13436  1 cxgb3
ib_iser                38040  0 
rdma_cm                42039  1 ib_iser
ib_cm                  41693  1 rdma_cm
iw_cm                  18177  1 rdma_cm
ib_sa                  32889  2 rdma_cm,ib_cm
ib_mad                 46393  2 ib_cm,ib_sa
ib_core                73875  6 ib_iser,rdma_cm,ib_cm,iw_cm,ib_sa,ib_mad
ib_addr                13786  1 rdma_cm
iscsi_tcp              18334  0 
libiscsi_tcp           24177  4 cxgb4i,cxgb3i,libcxgbi,iscsi_tcp
libiscsi               50528  8 be2iscsi,bnx2i,cxgb4i,cxgb3i,libcxgbi,ib_iser,iscsi_tcp,libiscsi_tcp
scsi_transport_iscsi    57475  8 be2iscsi,bnx2i,libcxgbi,ib_iser,iscsi_tcp,libiscsi
ip6t_REJECT            12940  2 
nf_conntrack_ipv6      14524  15 
nf_defrag_ipv6         18222  1 nf_conntrack_ipv6
nf_conntrack_netbios_ns    12666  0 
nf_conntrack_broadcast    12528  1 nf_conntrack_netbios_ns
ip6table_filter        12816  1 
nf_conntrack_ipv4      14970  19 iptable_nat,nf_nat
nf_defrag_ipv4         12674  1 nf_conntrack_ipv4
xt_state               12579  31 
nf_conntrack           83893  8 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv6,nf_conntrack_netbios_ns,nf_conntrack_broadcast,nf_conntrack_ipv4,xt_state
ip6_tables             26846  1 ip6table_filter
binfmt_misc            17432  1 
snd_hda_codec_hdmi     36328  1 
snd_hda_codec_realtek    77993  1 
snd_hda_intel          37564  4 
snd_hda_codec         126531  3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep              17612  1 snd_hda_codec
iTCO_wdt               13481  0 
iTCO_vendor_support    13420  1 iTCO_wdt
snd_seq                64842  0 
snd_seq_device         14130  1 snd_seq
snd_pcm                97617  3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
e1000e                236447  0 
lpc_ich                17062  0 
coretemp               13438  0 
mfd_core               13146  1 lpc_ich
snd_timer              28816  2 snd_seq,snd_pcm
snd                    79418  17 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
soundcore              14485  1 snd
snd_page_alloc         18102  2 snd_hda_intel,snd_pcm
shpchp                 37095  0 
i2c_i801               18114  0 
ioatdma                54375  28 
dca                    14602  1 ioatdma
i5100_edac             17024  0 
edac_core              56483  1 i5100_edac
microcode              23447  0 
serio_raw              13376  0 
vhost_net              33757  3 
macvtap                18184  1 vhost_net
macvlan                18645  1 macvtap
tun                    22881  8 vhost_net
kvm_intel             136589  9 
kvm                   419172  1 kvm_intel
uinput                 17607  0 
nfsd                  276902  13 
lockd                  93333  1 nfsd
nfs_acl                12742  1 nfsd
auth_rpcgss            43886  1 nfsd
sunrpc                255307  17 nfsd,lockd,nfs_acl,auth_rpcgss
ata_generic            12911  0 
pata_acpi              13039  0 
pata_it8213            13091  0 
mptsas                 62324  0 
mptscsih               38797  1 mptsas
mptbase                99870  2 mptsas,mptscsih
scsi_transport_sas     39291  1 mptsas
radeon                896029  5 
ttm                    79619  1 radeon
drm_kms_helper         40132  1 radeon
drm                   255124  7 radeon,ttm,drm_kms_helper
i2c_algo_bit           13251  1 radeon
i2c_core               38317  5 i2c_i801,radeon,drm_kms_helper,drm,i2c_algo_bit

Which is quite a list.

The first column is the module name, second column it memory size, the third is usage count, followed by a list of the layered drivers involved.

A shortened list involving only the radeon driver for my card (a now old FireGL V3600) is:

Code:

$ lsmod | grep radeon
radeon                896029  5 
ttm                    79619  1 radeon
drm_kms_helper         40132  1 radeon
drm                   255124  7 radeon,ttm,drm_kms_helper
i2c_algo_bit           13251  1 radeon
i2c_core               38317  5 i2c_i801,radeon,drm_kms_helper,drm,i2c_algo_bit

These interdependencies are mostly for coordination. The video card driver (radeon) has to provide support for ttm to emulate terminals. It also has to coordinate with drm_kms_helper and drm drivers for the direct rendering access to work. Not certain of how the interaction with the i2c_core goes, but from a very brief scanning of the source (actually via google), it appears to be used to help identify various video cards, and their capabilities.

The complexity of interfacing with all the different kinds of video cards is what has pushed nearly all of the actual USE of the video card into user mode. Even for two cards that fully implement OpenGL capability, they are very likely to have totally different ways to interface - what might be a texture load on one, could very easily be a load transform map on the other. To simplify the kernel level drivers, they try to just stay with the minimum (VGA frame buffer, and virtual console terminals) - and provide an interface to user space to access the rest.

CuriousLittlePenguin · 02-16-2013, 12:57 PM

Quote:

the driver only provided mapped access to the video card control registers

This is a new and very enlightening piece of information for me. Thank you very much jpollard.

When you say:

Quote:

I believe this is still done, but now through the direct rendering module (DRM) so that more cards can be supported generically.

what do you mean with "through the DRM"? Does this mean that only DRM has access to the mapped registers and memory and commands buffers? What if one does not have the DRM module? Is that even possible? As I understand it DRM is not that old so I imagine there are machines out there without it.
And I guess that if only frame buffer and/or virtual console is used then DRM is not even neccessary, am I correct? Or does it just channel through the requests for frame buffer manipulation for example?

Also why would going through DMA make for a wider support in terms of graphics cards? Isn't DRM there to deal with memory management, resource locking, and secure hardware access?

One other thing about the DRM... Is the DRM module hardware-specific and is therefore different for different GPUs? In your case if you were to replace your graphics card with a different one and install appropriate drivers then would the DRM module be replaced by that of the new drivers?

Thanks.

jpollard · 02-16-2013, 02:14 PM

Quote:

Originally Posted by CuriousLittlePenguin

This is a new and very enlightening piece of information for me. Thank you very much jpollard.

When you say:
what do you mean with "through the DRM"? Does this mean that only DRM has access to the mapped registers and memory and commands buffers? What if one does not have the DRM module? Is that even possible? As I understand it DRM is not that old so I imagine there are machines out there without it.

At this point, I think you would have to look in the DRM driver for a specific video card interface to see how it does things. I believe DRM mediates the access to the registers. I don't know exactly how, but it doesn't require X, and using it allows applications to coordinate with the X server (the X server knows where the window is, but doesn't do anything with it - that is up to the application and the DRM management). DRM is fairly old as kernels go. I don't remember it in the 2.2/2.3 kernel, but in the 2.4 and after.

Quote:

And I guess that if only frame buffer and/or virtual console is used then DRM is not even neccessary, am I correct? Or does it just channel through the requests for frame buffer manipulation for example?

That is my understanding. Before the DRM module it was up to a privileged system call to essentially poke the videocard to access the control registers.. error prone and not very secure.

Quote:

Also why would going through DMA make for a wider support in terms of graphics cards? Isn't DRM there to deal with memory management, resource locking, and secure hardware access?

yes, but the dma is done directly by the video card. As I understand it, the DRM only validates parameters for the transfer. Different video cards have different ways of specifying how DMA is done. It is my understanding that the DRM handles that.

Quote:

One other thing about the DRM... Is the DRM module hardware-specific and is therefore different for different GPUs? In your case if you were to replace your graphics card with a different one and install appropriate drivers then would the DRM module be replaced by that of the new drivers?

It is my understanding that the DRM module attempts to make as much data transfer to/from the video cards generic. To that end there is a split - the DRM module presents as much as possible in a device independent way, and the lower level video card driver has to support the DRM driver in that activity. Not all operations of the DRM driver are necessarily supported.

You can get more (and likely better) information over at: http://www.kernel.org/doc/htmldocs/drm.html

Quote:

Thanks.

one thing (out of possible many), the ttm module provides a memory management interface... not terminal handling as such.

CuriousLittlePenguin · 02-17-2013, 04:03 PM

OK then, does the following make sense:

When writing Linux drivers for a new graphics card they are almost always written for the X system, correct? Meaning that a DRM driver, a DDX and Mesa driver are all written. Am I correct so far? And one more question: where does libGL.so fit into all this? From what I read (couldn't find much though) this is also hardware dependant. So when writting drivers is libGL.so also written and who uses it?

What are the alternatives to X? I take it framebuffer is one. So the drivers could be written to communicate with the GPU on one end and to the linux framebuffer on the other, where the Linux framebuffer defines a common interface into userspace for all applications to use (the ones which have framebuffer support). VESA being one of such interfaces for example (vesafb). Am I far off?

Are there any drivers out there which combine the two - X drivers and framebuffer drivers? Are perhaps most made this way?

Are there any other drivers like X and framebuffer? I saw Wayland being mentioned a couple of times when browsing the web. It also requires special drivers I imagine?

Thanks

jpollard · 02-17-2013, 05:09 PM

It isn't a "special driver".

If you don't use the X protocol, then the only available interface is to go through a package/library/toolkit that implements the direct rendering. Qt has one for wayland.

The framebuffer is generally slow... and definitely not accelerated. When you want speed... you don't go there.

The problem is sharing access to GPU resources. This is a nontrivial activity. It is relatively easy if there is no sharing, no text, and only one application.

The problem is when there is more than one. And that leads into display/window managers that allocate and grant access to a subset of the GPU resources, preventing one application from interfering with with another.

The purpose of X was to make such access independent of the system the resources were on. Thus, X is based on a network communication protocol, and only the X server had to interface directly with the GPU.

For some applications, this is "too slow" - usually video related, but also because X was designed to handle mouse/keyboard/display activity, but not audio (at the time, only the most expensive had audio capability). "Too slow" also desired something that could bypass the X protocol overhead, and go directly to the local GPU. This, of course, meant that it could NOT work over the network. X has improved, so some video actually works over the net... but not all, and not with audio (the syncronization has a problem... video likes to be able to drop frames in case it needs to catch up, but audio dropouts are a real problem). The usual solution is that video applications run locally on the system with direct GPU access, and uses the network to download a stream. This allows the application to drop frames (timing problems), and maintain audio sync.

Wayland is just another toolkit + display/window manager, but not based on using the X foundation. This allows it to be faster for local applications, but remote applications don't work. To make remote applications work requires an additional piece of software to interface with Wayland, and provide the network requirements.

fbobraga · 02-17-2013, 05:14 PM

it's not the wrong forum for this topic? I think it belongs to http://www.linuxquestions.org/questi...ux-software-2/ ...

jpollard · 02-18-2013, 07:36 AM

Quote:

Originally Posted by fbobraga

it's not the wrong forum for this topic? I think it belongs to http://www.linuxquestions.org/questi...ux-software-2/ ...

Its kind of in between. Yes it is software, but it is also a question from someone trying to understand how things work - "Being a relative beginner in Linux..." would call for this forum.

CuriousLittlePenguin · 02-23-2013, 01:39 PM

If I posted in a wrong forum I do apologize but I felt (and kind of still do) that my initial questions were more suited for a beginners forum.

As for the subject of this thread....
I went looking into what comprises "the Linux graphics drivers" for a particular hardware, keeping in mind that "drivers" is a relatively broad term. Until recently I considered drivers to be the low level piece of software which directly interfaces and communicates with a device. Then I saw terms like DRI driver, DDx driver and similar being used.

Anyway, I took Intel's Linux graphics drivers as an example: https://01.org/linuxgraphics/documentation/source-code
It would seem, that Intel's driver is made up of:

X.org 2D driver - if I am not mistaken this is X.org's DDX driver
Mesa 3D GL driver - this I imagine is a DRI driver which is "pulled in" by MESA in a form of a *.so
DRM and AGPGART kernel module - I guess this is the low level driver responsible for directly interfacing with the GPU by accessing its registers.
LIBDRM userland DRM module - This, I guess, is the the libDRM library
LIBVA and VA-DRIVER-INTEL - Video Acceleration API implementation in a form of the libVA library plus accompanying driver

Are my descriptions next to above listed components of Intel's graphics drivers correct?

About point 3:

DRM is made up of two parts (generic/core and device specific). Is the DRM kernel module mentioned above and on the referenced web page only the device specific part?
Is the AGPGART module relevant only if one has an AGP card and not a PCIe for example?
In kernel configuration under CONFIG_AGP (-> dev/agpgart(AGP support)) make menuconfig's help states: "You should say Y here if you want to use GLX or DRI." Again, is this only applicable if an AGP card is used?
A description of AGPGART I found on sourceforge says that AGPGART "is part of your motherboard's chipset and handles gathering data from memory and passing it to the card as a continuous stream." Does the DRM not contain this same functionality with GEM or TTM?
If the answer to my last question is yes, then does one chose from one of the two modules under point 3 based on which card one has? So only DRM module or only AGPGART is enough?

Thanks.

niagr · 04-12-2013, 10:27 AM

Thank you jpollard and CuriousLittlePenguin for all these questions and explanations; it has been a very enlightening read for me.

Here are some more resources for understanding the graphics stack:
Stack overview: http://blog.mecheye.net/2012/06/the-...raphics-stack/
DRI introduction: http://dri.sourceforge.net/doc/DRIintro.html
DRI docs list: http://dri.freedesktop.org/wiki/Documentation
DRM explanation: http://dri.freedesktop.org/wiki/DRM?...c81e34aa54d27b

I would like to ask a few additional questions:
What does it mean to say "binding an OpenGL context to a window"? Basically, what is it that GLX or EGL do exaclty? Also, when applications use direct rendering, what is the target of that rendering, i.e, where does the final image go and in what form is it output? Also, how does the X server display the contents of the direct rendering window to an appropriate place on the screen and send it to the framebuffer. I hope these questions make sense (please tell me if they don't).

_Jasper · 04-12-2013, 11:02 AM

AGPGART is really old and only for AGP cards, so just ignore it. DRM replaces it.

Otherwise, that's mostly accurate. Note that DRM really doesn't have a generic part. There's some ad-hoc agreement over some set of ioctls for basic usage, but it's all device-specific.

jpollard · 04-12-2013, 11:13 AM

Quote:

Originally Posted by niagr

Thank you jpollard and CuriousLittlePenguin for all these questions and explanations; it has been a very enlightening read for me.

Thank you.

Quote:

I would like to ask a few additional questions:
What does it mean to say "binding an OpenGL context to a window"? Basically, what is it that GLX or EGL do exaclty? Also, when applications use direct rendering, what is the target of that rendering, i.e, where does the final image go and in what form is it output? Also, how does the X server display the contents of the direct rendering window to an appropriate place on the screen and send it to the framebuffer. I hope these questions make sense (please tell me if they don't).

Yes, GLX and EGL do create windows.. and has the GL context tied to that window. Without the use use of GLX/EGL (by using a layered library such as Mesa without acceleration) tends to be slow as the rendering will mostly be done in software. The advantage GLX does for the X server is to allow that to be done in the supported hardware, and thus quite a bit faster.

As far as rendering, all the X server effectively does is to specify an offset X,Y coordinate to begin the window rendering. After that, as much as possible is done by the hardware.

_Jasper · 04-12-2013, 11:16 AM

Quote:

Originally Posted by niagr

I would like to ask a few additional questions:
What does it mean to say "binding an OpenGL context to a window"? Basically, what is it that GLX or EGL do exaclty?

X has the concept of multiple windows in an environment. GL does not. GL has a bunch of global state about your one scene. When SGI realized that was a terrible idea, they backpeddled and introduced something called a "context", which says "OK, sure, it's not global state anymore. You can have multiple scenes". However, it still doesn't define how you take one of those scenes and glue it to an X window.

Note that all platforms have the same problem, and they all mostly have the same solution. X has GLX, Windows has WGL, and OS X has AGL.

EGL is an attempt to take those three different APIs that are practically the same but with different prefixes and make them into one API.

Quote:

Also, when applications use direct rendering, what is the target of that rendering, i.e, where does the final image go and in what form is it output?

Depends how you look at it. From the OpenGL and graphics card's perspective, the output is "a buffer at some location". GLX tells the X server which window it wants the GL scene and some other junk, and then the X server communicates with the GL implementation through DRI to make sure that everything is OK.

In an uncomposited environment, that's all this information like making sure it's in the right place when you move windows around, and that it's clipped correctly when you have another window on top.

When running a composited window manager (and the window is redirected), X doesn't handle the display of windows, and the "compositor" has that job. The detail is left up to the compositor, but most compositors use OpenGL themselves, which has an extension "texture_from_pixmap" which allows you to take an X window and make a GL texture from it, allowing you to paint it. Positioning of windows has to be handled by the compositor.

Quote:

Also, how does the X server display the contents of the direct rendering window to an appropriate place on the screen and send it to the framebuffer. I hope these questions make sense (please tell me if they don't).

The graphics card handles direct rendering into the framebuffer, and it's controlled by DRI from X and the GL implementation in the application.