Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 04:49

    cwfitzgerald on hal-0.6

    [dx11] Correctly bump version t… (compare)

  • 04:35
    kvark edited #3434
  • 04:34
    kvark synchronize #3434
  • 04:28
    kvark review_requested #3434
  • 04:28
    kvark opened #3434
  • 02:09
    bors[bot] closed #3433
  • 02:09

    bors[bot] on hal-0.6

    [dx11] Fix leak of buffers when… [dx11] Fix leak of images [dx11] Bump version to 0.6.8 and 1 more (compare)

  • 02:09
    bors[bot] commented #3433
  • 02:00

    bors[bot] on staging.tmp

    (compare)

  • 02:00

    bors[bot] on staging

    [dx11] Fix leak of buffers when… [dx11] Fix leak of images [dx11] Bump version to 0.6.8 and 1 more (compare)

  • 02:00

    bors[bot] on staging.tmp

    [dx11] Fix leak of buffers when… [dx11] Fix leak of images [dx11] Bump version to 0.6.8 and 1 more (compare)

  • 02:00

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • Oct 23 22:30
    cwfitzgerald synchronize #3433
  • Oct 23 22:25
    cwfitzgerald synchronize #3433
  • Oct 23 22:04
    cwfitzgerald edited #3433
  • Oct 23 22:00
    cwfitzgerald review_requested #3433
  • Oct 23 22:00
    cwfitzgerald opened #3433
  • Oct 23 04:40
    bors[bot] closed #3431
  • Oct 23 04:40

    bors[bot] on hal-0.6

    [dx11] Fix dynamic offsets with… [dx11] Update changelog Merge #3431 3431: [0.6/dx11] F… (compare)

  • Oct 23 04:40
    bors[bot] commented #3431
Brendan Zabarauskas
@brendanzab
@photex no cat! you are boring now :(
Chip Collier
@photex
haha
I'm zen
Dzmitry Malyshau
@kvark
cat-zen
Chip Collier
@photex
I'll draw some ears on it
Brendan Zabarauskas
@brendanzab
@photex I wan splodey cat again :(
Chip Collier
@photex
ok ok
lemme find it
brendanzab @bjz is working on a bad presentation
Dzmitry Malyshau
@kvark
@bjz you've got a rather large scope...
Brendan Zabarauskas
@brendanzab
aye
dunno if I should redefine it :(
Chip Collier
@photex
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
:cat2: :cat2: :cat2: :cat2: :cat2: :cat2:
sorry for derailing the discussion :smile:
Chip Collier
@photex
ok splodey is back... no idea when gitter updates it
Dzmitry Malyshau
@kvark
@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
@photex :heart:
Coraline Sherratt
@removed~csherratt
@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
If the handle in this case was actually just an pointer, the server would not even need to look up anything.
Dzmitry Malyshau
@kvark
@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
What is the content of the handle exactly?
Dzmitry Malyshau
@kvark
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
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
@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
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
@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
Is the pipeline stall caused by the user checking an issue worth fixing?
*use waiting on the error result
Dzmitry Malyshau
@kvark
@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
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
@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
So do you think it would be too costly to return a Result<> for each fallible message?
Dzmitry Malyshau
@kvark
@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
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
I like the idea of an async error channel.
Dzmitry Malyshau
@kvark
@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
A concrete example would be good.
Dzmitry Malyshau
@kvark
@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.
Brendan Zabarauskas
@brendanzab
Ok, if you guys are convinced an async error handling strategy is best, lets do it! Probably makes more sense in a game dev context.