Meta tags:

Headings (most frequently used words):

2011, 2010, october, 25, tuesday, september, thursday, apitrace, friday, 2013, 27, sunday, 18, monday, april, november, 02, 28, july, 01, about, me, links, blog, archive, bodega, nv, path, rendering, 2d, musings, intermediate, representation, again, graphics, drivers,

Text of the page (most frequently used words):
the (196), and (123), that (77), you (42), for (35), graphics (32), which (29), code (29), all (28), but (27), with (26), can (25), would (24), #rendering (23), like (22), share (21), from (21), not (21), drivers (19), have (19), some (19), very (19), just (19), using (19), this (18), lot (18), was (18), are (17), about (16), gpu (16), draw (15), well (14), they (13), make (13), because (13), one (13), there (13), every (13), tgsi (13), their (12), path (12), posted (11), more (11), will (11), model (11), data (11), new (10), need (10), could (10), them (10), really (10), same (10), opengl (10), zack (9), linux (9), working (9), use (9), driver (9), any (9), trace (9), its (9), were (9), performance (9), your (9), support (9), extension (9), open (8), what (8), api (8), don (8), then (8), out (8), other (8), time (8), each (8), pretty (8), direct3d (8), huge (8), apitrace (8), 2010 (7), 2011 (7), bodega (7), labels (7), pinterest (7), facebook (7), blogthis (7), email (7), comments (7), better (7), gnu (7), gallium (7), those (7), our (7), gpus (7), llvm (7), once (7), texture (7), paths (7), being (7), number (7), already (7), start (7), nvidia (7), how (7), windows (7), had (7), works (7), project (7), call (7), september (6), october (6), even (6), multiple (6), state (6), software (6), done (6), plus (6), see (6), running (6), things (6), who (6), good (6), again (6), hard (6), write (6), know (6), think (6), work (6), shader (6), way (6), language (6), bit (6), content (6), frame (6), render (6), life (6), file (6), gui (6), nv_path_rendering (6), little (6), node (6), november (5), gallium3d (5), than (5), having (5), while (5), simply (5), people (5), since (5), amd (5), great (5), idea (5), possible (5), why (5), though (5), both (5), most (5), different (5), when (5), few (5), qml (5), allows (5), fact (5), over (5), ever (5), may (4), june (4), july (4), august (4), february (4), march (4), april (4), devices (4), framework (4), sense (4), meant (4), has (4), trivial (4), right (4), now (4), two (4), get (4), before (4), side (4), doing (4), decided (4), vector (4), small (4), day (4), years (4), only (4), free (4), stuff (4), compiler (4), anything (4), debug (4), unfortunately (4), assembly (4), sometimes (4), either (4), making (4), much (4), look (4), parts (4), intermediate (4), started (4), representation (4), been (4), important (4), object (4), everything (4), completely (4), scene (4), tool (4), upload (4), limited (4), keep (4), application (4), games (4), became (4), amazing (4), ability (4), tracing (4), whether (4), developer (4), demo (4), 2013 (3), course (3), wanted (3), stack (3), memory (3), llvmpipe (3), part (3), away (3), play (3), likely (3), release (3), without (3), folks (3), true (3), able (3), replay (3), everyone (3), hardware (3), always (3), probably (3), problem (3), general (3), writing (3), actually (3), usually (3), too (3), obviously (3), computer (3), extend (3), behind (3), enough (3), give (3), doesn (3), require (3), own (3), written (3), developers (3), seen (3), also (3), never (3), optimize (3), companies (3), compiled (3), thing (3), easier (3), does (3), down (3), something (3), makes (3), interface (3), still (3), into (3), wrote (3), line (3), rectangle (3), calls (3), old (3), perspective (3), almost (3), change (3), addition (3), wasn (3), creating (3), store (3), primitives (3), used (3), include (3), first (3), another (3), many (3), setup (3), meaning (3), shaders (3), weird (3), last (3), large (3), features (3), should (3), github (3), inspect (3), during (3), best (3), implementation (3), svg (3), faster (3), might (3), implementations (3), files (3), hand (3), sure (3), load (3), distribution (3), aaron (3), crack (3), testing (3), awesome (2), december (2), org (2), complete (2), posts (2), company (2), shipping (2), management (2), kernel (2), modesetting (2), trackers (2), optimized (2), whatever (2), bad (2), terrible (2), fix (2), issues (2), hope (2), exactly (2), amount (2), certainly (2), simpler (2), gpgpu (2), vertex (2), units (2), optimizations (2), anyone (2), did (2), intel (2), known (2), desktop (2), seems (2), benefits (2), debugging (2), worth (2), android (2), example (2), skia (2), cairo (2), ones (2), unless (2), late (2), programmers (2), subset (2), harder (2), thursday (2), ultimately (2), kind (2), science (2), backend (2), main (2), try (2), abandon (2), clear (2), experts (2), reason (2), functional (2), unlike (2), top (2), transformable (2), rather (2), basically (2), thought (2), nice (2), care (2), essentially (2), case (2), crucial (2), opencl (2), poor (2), schmuck (2), going (2), definitely (2), living (2), transformations (2), didn (2), finally (2), usage (2), calling (2), designed (2), instructions (2), words (2), target (2), times (2), feels (2), ago (2), topic (2), made (2), web (2), engines (2), image (2), short (2), needs (2), accelerated (2), mesa3d (2), changes (2), create (2), interfaces (2), neat (2), argue (2), moving (2), significant (2), graph (2), seem (2), changing (2), move (2), transfers (2), download (2), cache (2), composition (2), modes (2), buffer (2), such (2), identifiers (2), pixmaps (2), efficient (2), itself (2), least (2), worked (2), costs (2), processing (2), zero (2), larger (2), process (2), uploads (2), closer (2), entire (2), handle (2), buffers (2), evolved (2), lots (2), blogs (2), slow (2), tuesday (2), jose (2), let (2), standalone (2), cad (2), apps (2), immediately (2), app (2), analyze (2), spent (2), looking (2), robust (2), results (2), quickly (2), patch (2), quite (2), came (2), openvg (2), whole (2), quality (2), implemented (2), site (2), improvements (2), means (2), applications (2), hacker (2), frames (2), market (2), technology (2), his (2), platform (2), high (2), dynamically (2), typed (2), languages (2), rewrote (2), inc, theme, powered, blogger, 2006, january, 2007, 2008, 2009, blog, archive, kde, freedesktop, links, view, profile, subscribe, atom, home, older, mesa, millions, bottom, ask, shipped, apparently, defy, logic, stands, excellent, ironically, precisely, mutation, potential, future, continues, generalization, drm, command, submission, generator, stretch, imagination, smaller, become, eventually, latter, mandatory, anyway, after, sampling, stay, dedicated, meego, ways, nokia, past, n800, n810, poulsbo, moorestown, woes, afraid, porting, destabilize, cleaner, tools, rbug, nicely, abstracting, hugely, beneficial, vendors, ship, value, platforms, phones, worst, frameworks, notables, wrap, game, port, ndk, pain, lack, decent, biggest, full, supports, earliest, someone, officially, available, maybe, year, incremental, update, motivation, weight, gold, double, skinny, tasks, successful, crocodile, petting, zoo, wireless, bungee, jumping, taking, speculative, ptx, places, generate, directly, proof, sacrificing, farm, animals, vegetarian, firmly, against, lunarg, injected, becomes, personally, abhor, rolling, word, crazy, sound, left, access, spec, confused, pre, declared, registers, typeless, easily, readable, simple, easy, negative, transform, structure, rare, simplicity, overabundance, misplaced, optimism, respective, wouldn, wonderful, take, end, logically, sadly, teams, talk, lofty, goal, quicker, adopt, took, severe, beating, especially, disappointing, documentation, notice, added, sadder, sit, less, insanely, handsome, brackets, operate, design, importantly, specification, public, explain, specific, realized, mistake, tried, back, paddle, term, referring, transport, describes, purpose, confusing, dance, off, geek, conference, painful, embarrassing, involved, called, tokenized, middle, layer, glsl, python, transformed, x86, blogging, rarely, ions, convoluted, info, decompose, canvas, style, painters, worries, fine, fundamentally, javafx, neater, rid, love, effect, long, difference, feel, qgraphicsview, qpainter, likes, fairly, familiar, suddenly, taken, required, drastic, boils, where, lifetime, knows, objects, rendered, begins, initialize, items, renderer, removal, properties, further, reused, note, hover, push, additional, translations, floats, translation, shared, pushbutton, background, label, glyphs, fixing, real, types, fills, collecting, temporary, copying, skoswindow, afterchildren, qwindowsurface, endpaint, adding, unique, surfaces, keys, pixmap, surface, copied, obvious, composed, widgets, widget, draws, rectangles, lines, primitive, needed, persistence, button, sees, stuck, request, user, static, boring, issue, cases, offset, technically, necessary, prevalent, commands, tell, sent, describe, increasingly, complex, scenes, downloads, allowing, resource, refer, via, shading, stages, tessellation, geometry, reduce, size, uploaded, neglect, hasn, function, blit, joined, fill, stroke, extra, core, remained, equally, following, developments, world, articles, complaining, particular, wondered, smooth, sluggish, musings, next, contexts, export, single, stop, hot, key, soon, graphs, significantly, announced, hosted, bsd, licensed, planning, add, osx, requires, qjson, library, longer, install, report, figure, wrong, automatically, produce, testcases, send, nuts, edit, uniform, chunks, effects, threw, error, point, bound, framebuffer, check, begin, console, created, three, weeks, spare, inspired, gdebugger, pix, slice, through, exact, causes, problems, including, textures, ended, getting, human, robot, emancipation, act, 3015, monday, released, gl_nv_path_rendering, relatively, stroked, filled, heard, lately, busy, spend, seconds, comparing, demos, clipped, transforms, dream, teaching, imaginary, hamster, drive, stick, shift, favorite, pastimes, ridicules, seeing, fast, unbelievably, clearly, these, trying, outcrazy, fortunately, compiles, workstation, card, measly, quadro, 600, dual, processor, xeon, e5405, raster, engine, looked, surprising, tiger, scaling, rotating, 270fps, 72fps, here, numbers, lower, account, figured, related, techniques, hacked, brand, window, click, qglpixelbuffer, nvpr_svg, changed, encoding, saved, dos, unix, shouldn, applying, quick, glance, slower, said, looks, numerically, stable, individual, pixels, impressed, situation, creates, proper, introducing, toolkit, implements, based, differ, profit, question, matters, specifically, improves, justify, hit, success, largely, depend, promoted, ext, ideally, arb, toolkits, libs, central, place, modern, maintain, non, matter, https, com, zackr, qt_svg, sdk, videos, sunday, far, bump, version, flushing, syncing, uncaught, signal, exception, switching, compression, zlib, magic, seek, demand, compressed, disk, loading, 1gb, takes, 20mb, ram, mean, starting, classified, abuse, superstar, differs, average, keyboard, headbutts, half, bucket, tears, week, believe, read, snappy, incredible, bug, fixes, throw, gl_gremedy_string_marker, gl_gremedy_frame_terminator, extensions, mark, pieces, showing, per, marking, indent, display, uniforms, multi, gigabyte, traces, mac, 10x, retracing, digital, today, prose, unbeatable, ripped, stallone, steroids, natural, inject, supplements, appreciated, widely, google, apple, noticed, discovery, rankings, communication, publishers, vetting, solves, vision, weren, mostly, apologize, isn, funny, plumber, hilarious, beginning, php, reuse, nightmare, fan, server, programming, validate, avoid, silly, mistakes, highly, hell, weekend, got, sick, setting, apache, test, sat, javascript, reading, choice, mocha, between, unit, tests, live, dynamic, nature, extensive, collection, packages, picked, job, pick, haskell, admit, system, level, shakes, head, native, uses, posgresql, combination, amazingly, biased, opinion, interesting, tooling, focus, finish, npm, jshint, friday, rusin,

Text of the page (random words):
little bit of time looking at the individual pixels and came away very impressed in general the extension is in a little bit of a weird situation on one hand unlike openvg which creates a whole new api it s the proper way of introducing gpu path rendering on the other hand pretty much every vector graphics toolkit out there already implements gpu based path rendering obviously the implementations differ and some might profit from the extension but for qt the question is whether that quality matters more than the performance specifically whether the quality improves enough to justify the performance hit i think the extension s success will largely depend on whether it s promoted to at least an ext or ideally an arb meaning all the drivers support it using it would make the implementations of path rendering in toolkits vector graphics libs a lot simpler and give driver developer a central place to optimize a pretty crucial part of the modern graphics stack unfortunately if you still need to maintain the non nv_path_rendering paths then it doesn t make a whole lot of sense mesa3d implementation would be trivial simply because i ve already implemented path rendering for openvg using the gallium3d interface so it d be a matter of moving that code but i m just not sure if anyone will be actually using this extension all in all it s a very well done extension but it might be a little too late posted by zack at 9 18 2011 01 27 00 am 14 comments email this blogthis share to x share to facebook share to pinterest labels gallium3d graphics opengl performance qt monday april 25 2011 apitrace during the last three weeks i ve spent most of my spare time writing a gui for jose s amazing apitrace project apitrace is a project to trace analyze and debug graphics api s both opengl and direct3d to some extend inspired by gdebugger and windows pix we wanted a tool that would let us slice through huge games and cad apps to the exact call which causes problems and be able to inspect the entire graphics state including the shaders textures and all the buffers we ended up doing that plus a lot more and we re just getting started in other words it s the best thing since human robot emancipation act of 3015 you begin by tracing your target application you can do that either from the console or from the gui a trace file is created and we can do some amazing things with it you can open it in a gui and inspect the state frame by frame draw call by draw call replay the trace file check every texture every bound framebuffer every shader every vertex buffer you can see if opengl threw an error at any point during the replay and if so what was it and to go completely nuts as graphics developers like to do you get to edit any shader any uniform and large chunks of the state to immediately see the effects it would have on the rendering as a driver developer you no longer have to install all the games just to debug a problem the report can simply include a short trace which you can use to immediately figure out what s wrong as an application developer you can inspect every graphics call your app makes you can analyze your api usage and you could automatically produce standalone testcases which you can send to driver developers apitrace is hosted on github and it s bsd licensed it works on linux and windows we re planning to add osx support as well gui is written using qt and requires the qjson library jose just announced the first release so let us know if there s anything that would make your life a lot easier next is support for multiple gl contexts ability to export just a single frame from a trace either as a trace file or a standalone c application ability to start and stop tracing on a hot key and lots of other features soon so whether you re a driver developer working on games cad apps or 2d scene graphs this is a tool that should make your life significantly easier and better posted by zack at 4 25 2011 09 21 00 pm 40 comments email this blogthis share to x share to facebook share to pinterest labels graphics opengl qt tuesday november 02 2010 2d musings if you ve been following graphics developments in the 2d world over the last few years you ve probably seen a number of blogs and articles complaining about performance in particular about how slow 2d is on gpus have you ever wondered why it s possible to make this completely smooth but your desktop still sometimes feels sluggish bad model for some weird reason neglect being one of them 2d rendering model hasn t evolved at all in the last few years that is if it has evolved at all since the very first draw line became a function call draw line draw rectangle draw image blit this were simply joined by fill path stroke path few extra composition modes and such at its very core the model remained the same though meaning lots of calls to draw an equally large number of small primitives this worked well because technically zero or almost zero setup code was necessary to start rendering then gpus became prevalent and they could do amazing things but to get them to do anything you had to upload the data and the commands that would tell them what to do with time more and more data had to be sent to the gpu to describe the increasingly complex and larger scenes it made sense to optimize the process of uploads i keep calling them uploads but gpu downloads is closer to the true meaning by allowing to upload an entire resource once and then refer to it via a handle buffers shaders addition of new shading stages tessellation geometry all meant to reduce the size of data that had to be uploaded to the gpu before every rendering at least for games and well designed 3d software 2d stuck to its old model of make gpu download everything on every draw request it worked ok because most of the user interface was static and rather boring so the performance was never much of an issue plus in many cases the huge setup costs are offset by the fact that the graphics processing units are really good at processing graphics each application is composed of multiple widgets each widget draws itself using multiple primitives pixmaps rectangles lines paths and each primitive needs to first upload the data needed by the gpu to render it it s like that because from the 2d api perspective there s no object persistence the api has no idea that you keep re rendering the same button over and over again all the api sees is another draw rectangle or draw path call which it will complete on each frame the same data is being copied to the gpu over and over again it s not very efficient is it there s a limited number of optimizations you can do in this model some of the more obvious ones include adding unique identifiers to the pixmaps surfaces and using those as identifiers as keys in a texture cache which allows you to create a texture for every pixmap surface only once collecting data from each draw call in a temporary buffer and copying it all at once e g in skoswindow afterchildren qwindowsurface endpaint or such creating a shader cache for different types of fills and composition modes but the real problem is that you keep making the gpu download the same data every frame and unfortunately that is really hard to fix in this model fixing the model it all boils down to creating some kind of a store where lifetime of an object model is known this way the scene knows exactly what objects are being rendered and before rendering begins it can initialize and upload all the data the items need to be renderer then rendering is just that rendering data transfers are limited to object addition removal or significant changes to their properties and then further limited by the fact that a lot of the state can always be reused note that trivial things like changing the texture e g on hover push don t require any additional transfers and things like translations can be limited to just two floats translation in x and y and they re usually shared for multiple primitives e g in a pushbutton it would be used by the background texture and the label texture glyphs it would seem like the addition of qgraphicsview was a good time to change the 2d model but that wasn t really possible because people like their qpainter no one likes when a tool they have been using for a while and are fairly familiar with is suddenly taken away completely changing a model required a more drastic move qml and scene graph qml fundamentally changes the way we create interfaces and it s very neat from the api perspective it s not much different from javafx and one could argue which one is neater better but qml allows us to almost completely get rid of the old 2d rendering model and that s why i love it a side effect of moving to qml is likely the most significant change we ve done to accelerated 2d in a long time the new qt scene graph is a very important project that can make a huge difference to the performance look and feel of 2d interfaces give it a try if you don t have opengl working no worries it will work fine with mesa3d on top of llvmpipe a nice project would be doing the same in web engines we have all the info there but we decompose it into the draw line draw path draw rectangle draw image calls short of the canvas object which needs the old style painters everything is there to make accelerated web engines a lot better at rendering the content posted by zack at 11 02 2010 02 56 00 pm 36 comments email this blogthis share to x share to facebook share to pinterest labels graphics performance qml qt thursday october 28 2010 intermediate representation again i wrote about intermediate representation a few times already but i ve been blogging so rarely that it feels like ions ago it s an important topic and one that is made a bit more convoluted by gallium the intermediate representation ir we use in gallium is called tokenized gallium shader instructions or tgsi in general when you think about ir you think about some middle layer in other words you have a language e g c glsl python whatever which is being compiled into some ir which then is transformed optimized and finally compiled into some target language e g x86 assembly this is not how gallium and tgsi work or were meant to work we realized that people were making that mistake so we tried to back paddle on the usage of the term ir when referring to tgsi and started calling it a transport or shader interface which better describes its purpose but is still pretty confusing tgsi was simply not designed as a transformable representation it can be done but it s a lot like a dance off on a geek conference painful and embarrassing for everyone involved the way it was meant to work was language tgsi gpu specific ir transformations gpu with the parts in the brackets living in the driver why like that because gpus are so different that we thought each of them would require its own transformations and would need its own ir to operate on because we re not compiler experts and didn t think we could design something that would work well for everyone finally and most importantly because it s how direct3d does it direct3d functional specification is unfortunately not public which makes it a bit hard to explain the idea behind it was great in both its simplicity and overabundance of misplaced optimism all graphics companies had direct3d drivers they all had working code that compiled from direct3d assembly to their respective gpus if tgsi will be a lot like direct3d assembly then tgsi will work with every gpu that works on windows plus wouldn t it be wonderful if all those companies could basically just take that windows code and end up with a working shader compiler for gnu linux we thought logically that would be a nice thing sadly companies do not like to release part of their windows driver code as free software sometimes it s not even possible sometimes windows and linux teams never talk to each other sometimes they just don t care either way our lofty goal of making the ir so much easier and quicker to adopt took a pretty severe beating it s especially disappointing since if you look at some of the documentation e g for amd intermediate language you ll notice that this stuff is essentially direct3d assembly which is essentially tgsi and most of the parts that are in amd il and not in tgsi are parts that will be added to tgsi so they have this code in the case of amd it s even sadder because the crucial code that we need for opencl right now is opencl c tgsi llvm backend which amd already does for their il some poor schmuck will have to sit down and write more less the same code of course if it s going to be me it s poor insanely handsome and definitely not a schmuck so we re left with free software developers who don t have access to the direct3d functional spec and who are being confused by the ir which is unlike anything they ve seen pre declared registers typeless which on top of it is not easily transformable tgsi is very readable simple and pretty easy to debug though so it s not all negative it s also great if you never have to optimize or transform its structure which unfortunately is rather rare if we abandon the hope of having the code from windows drivers injected in the gnu linux drivers it becomes pretty clear that we could do better than tgsi personally i just abhor the idea of rolling out our own ir ir in the true sense of that word crazy as it may sound i d really like my compiler stuff to be written by compiler experts it s the main reason why i really like the idea of using llvm ir as our ir ultimately it s all kind of taking the science out of computer science because it s very speculative we know amd and nvidia use it to some extend and there s an open ptx backend for llvm we like it we use it in some places llvmpipe the people behind llvm are great and know their stuff but how hard is it to use llvm ir as the main ir in a graphics framework and how hard is it to code generate directly from it for gpus we don t really know it seems like a really good idea good enough for folks from lunarg to give it a try which i think is really what we need a proof that it is possible and doesn t require sacrificing any farm animals which as a vegetarian i d be firmly against posted by zack at 10 28 2010 10 12 00 pm 10 comments email this blogthis share to x share to facebook share to pinterest labels gallium3d gpgpu graphics llvm thursday july 01 2010 graphics drivers there are only two tasks harder than writing free software graphics drivers one is running a successful crocodile petting zoo the other is wireless bungee jumping in general writing graphics drivers is hard the number of people who can actually do it is very small and the ones who can do it well are usually doing it full time already unless the company which those folks are working for supports open drivers the earliest someone can start working on open drivers is the day the hardware is officially available that s already about 2 years too late mayb...