Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:13
    bors[bot] closed #3091
  • 20:13
    bors[bot] closed #3090
  • 20:13
    bors[bot] commented #3091
  • 20:13

    bors[bot] on master

    update glutin version Merge #3091 3091: [GL] Update … (compare)

  • 19:25

    bors[bot] on staging.tmp

    (compare)

  • 19:25

    bors[bot] on staging

    update glutin version Merge #3091 3091: [GL] Update … (compare)

  • 19:25

    bors[bot] on staging.tmp

    update glutin version [ci skip][skip ci][skip netlify… (compare)

  • 19:25

    bors[bot] on staging.tmp

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

  • 18:50
    Gordon-F opened #3091
  • 15:59
    kvark pinned #3090
  • 15:59
    kvark labeled #3090
  • 15:59
    kvark labeled #3090
  • 15:59
    kvark labeled #3090
  • 15:59
    kvark labeled #3090
  • 15:59
    kvark labeled #3090
  • 15:59
    kvark opened #3090
  • Nov 12 17:01

    kvark on hal-0.4

    metal: build ios shaders in Mak… bump verison number (compare)

  • Nov 12 17:01
    kvark closed #3089
  • Nov 12 17:01
    kvark commented #3089
  • Nov 12 17:01
    kvark edited #3089
Dzmitry Malyshau
@kvark
@photex I read it yesterday, and didn't see a solution outside of just "please be careful to not overflow"
also, let's structurize your points. Here is what I see:
  1. DoS possibility
  2. memory fragmentation
  3. you don't think it solves anything
is that a correct recap?
Chip Collier
@photex
yep, but add 4) I honestly don't mind your solution. I'm just making sure we discuss it (helps me understand everything)
Dzmitry Malyshau
@kvark
@photex ok, so let's go through the points:
  1. I don't see why anyone would want to do that. Device is not exposed to the network, so we can assume whoever works with it is trusted
  2. could you explain this bit? AFAIK, my solution covers that 1% of usecases where we alternatively either crash or go unsafe. Even if memory gets fragmented, it's an exception case and we can live with it
  3. pretty much explained it in 2.
  4. sure, no worries! I might be easily missing bits myself too
Chip Collier
@photex
  1. If the argument is about safety, then disabling a cell is certainly unsafe vs a generation overflow (my opinion).
  1. when a generation is maxed and you can't add a new item in it's place, now you have a cell that is going to have to be skipped.
oops, that should be 2.
that's it. I think operationally it seems rare, but the engine data wasn't entirely meant to be used behind the scenes
I had anticipated it's use in game threads, scene graphs, etc
multi-line
ahh ok Shift-Enter
Dzmitry Malyshau
@kvark
@photex
  1. why is disabling unsafe? EntityData may guarantee that nothing tries to use that handle
  2. for all managing purposes, this handle is going to behave as being already used. I don't see any overhead of this in the code. Where do you see it being skipped exactly?
Chip Collier
@photex
if you delete an item, generation is incremented, if it reaches LAST_GENERATION then from that point forward, the cell this relates to is no longer able to be used
so when iterating over the collection, you now have to check for a generation that equals LAST_GENERATION
if it does, then this is a disabled cell, so we skip it
did I misunderstand this?
Dzmitry Malyshau
@kvark
@photex that's correct, yes, but when are you going to actually iterate the valid handles? I don't see it in your code.
Chip Collier
@photex
you would presumably be iterating over the data that the handle refers to
now you have to include the handle generations in that work
this code wasn't entirely worked out either :)
Dzmitry Malyshau
@kvark
@photex wait, wait. "iterating over the data that the handle refers to"?
Each handle has 1 data associated. What iteration do you mean exactly?
Chip Collier
@photex
well, these handles are related to a Vector, when a system in the game performs it's update loop it's over that Vector
the iterator hasn't been implemented yet
Chip Collier
@photex
lunch time :)
Dzmitry Malyshau
@kvark
@photex oh well, so you are describing something outside of the code... I'll need to see that to understand. Perhaps, @bjz knows better what you have in mind?..
My understanding is that nothing (outside of, possibly, some debug functionality) will need to iterate the valid handles (where different types of handles are used for, to say, vertex buffers, shaders, meshes, materials, etc). The game (or for some handles - the render thread) keeps track of the handles it uses, and iterates over its own structures.
Chip Collier
@photex
nothing will iterate the handles
but they will iterate what the handles point to
if you can't make a new handle
then you can't effectively make a new item in the collection
anyway, there is clearly a problem with this design. Perhaps we should redesign it from first principles
Brendan Zabarauskas
@brendanzab
so what is the problem?
this is with the data-oriented way of doing things?
Dzmitry Malyshau
@kvark
@photex could you explain it on an example with a particular handler type?
@cmr ohi!
Brendan Zabarauskas
@brendanzab
@cmr o/
@cmr: still keeping this pretty quiet seeing as we have lots still to figure out
Dzmitry Malyshau
@kvark
@bjz I'm trying to get what's the problem with my proposal according to @photex , and so far it seems that I misunderstand the whole concept of handler management.
Brendan Zabarauskas
@brendanzab
@photex do you think this is something we can re-engineer later? It would be awesome just to get something rendering. I know this is pretty fundemental though.
@kvark gw might be on IRC soon
@kvark perhaps you could ask him - he has tons of experience with this design
Dzmitry Malyshau
@kvark
@bjz ok, will try to catch him
@bjz btw, the whole handler management thing is not required to get something rendering
Brendan Zabarauskas
@brendanzab
@kvark I reckon just implement something then we can squabble over it in a PR :)
It will probably be easier with something more concrete
Dzmitry Malyshau
@kvark
@bjz you know, I'm on my way to it...
Brendan Zabarauskas
@brendanzab
:D
sorry
Dzmitry Malyshau
@kvark
@bjz it's cool, I understand your position
Dzmitry Malyshau
@kvark
@bjz halp! Even if I introduce GlProvider trait, I can only implement it for Glfw, but we have a Window, not the context.... And the reason we are not capturing the whole context is because we want to leave event management to the user (which makes perfect sense). Piston doesn't have this problem since they are managing events internally, so they are just capturing the whole thing...
Dzmitry Malyshau
@kvark
@bjz Ok, I kinda worked my way through it, but it break a bit of platform abstraction. Passing a reference to Glfw (under my trait) as the initialization option now.