Advertisement Jump to content
Sign in to follow this  
fir

shader like graphics programming - ugly

This topic is 1832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I wonder if the opinion that shader way of programming computer

graphics is an ugly one... i must admit that i was not doing it to 

much though (only basic), but i was not doing it much just because

i find it ugly... I would much prefere the oldschool (perpixel) way

of doing computer graphics rasterization or raytracing ..

 

(Though on the other side i can admit that some results done with

shaders are very impressive and quality of graphics in some

games made like that is very high) what are the opinions ;/ ?

 

 

Share this post


Link to post
Share on other sites
Advertisement

If pixel shaders don't work on "per-pixel" basis how do they work?

 

Cheers!

Edited by kauna

Share this post


Link to post
Share on other sites

Shader programming is a bit obtuse to start with, but once it clicks its easy enough. Pixel/Fragment shaders are written "per-pixel" but you have to get your head around the fact that some of the "constants" are different for each pixel, and that that's all happening at the same time. Its a different model of working from old-school, single-threaded rasterizers on a CPU, its much like how programming for a vector unit is a different model from a single-lane CPU, or how programming in a functional language is different from procedural languages.

 

Myself, I've always wanted a shader language based on functional programming. I might just build one someday.

Share this post


Link to post
Share on other sites

Yes, I think you may have a misunderstanding of the programmable pipeline.  It's incredibly powerful.

 

Fragment shaders are per pixel.

 

Read this: http://msdn.microsoft.com/en-us/library/bb205123%28VS.85%29.aspx

 

well so you maybe wrote some draw line routine in fragment shader? : O

does it make sense? ;\

 

(indeed i hav not to much experience with writing shaders

but i doubt it .. Is it really reasonable to speak about drawLine

routine in fragment shader? how it would look like ;\

Share this post


Link to post
Share on other sites

I wouldn't implement a drawLine in a pixel shader.

 

The way this would work is you would create a piece of 3D geometry representing the "line" in 3D positioning.  You could convert the 2D window coordinates to 3D world coordinates, and then render that.  For a shader to work, you need to have geometry that generates pixels that make up your object in screen space.

 

The fragment shader that you have bound during your draw call will only determine what color that pixel ends up being... the 3D geometry is still required.

 

Again, I point you to read the link I posted, and it may be a little more clear.  Before any rendering is done, you generate your Vertex buffers, which uploads all of the vertex locations to the Video card.  Once that data is in there, you can draw all of that geometry with a single function call.  You set your shader to active, then draw the geometry.  That's what executes the shader.

 

Shaders don't represent a "program" like you would normally think of a desktop program.  They're simply a tool to help you deliver high fidelity graphics.

Share this post


Link to post
Share on other sites

What you are suggesting (drawing lines using custom code) is fun, however the reason graphics cards don't work like that these days is because doing it in such a way is very very slow due to the random access to the display surface required. To get the sheer performance required for the graphics expected (and desired) by games these days, the hardware pipeline must be insanely optimised and being able to freely access pixels as you suggest just isn't practical.

 

However, in some ways it is much simpler to achieve the drawing of a line that you give as an example. Rather than draw the individual pixels yourself, you can ask the hardware to draw the line for you and you simply have to implement how each pixel is coloured. This actually separates the shading from the drawing logic and allows you to write specific shading logic independent of the geometry.

 

Rather than 'ugly' I think the current graphics architecture is fairly elegant. Especially when you take into account the amount of design that has gone into making the pipeline so optimised, far beyond what could be accomplished with the arbitrary writes that you seem to wish for (and, I'd wager, you'd like reads to go with those writes? It just isn't efficient for the hardware).

 

n!

Edited by nfactorial

Share this post


Link to post
Share on other sites


If pixel shaders don't work on "per-pixel" basis how do they work?

 

He probably just means that shaders work in the "inverse" way that you would use in general CPU programming.

"oldschool": write code that "figures out colors" and puts colors in the desired pixels

shader: given a pixel, write code that figures out what color it should be

Share this post


Link to post
Share on other sites

Right, Phil.

 

And for the OP, its actually a good point to address -- in an old-school CPU renderer, rasterization and shading were essentially one and the same to get reasonable performance, but both GPUs and modern CPU renderers decouple rasterization from shading.

 

Rasterization is determining pixel coverage of a primitive together with the interpolated state that's necessary input to the shader.

 

Shading is a program that runs per-pixel and turns the interpolated state + constants into a single color.

 

Then there's an additional step where the fragment color can be combined with the existing frame-buffer color in various ways (for e.g. transparency).

Edited by Ravyne

Share this post


Link to post
Share on other sites

 


If pixel shaders don't work on "per-pixel" basis how do they work?

 

He probably just means that shaders work in the "inverse" way that you would use in general CPU programming.

"oldschool": write code that "figures out colors" and puts colors in the desired pixels

shader: given a pixel, write code that figures out what color it should be

 

well really, i do not know, I say that for me, shader-way
graphics programming presents as ugly, unconvenient, constrained  etc - (thats all) - (and i am curious if other shares my  opinion on this or could say something opposite or what, - interested if ppl have some opinion on this ;/
Edited by fir

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!