public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Kendall Bennett" <KendallB@scitechsoft.com>
To: Tomas Carnecky <tom@dbservice.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: my opinion about VGA devices
Date: Wed, 20 Oct 2004 10:27:08 -0700	[thread overview]
Message-ID: <41763D7C.26451.1B52EDE7@localhost> (raw)
In-Reply-To: <417590F3.1070807@dbservice.com>

Tomas Carnecky <tom@dbservice.com> wrote:

> I don't like the framebuffer devices or even the DRI drivers
> because: most applications use a 'high-level' API for rendering
> (OpenGL). These 'high-level commands' are translated to
> 'intermediate commands' (framebuffer/DRI ioctl calls etc.) before
> being send to the card as 'low-level commands'. Why this
> intermediate layer? 

I am not sure what you are trying to propose here, but really you should 
go back and read up on how graphics device drivers work, more 
specifically DRI. If you do that, it will be clear that DRI drivers are 
the internal 'meat' implementation for OpenGL on Linux. DRI is not an 
intermediate layer that can be eliminated at the swish of your hand and 
instantly get more performance! OpenGL drivers on Linux using DRI build 
up packets of 3D commands to be send to the hardware in *user mode* into 
DMA buffers. Then a command is sent to the kernel driver to start sending 
the data to the hardware using DMA. The overhead of the ioctl's to the 
/kernel to start the DMA packets is not very high (although IMHO this 
could all be moved into user space also, but that is a different story).

As for the framebuffer console, it exists purely to get high resolution 
text consoles working with basic graphics capabilities. It was never 
intended to be a complete graphics environment, but just the console that 
can be used in graphics modes. The original versions of the framebuffer 
console code were developed not for x86 machines but for non-x86 machines 
that did not have any VGA capabilities at all (ie: Mac's). For Linux to 
work on such machines, the console needed to be able to output text in 
graphics modes since that is what the machines booted in. Once this was 
done for non-x86 boxes, it was realised this would be a 'cool' feature 
for x86 machines for two reasons. 1 - you get a nice high resolution text 
console, way better than VGA text mode and, 2 - you can display the cool 
penguin logo ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



  parent reply	other threads:[~2004-10-20 17:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-19 22:10 my opinion about VGA devices Tomas Carnecky
2004-10-20 11:18 ` Oliver Neukum
2004-10-20 12:31   ` Tomas Carnecky
2004-10-20 12:56     ` Richard B. Johnson
2004-10-20 14:14       ` Tomas Carnecky
2004-10-20 14:34         ` Richard B. Johnson
2004-10-20 15:01           ` Tomas Carnecky
2004-10-20 16:58             ` Matthew Garrett
     [not found]             ` <4178F276.2040501@globalintech.pl>
2004-10-22 11:58               ` Tomas carnecky
2004-10-22 19:13         ` Geert Uytterhoeven
2004-10-20 20:16     ` Oliver Neukum
2004-10-20 17:27 ` Kendall Bennett [this message]
2004-10-22  8:29   ` Helge Hafting
  -- strict thread matches above, loose matches on Subject: below --
2004-10-19 18:51 Tomas Carnecky
2004-10-23 16:11 ` Blizbor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41763D7C.26451.1B52EDE7@localhost \
    --to=kendallb@scitechsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tom@dbservice.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox