API Innovision to surpas DX

[EyalBarlev]

Hello.
I would like to offer a new , more global , more robust API fit for a programmable pipeline.

The API shall concentrate on two sections:
1. Declarations of shader programs.
2. Creation of Pipeline.

1. In order to declare/use shaders there will be only one command. For instance , should I like to create a vertex shader I would call : SetShader(int nShader,int nProgID). Which means, set a shader to be the active shader, nShader will be an enum (1= Hull Sgader [see dx11 to understand],2= Domain Shader, 3= VS, 4 = GS, 5 = PS[Fragment Shader in GL]) This method will add the flexibility of further shader additions to the pipe. A Point to think about.

2. Totally new innovision - Have the user change the pipe functionality with chaining the units. A command to push shaders down the pipe so that the pipe will be built in the most flexible way one could ever want : for instance : Pipe.Push(VS); Pipe.Push(GS); Pipe.Push(PS) will set a drawing pipe of VS->GS->PS. If, at any other stage of time , other uints (Today it is hull and domain, and who knows what shall be next), shall be added to the pipe - all the API will need is a change in the enumeration of units. The management of the pipe can be vector like (See STL::vector) for that and one may create pipes to fit his/her own needs (with and without shaders) and toggle between them in a command like SetActivePipe (PipeID).

[Ilian Dinev]

Want it or not, the pipeline is there fixed in hardware, and it doesn't look useful to rearrange its functionality and flow.
How is your proposition any better than glBindProgramARB(target,name) ?

[Korval]

innovision

What is that?

[V-man]

2. Totally new innovision - Have the user change the pipe functionality with chaining the units. A command to push shaders down the pipe so that the pipe will be built in the most flexible way one could ever want : for instance : Pipe.Push(VS); Pipe.Push(GS); Pipe.Push(PS) will set a drawing pipe of VS->GS->PS. If, at any other stage of time , other uints (Today it is hull and domain, and who knows what shall be next), shall be added to the pipe - all the API will need is a change in the enumeration of units. The management of the pipe can be vector like (See STL::vector) for that and one may create pipes to fit his/her own needs (with and without shaders) and toggle between them in a command like SetActivePipe (PipeID).

What happens if I do Pipe.Push(PS); Pipe.Push(GS); Pipe.Push(VS)

The management of the pipe can be vector like (See STL::vector)?
Sounds like you don't know enough about the subject.

[Groovounet]

1: What about linking? And I don't really see the point.

2: For defered shading I could be great to do: VS->FS->FS but it's a stream so maybe with tiled based GPU (PowerVR SGX or ARM Mali) this could be close to possible but it seams that Microsoft just dont care about any tiled rendering ideas. Except for early Z-culling, I didn't see any interest in this by nVidia either ATI... I don't really understand why.

The way you present this is a bit saly but I do think that more flexibility on the pipeline is going to happen (probably not soon...) and the output stream is a second step for this. The first step was unified architechture.

[Zengar]

Use OpenCL if you need flexibility For 99% of 3d graphics, current pipeline is jut ok. Don't forget that each stage operates on a different level, with primitive setup, rasterization in between.

[EyalBarlev]

For Ilan : I know the pipeline is fixed Hardware. Yet if you will check it out you will see that the longer the time , the flexible everything becomes. Intel's Larabee will be able to do it all in Hardware, When and if this one succeeds Don't you think the competition will learn ? glBindProbgramARB is sufficient for this case if the target could be any shader. The point is the API should be as less fixed-pipe as possible and as flexible as possible. This will make OpenGL really Open and Agile when new units and shaders are needed to be added along the pipe.

[EyalBarlev]

Korval : innovation , sorry for the spelling mistake, was written in a flash of thought. I am even more sorry that you chose to refer to a spelling mistake rather than the contents

[EyalBarlev]

V-Man : You are correct here , of course there are things to be taken into consideration , like a pipe which could not exist. I must say , however , that this is an Idea, I am not an ARB member who has the time to sit down and write the spec. I plant the seed (My Idea) and let it grow. Should it grow to a beutiful tree, I would be very happy.

[V-man]

2: For defered shading I could be great to do: VS->FS->FS but it's a stream so maybe with tiled based GPU (PowerVR SGX or ARM Mali) this could be close to possible but it seams that Microsoft just dont care about any tiled rendering ideas. Except for early Z-culling, I didn't see any interest in this by nVidia either ATI... I don't really understand why.

Are you saying because of the GPUs FS length limits, I would have to write 2 FS? Why can't I write one huge FS and the driver/GPU takes care of the breaking down for me?
This is an old idea. ATI called it the F-buffer. Somehow it died.