Meeting 2013 06 17

Servo Meeting 2013-06-17

Agenda

• gpu profiling
• reftests

Attending

pcwalton, jack, eschweic, azita, bz, brson, ssapin

GPU profiling

• jack: landed GPU rendering last week. been doing some profiling. on the whole we're slower, but it mostly comes from creating FBO-backed draw targets.
• pcwalton: can recycle some of those?
• jack: theoretically -pcwalton: will need to recycle tiles anyway
• jack: on 800x600 screen we create 4 tiles. used to be 1/5th ms now 20ms. 100ms just creating 4 tiles. 10ms per tile to draw.
• pcwalton: weird that FBO's are so slow. before just malloc. maybe profile actual driver. sometimes on mac you can look at what they're doing.
• jack: skia's doing a lot of work, stencil buffers, textures, GL features, 20-30 api calls.
• jack: code in tree also does task-per-tile. taken that out locally but doesn't change numbers much. slower in terms of clock time
• pcwalton: wouldn't expect that since parallelism in GPU
• jack: sequential bottleneck creating buffers
• jack: (something) easiest way is to make tiles same size, 512x512.
• pcwalton: some notes: tile size is too big, should decrease to 256; when compositor and renderer exchange buffers (thebes buffer swap in gecko), compositor needs to send back textures that are free; since we're going to have multiple renderers maybe make that a shared cache among all renderers; not sure how feasibile that is because of GL threading issues. for now we can just send them back to the single renderer we have. renderer will hold on to some tiles. when it wants to make a new tile it checks whether the cache tiles have right size and if so reuses it.
• jack: so you think we should use odd-size tiles and search for ones to reuse?
• pcwalton: possible that having odd-size tile doesn't hurt. reason we have them in gecko is for memory usage. maybe. if they are small enough anyway t doesn't matter and increased reuse counters the cost of increased mem usage
• jack: theoretically you wouldn't get that much reuse. when resizing view area you reuse (missed)
• pcwalton: can also appear when creating and destroying layers in animations. wouldn't necessarily do what gecko does. tiled rendering hacked in to get fennec wtorking. -pcwalton: other wringkle: expensive part is creating the draw target, not th etexture. it's the other crap: stensile buffer, etc. if compositor is sending back textures it's not sending back that other state. ideally we want to reuse all that state. not sure how to recycle it.
• jack: i'll try to recycle draw targets with tile search. see how that works
• pcwalton: another wrinkle re: updating only portions of tiles. can do it with double buffering + copy on write. don't know what the implications of that are. somewhat skeptical.
• jack: other thing: right now have rendering split between two tasks: render task and render layer. logic hard to follow. going to combine them. if we're not spinning each tile into its own task then it's not buying us anything.
• jack: good news is compositing got a 10x speed improvement.
• pcwalton: that determines scrolling performance. rendering is important to prevent checkerboards but in terms of compositing perf. being at 1000 fps - that's good
• jack: don't know drawing perf of old code because I needed to put in that prof. category but I'll get that number today
• pcwalton: won't know how it feels until we render only the viewing area - right now we render the entire page
• jack: (missed)
• pcwalton: need eston's tiling stuff to land. part of it is actually only rendering what's visibel. as you scroll the renderer will start renderingmore tiles.
• jack: if you're working over here anyway eston do you want to take over and to the draw target reuse etc?
• eston: one thing i'm blocked on right now: tim is refactoring the engine and init code. what I eventually want to do is get a channel between compositor and renderer so we can pass information back. once his changes land I can start working on that.

Ref tests

• jack: somebody mentioned that a specific test was regressed?
• pcwalton: i don't know of any regressions right now
• jack: what's the progress of rendering to images?
• pcwalton: have not made progress on that.

(missed)

• pcwalton: if you wanted to start from other end and have it do glut for now and write out PNG from currently active window that might be useful. keegan has a blog post how to write an uncompressed png in a few lines of code. might be useful.
• jack: is there a reason not to use the tga code?
• pcwalton: tga sucks (paraphrased)
• jack: ok, nbd.

(meeting over)