On 6/14/2012 7:32 PM, Rod Pemberton wrote:
@gmail.com> wrote in message
> On Thursday, June 14, 2012 3:55:51 PM UTC+2, Peter Cheung wrote:
>> ? 2012?6?5????UTC+8??6?34?31?,Joe??:
>>>> I'm Building an Operating System from Scatch, How would
>>>> I go about Implementing OpenGL?
>>> OpenGL library is big and i believe some functions in it are
>>> hardware dependent. Tell me when you know the answer. thanks
>> Obvious troll.
>> If you are in the need of implementing OpenGL in your OS
>> you would not ask anything ;-)
> I agree with Peter. Likely, there is much video card and hardware dependent
> a) I.e., it seems like a large task to start with, so why would Joe want to
> do this?
> I'd think at the start of writing an OS one would use the BIOS video calls.
> Get a copy of RBIL (Ralf Brown's Interrupt List) for the interrupts.
> b) But, why wouldn't Joe ask? Maybe, he just needs an idea of where to
> start. Or, maybe his skill set is quite advanced and he can do it with some
> I took his question to mean he wants to implement his own OpenGL, and not
> use OpenGL's OpenGL. He'd start by getting a video card that he can
> program, i.e., that has an open hardware interface specification. Or, he'd
> use VGA since it's well documented. Or, he'd call VESA/SVGA video BIOS
> functions and their trap I/O ports using v86 mode. That would allow him to
> determine the video card register set and/or create his own routines. Then,
> he'd get a list of the functions in various OpenGL specifications. Then,
> he'd start writing those functions, from the earliest specification to the
> current specification, one function at a time. IMO, starting with VGA is
> probably a good idea. He can update to SVGA or specific hardware later.
> This task seems astronomical for just starting an OS
the thing is, the best a person can really do with VESA / SVGA / ...
stuff would essentially amount to a software-renderer implementation of
OpenGL, which would be very slow (even with good code).
for a more "proper" OpenGL variety (IOW: one which isn't dead slow),
this would get very involved with the particular piece of video hardware
(targeting the particular HW ISA used by the GPU, ...), and modern video
HW drivers actually have a fair amount in common with compilers (both
for compiling the shader programs, and for mapping much of OpenGL
functionality itself to the GPU's ISA).
similarly, the (modern) OpenGL library often isn't really a library in
the traditional sense (at least on Windows), but more of a wrapper
interface which passes most of this stuff over to the video-card driver
(which implements the OpenGL API), which may then put it into GPU
memory, pass control of it over to shader programs, ...
granted, yes, one can implement a software renderer based driver, and
then use VESA or similar to put it on screen, just the performance wont
be very good.