Sign in to follow this  
psycoding

3d accelleration without ogl / d3d

Recommended Posts

It's simple. You simply have to write code to interface with the display driver (separate code for each type of display hardware on the market, of course), using the non-publically-available specifications (or even the publically-available ones) for the hardware.

Actually, come to think of it, that's not easy at all.

Really, why would you ever want to do this? The APIs used to interface with graphics hardware exist for a very good reason - no sane person would want to write that much device-specific code.

If your rationale is "I want my app to be faster" I suggest maybe taking a step back and asking yourself if you think you can code a better, faster interface to the hardware than the hundreds of people who have intimate access to their specifications, and a ton of resources.

Since every game on the market uses either D3D or OpenGL, and they seem to run fine, the speed of the API is obviously not an issue.

If it's for some...other...reason, might I suggest taking the "just say no" option?

Share this post


Link to post
Share on other sites
This IS after all, one of the key reasons gaming on windows managed to take over DOS in the first place (although it was probably inevitable eventually and is hard to see any other outcome now - but isn't that always the case?). Homebrewing code for every piece of graphics hardware on the market was such a pain 15 years ago when there were like 10-20 different specifications (at least the popular ones... I'm sure there were many more). I can only imagine trying to write for the 100s of graphics cards we have today... and the fact that no longer are we just trying to write to this new-fangled 16 bit or 32 bit display with resolutions > 320x240, but now we're trying to do massive amounts of calculations and 2d/3d rendering.

Why do you want to do this anyway? (just curious)

Cheers
-Scott

Share this post


Link to post
Share on other sites
If you don't need such hw access for graphic, maybe you could look into CUDA and OpenCL (I think ATI has something similar, don't remember its name right now). These are api to use GPU as general pourpose processors, so perhaps what you need is what they offer.

I think that you will never directly access the HW, without using an upperlevel api: there are simply to many devices aout there (at least 4 generations for each manufacturer, perhaps less for intel, several different versions in each generation).

Share this post


Link to post
Share on other sites
Quote:
Original post by cignox1
If you don't need such hw access for graphic, maybe you could look into CUDA and OpenCL (I think ATI has something similar, don't remember its name right now). These are api to use GPU as general pourpose processors, so perhaps what you need is what they offer.

ATI's was called Close To Metal (CTM), now AMD has the Stream SDK. Which among other things, allows you to do GPGPU computing.

Share this post


Link to post
Share on other sites
I'm writing my own 3d engine, mainly for my radiosity project.
And I want to write everything on my own, not using any other code than mine, except the framebuffer... and if it was possible, I'd also like to do this on my own.
Now where I'm finished with mainly most optimizations, I have to see that
using it in my radiosity project is just painful slow with just a very simple scene even though in triangle rendering my tmapper surprisingly beats ogl when many small triangles are used, and that's what radiosity is all about, many many small triangles.. Because of this I wanted to get HW access, because using ogl/d3d is no alternative for me...
so something like it's mentioned above, gpu as general purpose processor is exactly what i searched for.

I see it as an exercise and it's very interesting.
I just hate using black boxed code, even if it's fast.

Share this post


Link to post
Share on other sites
Quote:
Original post by psycoding
Quote:
and if it was possible, I'd also like to do this on my own.


this refers to the framebuffer, and the window(s) stuff
You can't. You're running on an operating system, you need to go through the OS to get to the hardware. And the only way to the hardware from the OS, is through drivers. And since there's only drivers for OpenGL or Direct3D, you have to use one or the other.

If you just want to put pixels onto the screen, you could write your own OS, and use interrupts to print pixels in mode 13h, but that still won't give you any hardware acceleration.

What you're trying to do is the equivalent of flying halfway around the world without wanting to use an aircraft.

Share this post


Link to post
Share on other sites
Uhm, will you also write your own BIOS and a Bootmanager, plus device drivers for your harddisk, both of them? What is with microcode? Don't forget to support the hardware of your teachers.

Basically I can understand you, but then where is the limit? If you sanely want to show your nuts, then take a frameuffer, and write the rendering code in your application onto it (canonical software rendering).

But also look at OpenCL + CUDA, as cignox mentioned :)

Share this post


Link to post
Share on other sites
All you need to do is write a kernel module that can initialize the card and exports a suitable API to userspace. This API will need to provide things like creating objects in the case of Nvidia, or whatever the equivalent is for AMD and Intel cards, memory management, and submitting command buffers. Then on the userspace side you'll have to use that API to create a suitable context and then you can start filling command buffers and dispatching them to do what you want.

So basically you'll have to write an entire driver. Good luck.

Share this post


Link to post
Share on other sites
Quote:
Original post by outRider
All you need to do is write a kernel module that can initialize the card and exports a suitable API to userspace. This API will need to provide things like creating objects in the case of Nvidia, or whatever the equivalent is for AMD and Intel cards, memory management, and submitting command buffers. Then on the userspace side you'll have to use that API to create a suitable context and then you can start filling command buffers and dispatching them to do what you want.

So basically you'll have to write an entire driver. Good luck.


"All you need to do" heh. Anyway, that's great and all, but it's not like there will have to be a driver per manufacturer (1 for intel, 1 for nVidia, 1 for AMDTI). More like, 1 per card that they came out with... and that's a lot of cards. Even if the OP managed to write some super-optimized radiosity renderer going directly to hardware by way of a self-written kernel-mode driver, it'll work with and only with the card he wrote it for, and not for the other gazillion billion million gfx cards out there. This is an unarguable reason as to why he should trust the black box of OpenGL or Direct3d - unless of course he only wants it to work on his gfx card.

... Not to mention the fact that the driver written by the same company that made the gfx card (note the singular form of that word "card") will probably do things safer and better anyway... but there's always the slight chance (anything's possible) that the OP could possibly know the card and its quirks better than they do...

Cheers
-Scott

Share this post


Link to post
Share on other sites
The company that build videocards hardware also build the code (aka drivers) for give full access to their hardware via directx and opengl; and they code in a way that the hardware is used in the fastest and best way posible; after all they are selling this kind hardware for videogarmers people that want to have high end frame rate with high end features...

So, if you code in directx or opengl and your app perfomance is poor, it is very unlikely the fault is from the programmers that code the drivers or from the programmers that code directx/opengl; it is most likely you are not using the API in the way thats gives best result; there are a lot docs that explain guidelines for get best result from those APIs

Share this post


Link to post
Share on other sites
Quote:
Original post by popsoftheyear
Quote:
Original post by outRider
All you need to do is write a kernel module that can initialize the card and exports a suitable API to userspace. This API will need to provide things like creating objects in the case of Nvidia, or whatever the equivalent is for AMD and Intel cards, memory management, and submitting command buffers. Then on the userspace side you'll have to use that API to create a suitable context and then you can start filling command buffers and dispatching them to do what you want.

So basically you'll have to write an entire driver. Good luck.


"All you need to do" heh. Anyway, that's great and all, but it's not like there will have to be a driver per manufacturer (1 for intel, 1 for nVidia, 1 for AMDTI). More like, 1 per card that they came out with... and that's a lot of cards. Even if the OP managed to write some super-optimized radiosity renderer going directly to hardware by way of a self-written kernel-mode driver, it'll work with and only with the card he wrote it for, and not for the other gazillion billion million gfx cards out there. This is an unarguable reason as to why he should trust the black box of OpenGL or Direct3d - unless of course he only wants it to work on his gfx card.

... Not to mention the fact that the driver written by the same company that made the gfx card (note the singular form of that word "card") will probably do things safer and better anyway... but there's always the slight chance (anything's possible) that the OP could possibly know the card and its quirks better than they do...

Cheers
-Scott


He asked a direct question, I gave him a direct answer. He didn't ask whether or not it was a good idea, he can hopefully decide that for himself if he knows basically what's involved, although if you read what I wrote carefully you'll see I don't think it's an easy task at all.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this