These are chat archives for bjz/gfx-rs

25th
Jun 2014
Dzmitry Malyshau
@kvark
Jun 25 2014 17:56
@bjz @csherratt thanks for having a look at #21
Dzmitry Malyshau
@kvark
Jun 25 2014 18:06

Could both of you explain what you mean now? :)

@bjz how does having a channel per return type change the interface with the client?
@csherratt something like that?

let load_handle = client.create_program(...);
...
let prog = client.retrieve_program(load_handle);
Chip Collier
@photex
Jun 25 2014 18:35
My suggestion tl;dr: Move the recv into another method that can be called after all the submissions.
Dzmitry Malyshau
@kvark
Jun 25 2014 18:36
@photex how do we enforce the queue order of requests vs receives then?
Chip Collier
@photex
Jun 25 2014 18:36
why would you?
you can't enforce that in either case
one idea though, is to index the submits
if you really need to
I've had to do that to implement a parmap over a vector for instance
but I didn't think that was the nature of these calls
Brendan Zabarauskas
@brendanzab
Jun 25 2014 18:37
@photex no cat! you are boring now :(
Chip Collier
@photex
Jun 25 2014 18:38
haha
I'm zen
Dzmitry Malyshau
@kvark
Jun 25 2014 18:38
cat-zen
Chip Collier
@photex
Jun 25 2014 18:38
I'll draw some ears on it
Brendan Zabarauskas
@brendanzab
Jun 25 2014 18:38
@photex I wan splodey cat again :(
Chip Collier
@photex
Jun 25 2014 18:38
ok ok
lemme find it
brendanzab @bjz is working on a bad presentation
Dzmitry Malyshau
@kvark
Jun 25 2014 18:39
@bjz you've got a rather large scope...
Brendan Zabarauskas
@brendanzab
Jun 25 2014 18:39
aye
dunno if I should redefine it :(
I like the enso on this page though
wish gitter would let me specify an avatar without github
lol
brendanzab @bjz likes seeing lots of cats
Brendan Zabarauskas
@brendanzab
Jun 25 2014 18:40
:cat2: :cat2: :cat2: :cat2: :cat2: :cat2:
sorry for derailing the discussion :smile:
Chip Collier
@photex
Jun 25 2014 18:42
ok splodey is back... no idea when gitter updates it
Dzmitry Malyshau
@kvark
Jun 25 2014 18:47
@photex Your proposal on #21 makes sense too me, but if we go this route, why do we even need a Client struct? The client would just get the duplex stream end to work with (or something that implements Deref<DuplexStream<..>>). That's not as convenient as it is now,.. but would also solve #9 .
Brendan Zabarauskas
@brendanzab
Jun 25 2014 19:10
@photex :heart:
Coraline Sherratt
@removed~csherratt
Jun 25 2014 19:16
@kvark If you let the client enumerate the handle you can avoid the round trip. CreateFoo(unique number, args). Then later when you want to use the handle, UseFoo(same unique handle, args). Since it is in a FIFO the server will see the CreateFoo before the UseFoo and it should work.
The creation of the unique number would need to be transparent to the client. It's just a implementation detail.
Coraline Sherratt
@removed~csherratt
Jun 25 2014 19:26
If the handle in this case was actually just an pointer, the server would not even need to look up anything.
Dzmitry Malyshau
@kvark
Jun 25 2014 19:38
@csherratt What exactly do you mean by "client enumerate the handle"? Overall, I kinda like this solution. There would be no need to wait synchronously for the user. From his perspective, once something is queried for creation, it exists. Our Client would have to make sure everything is loaded by the time it is used. A big question here is whether this checks are going to be any heavy for us to bear (because most of the time Use function is called the resource is already there).
Coraline Sherratt
@removed~csherratt
Jun 25 2014 19:40
What is the content of the handle exactly?
Dzmitry Malyshau
@kvark
Jun 25 2014 19:42
So far the handle is represented as (id, generation) pair (see @photex data.rs). Not sure if we are going to add some custom info to it later on the way (depending on the type)
Coraline Sherratt
@removed~csherratt
Jun 25 2014 19:47
hmm
So when I meant by enumerate the handle is that the client figures out the Id of the handle, it does not have to wait for the server to figure it out.
Not sure of the generation field...
The id can just be bumping an atomic variable.
Dzmitry Malyshau
@kvark
Jun 25 2014 19:56
@csherratt I don't think the figuring out of the ID takes long enough to defer it :) We are talking about deferring program linking, buffer and texture loading, and such. So the user may call Create() and get the unique handle back from Client.
Coraline Sherratt
@removed~csherratt
Jun 25 2014 19:59
Ah that makes more sense.
So if you are doing an async program linking, how do we know if it failed or not?
Dzmitry Malyshau
@kvark
Jun 25 2014 20:07
@csherratt Good question. Here comes the proposal to solve it: error channel. It's a simple one-side channel that will be used to report errors back to the user. The errors are gonna be defined as enum Error {}, and the user is going to be responsible for checking those and make arrangements accordingly. Does that sound good to @bjz @photex ?
Coraline Sherratt
@removed~csherratt
Jun 25 2014 20:12
Is the pipeline stall caused by the user checking an issue worth fixing?
*use waiting on the error result
Dzmitry Malyshau
@kvark
Jun 25 2014 20:16
@csherratt I don't think there is going to be any stall at all. The device will catch the error, report somehow to the renderthread, that one will send the error message to the channel that user receives on. User is free to do it at will, but the pipeline will continue to function and will just ignore all the calls that require broken resources.
Coraline Sherratt
@removed~csherratt
Jun 25 2014 20:19
That makes sense. So there is no harm telling the pipeline to use a resource that is not fully linked yet, worst case all commands after the compilation will be discarded and the user will get a black frame buffer back.
Dzmitry Malyshau
@kvark
Jun 25 2014 20:24
@csherratt That sounds interesting but it's not exactly what I meant. I thought the Client will make sure that any resource that is needed for a call is loaded. So the call will be ignored only if some of the dependencies failed (there but they have finished loading regardless).
Brendan Zabarauskas
@brendanzab
Jun 25 2014 20:44
So do you think it would be too costly to return a Result<> for each fallible message?
Dzmitry Malyshau
@kvark
Jun 25 2014 22:16
@bjz if you want to return Result<>and still load resources asynchronously, then you'd need a function to get the loaded result back. In @csherratt proposal, as I got it, there is no such function. Instead, the pipeline just avoids the use of the resource, and optionally (my proposal) reports the error back to the user via the designated channel.
Chip Collier
@photex
Jun 25 2014 22:29
I'm feeling positive about the designated channel for errors, and simply ignoring requests for "invalid" resources.
And I think the Client struct can neatly manage the relevant channels
Coraline Sherratt
@removed~csherratt
Jun 25 2014 22:32
I like the idea of an async error channel.
Dzmitry Malyshau
@kvark
Jun 25 2014 22:33
@photex @csherratt Awesome, at least we are one step closer to the consensus. The potential problem will arise if the user needs some data derived from the resource (mesh name?..). It could be solved, of course, by introducing another method like client.really_give_me_the_mesh_info_now(). So far I'm trying to imagine the possible use-cases for that, if any...
Coraline Sherratt
@removed~csherratt
Jun 25 2014 22:38
A concrete example would be good.
Dzmitry Malyshau
@kvark
Jun 25 2014 23:11
@csherratt I recall one example from my experience. Had a number of different skinning shaders: one for quaternion-provided geometry, one for tangent/bitangent, one for the geometry that only got normals. Was choosing the proper shader based on what mesh carried.