Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weep for Graphics Programming

adriansampson.net

Post reply on HN
Print view View original

131–140 of 162 posts

Re: Weep for Graphics Programming

#131

Post by angersock »

vitd wrote: post #128
Impossible wrote: post #124

Earlier quoted context omitted.

I agree that Unity3D is overkill for many use cases, although its not many steps to get something that looks roughly like a fixed function OpenGL 1.x and GLUT application working for quick, code only prototypes, so I'm curious what you think is a lot of bullshit. I find that Processing has less boilerplate and more functionality than oldschool OpenGL + GLUT but it gets dismissed by a lot of people because its seen as…

Here are things that made learning OpenGL extremely painful for me: - I came from doing graphics on the CPU where you were often handed a buffer of ARGB pixels and did whatever the heck you wanted to them. You could call OS or library routines to draw simple 2D shapes, text, or images, or you could write directly to the buffer if you were generating a pattern or writing a ray tracer. Understanding textures, framebuff…

I don't mean to sound dismissive, but a lot of what you just mentioned is because you are trying to use OpenGL in a way it wasn't intended.

OGL is meant for 3D work--if you want a framebuffer, an SDL_Surface or some native GUI element is probably a better fit for manual CPU hackery. The reason you find it so uncomfortable is that you are trying to use a refinery to bake a waffle. Textures, framebuffers, and polygons are all kinda central to how 3D graphics (and thus OGL) work--they require some work to understand, but it's not wasted work, if you are doing 3D pipeline stuff.

If you're trying to do simple operations, you probably shouldn't be using OGL directly. For debugging, RenderMonkey was quite a good tool.

Lacking modern language features means keeping a clean C ABI is easier. Having #define's means that there is little work to make sure that any language can invoke different things. Using enums, or even better strongly-typed/templated arguments ala C++, would harm that portability.

The many variants on the APIs are actually quite useful under certain circumstances, and it is always pretty clear how they are used (and again, remember that this is meant for a C ABI).

~

I agree that a simpler environment (like Processing, mentioned above) would be helpful. That said, OGL is hardly bad for the reasons you listed.

Re: Weep for Graphics Programming

#132

Post by eropple »

chongli wrote: post #100
eropple wrote: post #96

Earlier quoted context omitted.

The cost of making a chip anybody wants to use is not $30,000, though. nVidia gets my money because their GPU technology is good enough to, at a reasonable price point, do absolutely anything I'm likely to encounter in the next 3-5 years. You're fighting against significant economies of scale as well as a significant technical deficit. Don't get me wrong: it would be awesome if this existed. But I think that, like RI…

I agree that you're not soon likely to replace your shiny $400 Nvidia graphics card with something designed by a bunch of students and faculty at Berkeley. However, what about your phone? If you watch Prof Patterson's talk, you'll be astounded at what they've been able to do with modern tools and a small team of students. Now think of some larger, slightly-more funded teams such as LowRISC[0] and you begin to see the…

"It's open" is not and has never been an effective selling point for consumer products, and it seems that you're effectively trying to sell these things to consumers. "It's open and is better is," and in my experience that rarely exists (again, for consumer products). If it is as easy as you posit (and this isn't my field, I know a little about CPUs and GPUs but mobile isn't really relevant to me), then what's stopping a company with significant talent and cash reserves can appropriate the same approaches and lap you with their closed tech? I don't see how you're not going to have to offer an inferior good at superior-good prices.

Technically speaking, if anything, phones strike me as a harder place to enter, due to the limitations on power budget and the significant premium on marginal performance. I'm not saying it can't be built--I'm saying, who would both want it and not benefit from business-as-usual, closed development?

Re: Weep for Graphics Programming

#133

Post by angersock »

xigency wrote: post #123
angersock wrote: post #102

Earlier quoted context omitted.

The beginner needs to rise to the task. GLSL isn't complex at all , least of all because its problem domain is basically pure math. It should take less than an afternoon to understand how to write a shader if they have any familiarity with math. If they don't know math, they shouldn't be doing shader programming until they learn .

Writing a fixed function shader is to learning graphics programming what writing a Makefile is to learning C++. I'm not saying it's not important, or not important in the long run, but what introductory programming book would start out showing how to use a linker instead of how to write a program? In this case things are compounded by the fact that there is no linker, which means the programmer has to shuffle around…

I disagree that it's inappropriate for beginners, and comparing it to a build system is incorrect.

Shaders are a step in the pipeline. Beginners should be learning the pipeline:

1. Geometry is instantiated and draw parameters set.

2. Geometry vertices are transformed by a vertex shader.

3. Transformed vertices in primitive are used to sample across its geometry, producing pixel fragments.

4. Pixel fragments are transformed by a fragment shader.

5. Transformed fragments are written to a framebuffer.

That's the whole thing, and GLSL neatly handles 2-4. Step 1 is a kinda pain in the ass, but not terrible. Step 5 is usually simple, but no worse than 1. We shouldn't be protecting users from dealing with the (simple) facts of life in a graphics pipeline.

As for Javacsript not having multi-line strings...that's hardly the fault of WebGL, and honestly the simplicity of passing around strings means that as the language gets more interesting support (for interpolations and whatever) the API will be unaffected.

Re: Weep for Graphics Programming

#134

Post by datenwolf »

xigency wrote: post #123
angersock wrote: post #102

Earlier quoted context omitted.

The beginner needs to rise to the task. GLSL isn't complex at all , least of all because its problem domain is basically pure math. It should take less than an afternoon to understand how to write a shader if they have any familiarity with math. If they don't know math, they shouldn't be doing shader programming until they learn .

Writing a fixed function shader is to learning graphics programming what writing a Makefile is to learning C++. I'm not saying it's not important, or not important in the long run, but what introductory programming book would start out showing how to use a linker instead of how to write a program? In this case things are compounded by the fact that there is no linker, which means the programmer has to shuffle around…

> but what introductory programming book would start out showing how to use a linker instead of how to write a program?

A good one!

Just take a glance over at StackOverflow and consider how many questions there essentially boil down to lack of understanding how the pieces in the compiler toolchain fit together:

http://lmgtfy.com/?q=stackoverflow.com%20undefined%20referen...

In workshop class a teacher will also start with explaining how to properly handle a tool before showing how to apply said tool to a problem.

Re: Weep for Graphics Programming

#135

Post by DonHopkins »

DonHopkins wrote: post #104

DreemGL [1] [2] addresses these problems by compiling JavaScript code into shaders. "DreemGL is an open-source multi-screen prototyping framework for mediated environments, with a visual editor and shader styling for webGL and DALi runtimes written in JavaScript." [3] [1] https://github.com/dreemproject/dreemgl [2] http://docs.dreemproject.org/docs/api/index.html#!/guide/dre... [3] https://dreemproject.org/

Here's a talk about the nuts and bolts of how DreemGL compiles JavaScript into shaders:

https://youtu.be/L-apMRjlBOM?t=12m6s

Re: Weep for Graphics Programming

#136

Post by robbies »

xigency wrote: post #127
robbies wrote: post #90

I think the author has good intentions (don't we all), but I don't think he understands enough about graphics programming to make some of the proclamations/requests in the article. Not that I blame him...it's hard to get an understanding of GPU programming outside the scope of a game dev or IHV. > To define an object’s appearance in a 3D scene, real-time graphics applications use shaders... Eh, the shaders are just a…

"Eh, I don't think I want a common programming model across CPUs and GPUs. They are fundamentally different machines, and I don't think it makes sense to try to lump them together." Well, except for APU's, which I think is an unstated target for this discussion. Or on-board graphics chips. In these cases, there is almost certainly extra work being done, regardless of your programming philosophy.

I'd actually argue that not that much changes, except APUs mean you don't have to worry about different memory pools, and moving stuff across the bus. That's a whole other problem, as far as streaming data management. If we're just talking about GPU programming, in my experience, even APUs still feel like two separate processors instead of some...combined thing.

Re: Weep for Graphics Programming

#137

Post by kbutler »

vvanders wrote: post #87
continuational wrote: post #86

Earlier quoted context omitted.

But still, just one page of code? Ideally, drawing a quad should be a one-liner.

If you want to use a higher-level framework then one-liner might make sense. For OpenGL you want control over state changes, uniforms and a slew of other things. Otherwise your performance/control will suffer significantly. Look at the things I listed there, that's the bare minimum you need to do the above, and fitting that in one page is pretty impressive.

OpenGL is set up to optimize for all those things, instead of optimizing for the learner/simple case.

It's definitely a valid approach, but it means for simple cases, you're copy & pasting a lot of boilerplate for performance, control, and a slew of other things you don't need.

You have to learn/paste a lot before you get a little reward.

Re: Weep for Graphics Programming

#138

Post by xigency »

datenwolf wrote: post #134
xigency wrote: post #123

Earlier quoted context omitted.

Writing a fixed function shader is to learning graphics programming what writing a Makefile is to learning C++. I'm not saying it's not important, or not important in the long run, but what introductory programming book would start out showing how to use a linker instead of how to write a program? In this case things are compounded by the fact that there is no linker, which means the programmer has to shuffle around…

> but what introductory programming book would start out showing how to use a linker instead of how to write a program? A good one! Just take a glance over at StackOverflow and consider how many questions there essentially boil down to lack of understanding how the pieces in the compiler toolchain fit together: http://lmgtfy.com/?q=stackoverflow.com%20undefined%20referen... In workshop class a teacher will also start…

You're skirting around the issue.

The original comment was - "When writing my first OpenGL code, I was stunned by the amount of boilerplate required."

Your response was - "the amount of boilerplate required ... is minimal."

It's clearly not minimal because we've outlined ways it could be reduced. Your counter-example of writing larger programs doesn't solve the issue of drawing a single triangle. Don't confuse a local minima for a global minima and don't confuse your experience with every noobie's experience.

Although I would say it looks minimal compared to an early D3D application.

Re: Weep for Graphics Programming

#139

Post by xigency »

angersock wrote: post #133
xigency wrote: post #123

Earlier quoted context omitted.

Writing a fixed function shader is to learning graphics programming what writing a Makefile is to learning C++. I'm not saying it's not important, or not important in the long run, but what introductory programming book would start out showing how to use a linker instead of how to write a program? In this case things are compounded by the fact that there is no linker, which means the programmer has to shuffle around…

I disagree that it's inappropriate for beginners, and comparing it to a build system is incorrect. Shaders are a step in the pipeline. Beginners should be learning the pipeline: 1. Geometry is instantiated and draw parameters set. 2. Geometry vertices are transformed by a vertex shader. 3. Transformed vertices in primitive are used to sample across its geometry, producing pixel fragments. 4. Pixel fragments are trans…

It's a stretch to say that GLSL shaders are broken, since they are functional and every OpenGL application uses them, but it's hard to say that they are implemented in a logical way as they are now, especially at a topical glance.

Re: Weep for Graphics Programming

#140

Post by khedoros »

vitd wrote: post #128
Impossible wrote: post #124

Earlier quoted context omitted.

I agree that Unity3D is overkill for many use cases, although its not many steps to get something that looks roughly like a fixed function OpenGL 1.x and GLUT application working for quick, code only prototypes, so I'm curious what you think is a lot of bullshit. I find that Processing has less boilerplate and more functionality than oldschool OpenGL + GLUT but it gets dismissed by a lot of people because its seen as…

Here are things that made learning OpenGL extremely painful for me: - I came from doing graphics on the CPU where you were often handed a buffer of ARGB pixels and did whatever the heck you wanted to them. You could call OS or library routines to draw simple 2D shapes, text, or images, or you could write directly to the buffer if you were generating a pattern or writing a ray tracer. Understanding textures, framebuff…

Use SDL or SFML. They both let you write RGBA into a buffer and throw it onto the screen. I think they both handle hardware stretching and scaling, too.

> Having 20 different versions of each function for every combination of data type and size.

Welcome to C land.

> I'm sure it's all related to how SGI machines worked in the early 90s and how graphics hardware evolved since then

Fixed pipeline would be, I suppose. The programmable pipeline is what you get when you have GL 1.x users reinvent the API. It's great for graphics experts and a barrier for everyone else.

Post reply on HN