dri-devel

gistfile1.txt

19:24 < glennk> imirkin, i'm not sure i entirely understand what you mean by accessing other invocation's outputs
19:24 < imirkin_> glennk: if you have a non-patch output, say 'x', it'll be declared as "out int x[]"
19:25 < imirkin_> you're supposed to write to it with x[gl_InvocationID] = ...
19:25 < glennk> ok, so this is the no hull shader case?
19:25 < imirkin_> however you can also read from it, e.g. foo = x[0]
19:25 < imirkin_> i can never remember which is the hull and which is domain
19:25 < imirkin_> this is for the tess control shader
19:25 < glennk> thats the hull shader afaik
19:25 < imirkin_> the one that gets inputs from vertex shader, outputs to tess eval shader
19:26 < imirkin_> has patch inputs and outputs (although the output patch size can be different than input patch size)
19:26 < glennk> outputs to fixed function primitive gen, then to eval shader
19:27 < imirkin_> http://cgit.freedesktop.org/piglit/tree/tests/spec/arb_tessellation_shader/execution/barrier.shader_test
19:27 < glennk> the inputs to that stage are buffered by the hardware so everything is available there, and likewise the next stage isn't started until it gets enough outputs
19:29 < imirkin_> right
19:29 < glennk> ah, the barrier there is obviously needed to get any sort of valid data for whats been written prior to that
19:29 < imirkin_> right :)
19:29 -!- maelcum [~horst@188.111.54.34] has quit [Quit: Konversation terminated!]
19:30 < glennk> one way that could be implemented is running two shader stages after another
19:30 < imirkin_> i believe D3D11 solves this by have multiple sub-stages
19:30 < imirkin_> but there's nothing preventing multiple barriers in a single shader in GL
19:31 < glennk> well, r600 can probably do either, i'm not entirely sure exactly how its stages map to GL yet though
19:31 < imirkin_> well, with nvc0, there's a barrier instruction which handles all this quite nicely :)
19:31 < imirkin_> and you can write to shader outputs, and you can read other shaders' outputs using the "load" instruction
19:31 < glennk> but its inputs/outputs are basically just memory so it can do arbitrary reads/writes, and just use a barrier between
19:31 < imirkin_> ( + a special flag)
19:32 < imirkin_> er, other *invocations's* outputs
19:32 < mareko> glennk: VS->TSC->TES in GL are LS->HS->VS in hw
19:32 < glennk> the outputs from the eval shader can be fed to a special ring buffer if they are to be consumed by a geometry shader though - in that case reading back the values won't work
19:33 < glennk> mareko, i think ES pops in there somewhere too
19:34 -!- xexaxo [~xexaxo@cpc6-nott17-2-0-cust458.12-2.cable.virginm.net] has quit [Read error: Connection reset by peer]
19:35 -!- xexaxo [~xexaxo@cpc6-nott17-2-0-cust458.12-2.cable.virginm.net] has joined #dri-devel
19:35 < imirkin_> glennk: well, TES only generates one value per invocation and can't read any info from other invocations
19:35 < imirkin_> s/value/vertex/
19:36 < imirkin_> and then there's a primitive assembly stage which converts all the vertices into triangles
19:36 < imirkin_> and feeds them to geometry shader
19:37 < mareko> glennk: if there's GS, then VS->TCS->TES->GS in GL are LS->HS->ES->GS->VS
19:38 -!- tgall_foo [~tgall@linaro/tgall-foo] has quit [Quit: This computer has gone to sleep]
19:39 < glennk> VS being last is really weird, i would expect it to be at the top...
19:40 -!- okias [~okias@5-80-207-85.adsl-llu.bluetone.cz] has quit [Quit: Konversation terminated!]
19:41 -!- okias [~okias@5-80-207-85.adsl-llu.bluetone.cz] has joined #dri-devel
19:42 < mareko> glennk: LS outputs to LDS, ES outputs to export memory, VS outputs to the rasterizer