Couple of questions regarding graphics API?

Started by
15 comments, last by Inderpreet Singh 9 years ago
That's fair, and I agree...but depending on the age here we might be damaging an individual.
Could be a middle school genius in the making who hates google...You never know.

Couldn't hurt to encourage a little, instead of "go get smart" then come back and talk to us...unless this is the exclusive club.
Not wasting your time, right...you've chosen to answer the worlds questions and I've chosen to read them.
It's difficult not to want to interact.

Right...I see two threads started. I remember up voting the concise first response in his/her other thread.
Nice work breaking into the playstation mobile market...Might have been able to share something meaningful here...
Advertisement

I can see what you guys are doing and can understand because the OP went straight to consoles and the big boy hardware interface, but are we discouraging the young from creating a software renderer like this and that our dads were fools as well?

Is that what this website is about?

I don't really see how these answers are too discouraging.

Sure, a few are a bit abrasive (like the link to google, and possibly mine too), but most also give actual answers on what steps are needed to do what OP asks to do, and what knowledge is needed.

The problem is only that the steps needed are not something "anyone" can do, unless they have a company, preferably with a solid track record, in their back.

It's also something very few people need to do, since the whole point of APIs on this level is to have as few as possible that is widely standardized. You don't really want to have a graphics API of your own, unless it is for research and learning.

No amount of sugar coating can remove that fact.

There is even tips on hardware to use if OP wants to learn more about the hardware side of graphics (which is a must if you want to write new APIs)

It's not impossible, it's just a long way there, and it is relevant to ask if that route is really what this person want to take, or if there is just a bit confusion on where to go next.

You need to write a userspace driver to support an API. If you really want to, you can start by looking on Mesa which already support various API (OpenGL, opencl, DX9, gbm). It also uses an interface named gallium for some driver, an interface that can be considered an API per se.

The reason that I asked this question is I want to implement a complete new ray tracing rendering engine instead of making a hybrid (DX with ray tracing) rendering engine. So that's why I wanted to know that if I can access the GPU directly(on PC and consoles) instead of going through an API ?

I don't think it is advisable to go any lower than low level DirectX/OpenGL..

The only thing I can think of is probably the source for the open source Linux graphics drivers?

Otherwise look into a software renderer. That's fairly low level. :)

Too many projects; too much time


The reason that I asked this question is I want to implement a complete new ray tracing rendering engine instead of making a hybrid (DX with ray tracing) rendering engine. So that's why I wanted to know that if I can access the GPU directly(on PC and consoles) instead of going through an API ?

You absolutely don't need "direct" access to a GPU in order to write a ray tracing engine. Plenty of people have already written excellent ray tracers and path tracers on top of the current PC API's. You can go ahead an look at the docs for AMD GPU's if you'd like: you'll see very quickly that the majority of command buffer packets and registers are for setting up hardware states related to rasterization. For a ray tracer on a GPU you're just going to be using compute shader functionality, and the PC API's aren't going to hold you back too much in that regard.

@MJP Thanks! Finally I got what I wanted.

This topic is closed to new replies.

Advertisement