Why do you keep responding and elaborating to someone, who clearly ignores all of your explanations, refuses to be educated(keeps assuming, that he knows everything better) and keeps posting repetitive, utter nonsense and mumbling? It's obvious, that he's either a troll or a complete dumbass. It's also so clear, that he's not trying to learn API or to produce something. Do you really want threads like this on this forum, especially in suggestions?

I said exactly the same thing in his previous topic about 6 month ago. And now it's the same. A bunch of over-tolerant people trying to educate an obvious troll or extremely dense, ignorant person. And why do you want any of them educated or treated well? Why do you educate in the first place? Maybe you're helping potential developers, because you want OpenGL to be more popular and used in some future projects and to have decent, mature community and support? Do you think he's able to contribute to that? You keep writing thousands of words, keeping attention to this stupid thread, instead of showing ability for good judgment and just saying GTFO in response to ovid ignorance and thickness. It's good, then community shows no tolerance for bullshit, it keeps itself clean and intelligent that way. And if he's actually not a troll, he may review his attitude and try to understand things he's being told over and over. Why don't you just report him for trolling\flaming\flooding on suggestions forum and wait until these threads are (re)moved? And spend your time on someone, who's actually willing to be educated and has any potential.

This is my last post to this thread and as a rule now, I am not going to try to help you LuisAK; you have repeatedly ignored what anyone has said, you have repeated the same statement although multiple contributors have given counter arguments for those statements.

If you really want to suggest functionality to find its way into the hardware here are some tips:

Have a clear way to implement said functionality in a highly parallel fashion

Have a clear notion of what the input and output are. Your request for "draw concave polygons" in no way addresses what the output should be: what are the interpolates, what happens if the line loop defining the polygon is self intersecting.

Be aware of various constraints, i.e. the tradeoff between flexibility and speed; generally speaking more flexible implies slower.

Nothing of what you have suggested (font support or rendering of simple polygons beyond triangles) has done ANY of the above.

Going further, to repeat what mhagain said: OpenGL is a low level API; it is supposed to map naturally and directly to GPU commands. If one looks at GL, one sees essentially that each command is one of the following:

Define data store (be it buffer objects or textures)

Set values of data store directly (i.e. glTexSubImage2D for example)

Set GL state to determine from what data stores to fetch data (binding textures and buffer objects for example)

Set GL state to what data stores to write (framebuffer objects and transform feedback for example)

Set GL state for parameters of fixed functionality (depth test, stencil test, color, depth, stencil masking and blending for example)

To render concave polygons directly is very easy.
Here an example:
This concave polygon is rendered on pixel-level how it could be done by the graphics hardware
as efficient as triangles. Of course, there are a few little aspects in my algorithm, to detect the cross-points.
But in summary its much more efficient than triangulation.

Drawing a picture is not evidence. Anyone can draw a picture of an algorithm. That's not evidence that this algorithm can be implemented in hardware or implemented efficiently in hardware.

Unless you demonstrate an understanding of how this stuff is implemented in hardware, you cannot claim any kind of knowledge of whether this could be implemented reasonably.

And to preempt your linking me to PhysX or some other GPGPU library, let me stop you right there. That's all just executing programs on the GPU. You are not talking about shaders. You are talking about changing the rasterizer. The rasterizer is not done via shaders; it's hard-coded into the GPU.

What you are talking about is the equivalent of wanting to change how the division opcode on a CPU works. The fact that you can make the CPU do amazing things with a good compiler or other system has nothing to do with the feasibility of whatever else you wanted.

Lastly, you continue to miss the important question. Could IHVs implement this? Absolutely. WHY SHOULD THEY?!Nobody except you wants this. This solves a problem that nobody except the most lazy programmers have. Why should IHVs invest precious transistors solving a problem that nobody needs solving? That will be useful for one thousandth of a percent of their customers.

Why should they invest in this rather than anything else they could be doing? Like programmatic blending (rather than the user-heavy image load/store form). And so forth.

Every time you post a response that doesn't address this important question, I will simply repeat the question.