Meta tags:
description= iN fAiRy dUsT wE tRuSt;
Headings (most frequently used words):
lifecycle, work, updated, mir, shark, application, tvoss, xmir, performance, running, stopped, killed, user, shouldn, care, an, outpost, envisioned, as, new, home, large, scale, moo, experiments, with, oracle, grid, engine, mo, cma, es, continuous, integration, first, post, in, fairy, dust, we, trust, results, conclusions, future, the, model, policies, implications, of, strict, policy, front, approximation, twitter, recent, posts, archives, categories, meta,
Text of the page (most frequently used words):
the (307), and (152), that (59), for (44), with (43), our (41), this (38), are (38), mir (28), not (25), system (23), from (22), model (22), ubuntu (20), application (20), #lifecycle (20), user (19), have (18), running (17), state (17), app (17), xmir (15), performance (15), work (14), shark (13), use (13), can (13), more (13), overall (13), was (12), one (12), want (12), its (12), will (12), apps (12), however (12), quality (11), world (11), all (11), experience (11), been (11), desktop (11), case (11), engine (10), out (10), provide (10), arg (10), them (10), gpu (10), requirements (10), should (10), process (9), into (9), both (9), applications (9), well (9), different (9), too (9), driver (9), able (9), when (9), com (8), thomasvo5 (8), posted (8), post (8), decided (8), library (8), developers (8), future (8), how (8), you (8), but (8), some (8), existing (8), time (8), any (8), policy (8), resources (8), started (7), now (7), entry (7), help (7), test (7), would (7), has (7), set (7), your (7), phone (7), mobile (7), compositor (7), about (7), policies (7), impact (7), composition (7), bypass (7), cma (6), grid (6), first (6), specific (6), team (6), while (6), final (6), ensure (6), over (6), cases (6), platform (6), machine (6), run (6), further (6), being (6), version (6), shell (6), top (6), working (6), possible (6), memory (6), buffer (6), intel (6), like (5), already (5), account (5), blog (5), uncategorized (5), technology (5), canonical (5), december (5), 2011 (5), 2013 (5), large (5), updated (5), stopped (5), leave (5), terms (5), technical (5), integration (5), testing (5), providing (5), most (5), optimization (5), following (5), summary (5), needs (5), here (5), defined (5), scenario (5), objective (5), end (5), relying (5), within (5), going (5), step (5), moon (5), even (5), unity (5), toolkits (5), display (5), stack (5), seamless (5), transition (5), form (5), factors (5), before (5), towards (5), touch (5), surfaceflinger (5), protocol (5), way (5), own (5), usage (5), leverage (5), discussions (5), graphics (5), power (5), does (5), client (5), background (5), transparent (5), overhead (5), wordpress (4), name (4), required (4), tvoss (4), killed (4), care (4), reply (4), suite (4), provided (4), code (4), results (4), single (4), environment (4), approach (4), initial (4), focus (4), rely (4), development (4), goals (4), learning (4), dtlz2 (4), front (4), seed (4), there (4), known (4), computing (4), feature (4), default (4), after (4), multiple (4), lot (4), layer (4), integrated (4), efforts (4), place (4), enable (4), project (4), goal (4), neither (4), very (4), server (4), part (4), cpu (4), strict (4), easily (4), only (4), converged (4), today (4), unfocused (4), image (4), cycles (4), scenarios (4), see (4), graphical (4), design (3), comments (3), view (3), log (3), planet (3), august (3), scale (3), moo (3), experiments (3), oracle (3), outpost (3), new (3), home (3), posts (3), fairy (3), dust (3), trust (3), supported (3), platforms (3), finally (3), idea (3), implemented (3), job (3), api (3), consistent (3), easy (3), potential (3), starting (3), level (3), point (3), documentation (3), support (3), users (3), were (3), based (3), algorithms (3), other (3), objectives (3), stay (3), evaluate (3), independent (3), trials (3), note (3), across (3), objectivefunction (3), objectivespacedimension (3), command (3), 50000 (3), benchmark (3), implementing (3), installation (3), multi (3), much (3), could (3), strategy (3), target (3), implementation (3), allows (3), tightly (3), free (3), drivers (3), reach (3), important (3), google (3), forward (3), adaptable (3), solutions (3), require (3), solution (3), yes (3), these (3), found (3), efficient (3), clearly (3), soon (3), same (3), sort (3), ability (3), underlying (3), back (3), down (3), device (3), respective (3), replies (3), https (3), their (3), setup (3), resource (3), side (3), guaranteed (3), transitioned (3), transitions (3), behavior (3), diagram (3), archive (3), during (3), visible (3), states (3), make (3), developer (3), need (3), additional (3), available (3), primary (3), phoronix (3), issues (3), benchmarking (3), still (3), numbers (3), luckily (3), quite (3), glmark2 (3), actively (3), nexuiz (3), gui (3), people (3), question (3), framebuffer (3), rendering (3), get (2), site (2), website (2), manage (2), content (2), sign (2), subscribed (2), subscribe (2), feed (2), meta (2), march (2), envisioned (2), shouldn (2), general (2), continous (2), rewrite (2), virtual (2), machines (2), prevent (2), unit (2), execution (2), integrating (2), source (2), jenkins (2), interface (2), scientists (2), review (2), dive (2), little (2), processes (2), established (2), read (2), testable (2), again (2), components (2), active (2), last (2), year (2), core (2), necessary (2), solid (2), alike (2), provides (2), particular (2), evolutionary (2), serves (2), taken (2), experiment (2), tuned (2), second (2), explains (2), pareto (2), approximations (2), script (2), takes (2), actually (2), variable (2), sge_task_id (2), number (2), thus (2), result (2), dev (2), every (2), bin (2), bash (2), steadystatemocmamain (2), resultdir (2), runalgo (2), considered (2), function (2), parallel (2), array (2), maxnoevaluations (2), assume (2), indicator (2), functions (2), line (2), via (2), phases (2), approximation (2), calculation (2), pretty (2), thanks (2), done (2), lies (2), might (2), also (2), including (2), convergence (2), description (2), moving (2), allow (2), between (2), supporting (2), noted (2), qt5 (2), pipeline (2), legacy (2), adjusted (2), transparently (2), distant (2), tablet (2), regarding (2), prior (2), conversations (2), gpus (2), egl (2), together (2), nvidia (2), beautiful (2), off (2), decisions (2), evaluated (2), wayland (2), compared (2), fits (2), promising (2), sensible (2), security (2), reasons (2), wanted (2), considering (2), communication (2), chosen (2), ddl (2), idl (2), lean (2), away (2), details (2), tested (2), evaluation (2), catering (2), less (2), widely (2), weston (2), lack (2), whether (2), standalone (2), benefits (2), clear (2), think (2), demanding (2), consumption (2), compositors (2), minimal (2), central (2), ago (2), internal (2), developing (2), operating (2), classic (2), laptops (2), phones (2), tablets (2), seamlessly (2), put (2), http (2), management (2), competing (2), launchpad (2), net (2), services (2), though (2), cover (2), identified (2), internally (2), externally (2), separating (2), without (2), taking (2), non (2), defining (2), focused (2), aggressively (2), sigstop (2), whenever (2), they (2), kill (2), presented (2), current (2), granted (2), then (2), preserve (2), handing (2), becomes (2), main (2), changes (2), featured (2), connected (2), thinking (2), develop (2), tasking (2), completely (2), carry (2), tasks (2), fluent (2), perspective (2), control (2), integrate (2), fact (2), roughly (2), slow (2), fullscreen (2), benefit (2), once (2), present (2), benchmarks (2), raw (2), bound (2), clever (2), clients (2), compiz (2), opaque (2), remaining (2), living (2), series (2), notice (2), decrease (2), conclusions (2), seen (2), 3000 (2), openarena (2), hdr (2), measuring (2), reporting (2), trunk (2), reduce (2), output (2), graphic (2), skip (2), nouveau (2), surfaces (2), requires (2), destination (2), short (2), answer (2), email, write, comment, loading, collapse, bar, subscriptions, reader, report, privacy, entries, create, categories, archives, recent, search, tweets, twitter, tagged, slogan, chaos, computer, club, oldest, hacker, organizations, reviewed, commits, branch, bunch, realized, regressions, framework, handled, static, dynamic, analysis, carried, respectively, coverage, metrics, calculated, views, thereby, information, instance, gcov, valgrind, cppcheck, ctest, boost, programming, convenient, extend, equivalence, welcoming, friendly, geographically, distributed, pre, commit, despite, concerns, behalf, proved, useful, tools, rewriting, ship, quickly, reviewboard, deeper, topic, constant, high, address, wherever, feasible, unify, simplify, structure, years, contributors, simple, modular, adaptive, systems, methods, linear, nonlinear, gradient, kernel, neural, networks, various, techniques, toolbox, real, research, domains, computational, intelligence, sources, compatible, windows, solaris, macos, linux, continuous, brief, video, solving, wait, few, minutes, until, completes, algorithm, setting, unique, thing, dir, whole, cluster, normally, ops, scratch, accessible, node, null, follows, qsub, dtlz2_3, globally, path, several, moea, submit, specify, rng, explicitly, value, execute, terminating, evaluations, call, storageinterval, 100, searchspacedimension, timelimit, 1000, fitnesslimit, algorithmconfigfile, algorithmusage, defaultalgorithmusage, reportfitnessfunctions, hypervolume, dtlz, ready, bundled, executable, configurable, arguments, queryable, passing, generated, applying, moeas, recorded, accumulation, statistics, consists, three, conduct, clusters, thomas, reading, hope, give, insight, history, motivation, trajectory, head, ahead, curious, questions, simply, know, join, upcoming, olli, bigger, picture, uds, sessions, wiki, mirspec, along, burden, servers, gtk3, xul, cannot, against, translation, leverages, word, timelines, writing, preparing, deploy, next, leveraging, xwayland, porting, runs, supports, closed, vendors, those, unified, sitting, born, space, station, enables, arriving, spanning, parts, knowledge, transferred, revealing, subtleties, heavily, influenced, architecture, earliest, concerned, upon, communicate, realizing, attempt, standardizing, talk, exposes, privileged, sections, planned, handle, differently, decouple, works, facing, implement, agnostic, story, driving, buffers, data, language, rpc, abstract, transport, ordinary, socket, protobuf, backward, versioning, capabilities, component, developments, led, conclusion, adjusting, adapting, substantial, directly, vision, effectively, saying, priorities, mind, revisited, carefully, satisfies, complicated, laden, resulting, unlikely, rigorous, driven, gave, doubts, looked, fulfilled, adopted, industry, fulfills, rock, stable, did, empower, fulfill, mission, scales, getting, planning, replace, fully, ground, secure, input, subsystem, fulfilling, dictating, semantics, hardware, android, assumptions, tailored, aiming, worked, hard, draft, became, apparent, cornerstones, designing, took, distilled, spelling, shaping, cloud, sets, fridges, anyone, stated, bundle, portable, adapts, catchy, discourse, org, osx, 309, docs, document, 1ij8rtpsr_eymw3mys8gu1y2cvfzpjxdmpdijigz1sca, edit, blueprints, spec, 1303, add, readers, interested, 1st, install, engines, mechanism, hand, executing, constrains, alarms, appointments, downloads, happening, music, playback, prominent, examples, external, triggered, discussed, multitude, almost, solvable, means, logic, presentation, good, practice, software, service, escape, trap, dispatching, entity, exceeds, lifetime, dictated, nice, effect, implications, why, take, responsibility, scarce, efficiently, don, reviewers, identify, capture, hogging, consciously, conservative, open, gradually, opposed, functionality, discretion, save, ing, detect, pressure, oom, potentially, kicks, start, triggering, classical, expressed, never, automatically, triggers, limit, translates, subsequently, recreate, indicated, dashed, preceeded, notification, file, serialize, grace, period, resurrected, recreates, previous, interesting, aspect, sig, stop, stateless, sigkill, preservation, reset, removed, trigger, earlier, define, swap, dynamically, runtime, minimize, separate, executes, putting, extends, especially, screen, full, laptop, replacement, docked, edge, differences, environments, range, small, robust, fallback, problem, satisfy, constraints, offering, limited, ultimately, build, mental, longest, battery, life, expects, trying, greedy, listed, challenge, dedicated, explaining, fundamental, building, blocks, interdependent, conflicting, times, confinement, deep, stages, harmful, spans, deeply, sensors, acceleration, media, decoding, accessing, board, having, reached, common, enablement, such, straight, invoke, arbitrary, nor, ever, wonder, just, invoked, rest, update, michael, games, mode, native, resolution, mentioned, investigate, come, updates, root, causes, rate, bringing, sure, saucy, suggest, bottleneck, become, things, propagate, knows, notion, composite, mostly, itself, making, aware, nested, likely, adjustments, expose, keep, landing, significant, improvements, everyday, hardly, difference, due, requiring, yet, reported, public, dashboard, wiring, daily, preview, lenovo, x220, vpro, 4000, 2500, meaningful, complex, task, capable, tooling, opensource, selected, continuously, gains, publish, amd, regular, hit, total, section, approaches, please, investigating, qgears2, opengl, scaling, reports, speaking, significantly, keeping, aforementioned, solve, issue, straightforward, enough, recognize, situations, where, surface, complete, matches, exactly, configuration, avoided, instead, usual, moreover, smart, scan, signals, associated, infrastructure, haven, patch, glitch, ati, cards, gives, right, confident, won, major, cause, fixed, headache, vanvugt, swapping, allocation, implies, responsible, streams, assembling, compositing, scanned, monitors, buffering, render, individual, preparation, scanout, summarized, obvious, enabling, flicker, boot, shutdown, resume, suspend, session, switching, weeks, months, raised, what, degree, introduction, impacts, actual, characteristics, ways, avoid, absolutely, fluid, typical, gaming, article, insights, bottlenecks, addressing, menu,
Text of the page (random words):
and to what degree the introduction of a system level compositor impacts graphical performance the short answer is yes any additional layer between the gpu and the actual rendering process has an impact on the overall performance characteristics of the system however there are ways to avoid most of the overhead and this blog post is the not so short answer to the initial question as its name implies a compositor is responsible for taking multiple buffer streams or surfaces and assembling a k a compositing a final image that is then scanned out to the connected monitors in the general case composition requires buffering of the final image and it requires gpu resources to render the individual surfaces to the destination buffer in preparation for scanout here the destination buffer is the framebuffer the overhead of a system level compositor can be summarized as this additional rendering step in the overall graphic pipeline for the obvious benefit of being able to control the final output and enabling flicker free boot shutdown resume suspend and session switching both internally and externally people have been measuring the overall performance impact with xmir as available from the archive today roughly speaking people have been reporting a performance impact of 20 in the phoronix test suite and the question becomes how can we significantly decrease the impact in the specific case of xmir while still keeping all the aforementioned benefits in place the underlying idea to solve the issue is straightforward if the compositor is clever enough it could recognize situations where an opaque client surface does cover a complete output xmir matches exactly this configuration in that case composition can be avoided and the client should be provided with a framebuffer as rendering target instead of the usual graphic memory buffer moreover the server side composition strategy can be smart and completely skip the final composition step and scan out the framebuffer as soon as the client signals done luckily mir s composition engine and associated buffer allocation swapping infrastructure allows for implementing this behavior easily and transparently to the client the respective implementation has been living in https code launchpad net vanvugt mir bypass for some time now and we have been testing it in parallel to trunk our primary test and benchmarking platform was intel and we haven t seen any issues with the patch on that platform there is a graphical glitch present on ati cards that we are actively working on nouveau gives us some headache as it is quite slow both on x and xmir right now however we are confident that we won t see any major issues in xmir once the underlying cause in the nouveau driver is fixed results measuring graphical performance and developing meaningful benchmarks is a complex task on its own luckily we have some pretty capable tooling available in the opensource world during development and evaluation of the bypass feature we have been relying on selected test cases of phoronix test suite and on glmark2 to continuously evaluate performance gains and overall impact we are going to publish the results across intel nvidia and amd gpus as part of our regular qa reporting at http reports qa ubuntu com graphics as soon as we hit trunk in summary we are able to reduce xmir s total overhead to 6 on nexuiz and openarena see section conclusions and future work for reasons for and approaches to further reduce the remaining overhead please also note that we are actively investigating into the results for the qgears2 opengl image scaling test case gui toolkits intel 2500 gui toolkits intel 3000 gui toolkits intel 4000 nexuiz hdr off nexuiz hdr on openarena glmark2 numbers are not yet reported via the public dashboard but we are actively working on wiring them up as part of our daily quality efforts too however the numbers are quite promising as can be seen from this preview lenovo x220 i7 vpro intel r hd graphics 3000 conclusions future work today we are landing an important gpu bound optimization for the xmir use case with the bypass feature and we see significant performance improvements in our benchmarking scenarios everyday users will hardly notice any difference in graphical performance but notice a decrease in power usage on laptops due to the system compositor requiring less gpu and cpu cycles to carry out its tasks however this is only the first step and we still see some overhead in the benchmarks our glmark2 benchmark numbers for raw mir when compared to x as in saucy today suggest that we still have gpu bound optimization potential that we should leverage in the xmir case the unity system compositor performance is not the bottleneck in this specific scenario and we need to become more clever on the x side of things in summary we need to propagate the bypass approach further down into the x world and its clients with x compiz handing out the raw buffer provided by mir to fullscreen opaque x clients luckily compiz already knows about the notion of composite bypass too and the remaining optimization potential lies mostly within x itself by making it more aware of the fact that it is living in a world of nested compositors now quite likely though mir will require adjustments too to expose composition bypass end to end in the xmir scenario stay tuned we will keep you posted within this series of blog posts update michael of phoronix found out that some games when run in fullscreen mode but not at native resolution do not benefit from composition bypass as mentioned in one of the comments we are now starting to investigate into this sort of issues and will come back with updates once we identified the root causes at any rate thanks for bringing it up we will make sure that the respective benchmark setup is present in our benchmarking setup too this entry was posted in canonical planet ubuntu quality technology ubuntu uncategorized on august 29 2013 by thomasvo5 running stopped killed a user shouldn t care 3 replies to put it straight a user should be able to invoke an arbitrary number of applications and experience neither a slow down nor ever have to wonder whether an app is already running it is just there whenever it is invoked and the system takes care of the rest when we started working on ubuntu touch roughly a year ago our primary focus was the enablement of central hw components such that ubuntu would be able to run on common mobile form factors however after having reached the goal of being able to leverage hw acceleration for ui media decoding and accessing the on board sensors we started thinking about our application model that we wanted to deeply integrate with the os from a user s and a developer s perspective our primary goals are provide a consistent application model that spans installation execution and de installation of apps ensure security at all stages and account for the fact that apps have to be considered harmful ensure a seamless multi tasking experience that is transparent to the user and does not require to think in terms of running not running make the application model as easy to develop with as possible from the system s point of view our objectives are integrate a well defined confinement model deep within the system enable the system to aggressively control the resource consumption of apps enable a seamless transition to the converged world every single objective listed before is a challenge on its own on top they are interdependent and even conflicting at times however one of the most fundamental building blocks of the overall application model is the application lifecycle and this blog post is dedicated to explaining both our lifecycle model and policies from a user s perspective a mobile device is an environment offering a limited set of computing resources i e cpu cycles main memory gpu cycles graphics memory and power running applications are competing for these resources and we have to assume that applications are greedy trying to use as much of the available resources as possible the user expects the system to ensure a fluent user experience while providing the longest possible battery life at the same time on top of this the user should not be required to carry out any sort of process management tasks or to build a mental model of the different run states an app can be in ultimately the application lifecycle should be completely transparent to the user and multi tasking should be seamless a solution to the problem needs to satisfy the following additional constraints the application lifecycle model should be easy to develop with that is the changes to the well known process state machine should be as small as possible providing sensible and robust fallback behavior as ubuntu is working towards a converged world the lifecycle model needs to be adaptable to a range of different scenarios from mobile phones over tablets to classic desktop environments the differences should be transparent to the developer and both applications and the overall system need to be able to transition seamlessly from one use case to the other this is especially important when thinking about the ubuntu edge with the phone being a full featured desktop laptop replacement when docked or connected to a large screen the application lifecycle model as noted earlier one of our goals is the ability to define different lifecycle policies and swap them out dynamically at runtime to account for different usage scenarios we want to minimize the impact on developers when moving to a converged world and make lifecycle policy changes and decisions transparent to a user and a developer alike to this end we clearly separate the application lifecycle model and the policies that the system executes on top of it our current model we are putting in place extends on the well known process state machine as presented in the following diagram the states are defined as focused the application is visible to the user and guaranteed to be running and provided with all necessary resources unfocused the application is not guaranteed to be running i e it might not be granted cpu or gpu cycles and the policy is free to trigger a state transition to any of the not running states in the phone scenario the app is not visible to the user killed the app s process image has been removed from main memory stopped the app s process is sigstop d stateless the app s process has been sigkill d without prior state preservation serves as a way to reset an app s state a transparent application lifecycle then translates to ensure that applications are able to preserve and subsequently recreate their state before being transitioned to the not running meta state this is indicated by dashed state transitions in the diagram all of these transitions are preceeded by a notification to the app that it is about to be stopped or killed handing over an archive file that the app can serialize its state to during a grace period after that the app is actually transitioned to not running when the app is resurrected the system provides the archive back to the app and the app recreates its previous state in the diagram an interesting aspect becomes visible as we want to enable lifecycle policies to kill a stopped app an application needs to preserve its state even if only being sig stop ed application lifecycle policies based on the application lifecycle model presented before we can now start defining policies triggering the state transitions classical desktop behavior can be easily expressed in this model too the current desktop lifecycle policy never automatically triggers a state transition from the running to the not running state and does not limit resources granted to an app when unfocused for version 1 on the phone only considering the non converged standalone phone scenario we are defining a very strict lifecycle policy all non focused apps are not guaranteed to stay in the running state and are transitioned to the not running state at the policies discretion to aggressively save resources today we are already sigstop ing app processes whenever they are unfocused and we will go even further and kill unfocused apps when we detect memory pressure even before the oom potentially kicks in why are we so strict we as a platform take on the responsibility to manage the scarce resources of a mobile device as efficiently as possible we don t want to leave it up to reviewers or users to identify and capture resource hogging apps however this is only version 1 and we consciously decided for a very conservative approach that we can open up gradually going forward as opposed to starting without a clear policy and taking away functionality over time implications of a strict lifecycle policy both internally and externally a lot of discussions have been triggered by the strict lifecycle policy for version 1 we have discussed a multitude of different use cases and almost all of them are solvable by means of separating apps into an engine and into a ui part first separating application logic from the presentation layer is good practice in software design second relying on an engine background service allows apps to escape the lifecycle trap easily by dispatching to an entity that exceeds an apps lifetime as dictated by our lifecycle policy a nice side effect is easily testable code how does work for version 1 in ubuntu touch in summary the system will provide a set of system services that cover the most prominent examples and use cases identified from both external internal discussions e g music playback in the background downloads happening in the background alarms appointments in this 1st version apps will not be able to install their own background services engines in the default setup however going forward in time we will provide a mechanism for apps to hand their engine to the system and have it executing in the background with resource constrains in place though for readers interested in more details https blueprints launchpad net ubuntu spec client 1303 add app model and lifecycle to platform api https docs google com a canonical com document d 1ij8rtpsr_eymw3mys8gu1y2cvfzpjxdmpdijigz1sca edit http ubuntu discourse org t how osx does power management and how ubuntu is competing 309 12 this entry was posted in planet ubuntu ubuntu on august 15 2013 by thomasvo5 updated mir an outpost envisioned as a new home 11 replies some time ago canonical started internal discussions about our convergence strategy clearly spelling out the distant target of shaping and developing a single computing platform and operating system that is able to power the cloud classic desktop machines laptops tv sets phones and tablets fridges anyone more to this we stated that we want a single mobile device a bundle of portable computing power together with the respective operating system that seamlessly adapts to different form factors and use cases or to put it a little more catchy your...
|
