To elaborate on grawity's answer, there are several issues, of varying degrees of relevance, to your question:
- UGA vs. GOP -- As you say, there are two EFI video systems, UGA and GOP. The latter was introduced with EFI 2.x (aka UEFI), IIRC, and AFAIK all UEFI-based systems use GOP. In principle, all EFI 1.x systems should use UGA; however, Apple (which still uses EFI 1.x, even in its most recent products) has ported UGA to its EFI, so some (but not all) Macs have EFI 1.x with GOP. There may be other oddball exceptions. As grawity says, this distinction is important at the firmware level, but not really at the OS level, at least not AFAIK.
- Linux framebuffer devices -- Whether it's UGA or GOP, the firmware gives the OS access to its video hardware, which Linux exposes via a framebuffer device -- specifically,
efifb. On EFI-based systems, this is often the basis for text-mode operation (if you don't start X or if you hit Ctrl+Alt+F1 through Ctrl+Alt+F6). OTOH, there are also framebuffer devices provided by some kernel drivers for specific video chipsets, so you might not end up using the efifb device. I don't know offhand if there are any differences in the way UGA and GOP present themselves to the OS. Certainly I know of no differences at a higher level, like commands you'd use in Linux.
- X Window System drivers -- X drivers can rely on kernel video drivers or be basically independent of them. In most cases, you use an X driver that's written for a specific video chipset (ATI, Nvidia, Intel, etc.), and these don't work through the firmware. Thus, these drivers should not be affected by UGA vs. GOP (or even BIOS vs. EFI, although there are some caveats about that). That said, there is an X framebuffer driver that will work via whatever framebuffer device is active, including the
efifb device. Thus, you could be driving a display via the EFI's UGA or GOP modes. This is definitely a sub-optimal way to do it, though, because the framebuffer drivers tend to be slow. Modern windowing environments, including Ubuntu's Unity, are increasingly relying on video acceleration features that aren't accessible through a framebuffer.
You can see some of this at work by examining the kernel ring buffer via dmesg, as in:
$ dmesg | grep fb
[ 0.625015] efifb: probing for efifb
[ 0.625207] efifb: framebuffer at 0xc0000000, mapped to 0xffffc90010880000, using 3072k, total 3072k
[ 0.625208] efifb: mode is 1024x768x32, linelength=4096, pages=1
[ 0.625209] efifb: scrolling: redraw
[ 0.625210] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 0.627994] fb0: EFI VGA frame buffer device
[ 6.086695] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver
[ 6.689526] [drm] fb mappable at 0xC1488000
[ 6.689531] [drm] fb depth is 24
[ 6.689610] fbcon: radeondrmfb (fb0) is primary device
[ 6.804904] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
This example shows a number of framebuffer-related messages on a system with an AMD/ATI GPU. You'll note there's no mention of UGA vs. GOP, but the efifb device is referenced, as is fbcon (the framebuffer console) and radeondrmfb (the framebuffer device for ATI/AMD Radeon devices). The removing generic driver message denotes a handoff from the efifb driver to the radeondrmfb driver. You can also examine /var/log/Xorg.0.log for messages related to the X server. In the case of my system, these are less interesting, but if you're having problems with X starting up, Xorg.0.log may be of more interest to you.
One more point: When asking for help on hardware issues, it's generally important that you specify what your hardware is -- "a discrete graphics adapter" is insufficiently specific when soliciting help on your video problem. For that matter, it's not clear what your problem is -- or are you simply looking for information on how it all fits together so as to further your understanding?
