summaryrefslogtreecommitdiff
path: root/uxa/uxa-priv.h
AgeCommit message (Collapse)Author
2012-09-27Remove the last couple of references to mibstoreChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2012-06-05uxa: drop enable disable access hookDave Airlie
This looks to be unused. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-23intel: add compat header file for conversion fnsDave Airlie
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-03-23uxa: Remove hook for CompositeRectanglesChris Wilson
It was broken and not flushing damage correctly. With the improvements made to the kernel, it is no longer a significant advantage per se and not worth its additional complexity. Reported-by: Tilman Sauerbeck <tilman@code-monkey.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32547 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-12-28uxa: Remove concept of global FB ownership made obsolete by GEM and KMSChris Wilson
With the introduction of GEM, we can continue to submit batch buffers irrespective of ownership of the console, so do so. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-12-14uxa/glamor: Enable the rest of the glamor rendering routinesZhigang Gong
This commit hooks up all the remaining rendering routines to call into glamor; the takeover is nearly complete! When tested with the latest glamor master branch, it passes rendercheck. One thing need to be pointed out is the picture's handling. Pictures support many different color formats, but glamor's texture only support a few color formats. And the most common scenario is that we create a pixmap with a color depth and then attach it to a picture which has a specific color format with the same color depth. But there is no way to change a texture's internal format after the texture was allocated. If you do that, the OpenGL will allocate a new texture. And then the glamor side and UXA side will be inconsitent. So for all the picture related operations, we can't fallback to UXA path directly, even it is rather a straight forward operation. So for the get_image, Addtraps.., we have to add wrappers function for them to jump into glamor firstly. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com> [ickle: prefer access; ok = glamor(); finish; if (!ok) goto fallback; return; ] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-11-16uxa/glamor: Introduce additional access modes to wrap glamor accelerationZhigang Gong
Integrate glamor acceleration into UXA framework. Add necessary flushing at the following points: 1. Flush UXA batch buffer before call into glamor. 2. Flush GL operations after return from a glamor function. 3. The point we need to flush UXA batch buffer, we also need to flush GL operations, for example, in intel_flush_callback and couple of places in intel_display.c. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-11-04uxa: Ensure that alphaMaps are mapped into the CPU for fallbacksChris Wilson
Reported-by: Hans-Peter Budek <peter.budek@gmx.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-01-24uxa: Only recreate the glyph cache on *generational* updatesChris Wilson
The screen resources are recreated when the screen is rotated as well, without being finalized. In this case, we do not need to reconstuct the cache (or if we did, we would need to tear it down first). Reported-by: Till Matthiesen <entropy@everymail.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33412 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-07-09Purge macro NEED_EVENTSFernando Carrijo
Signed-off-by: Fernando Carrijo <fcarrijo@yahoo.com.br> Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2010-06-19uxa: Enable SHM pixmapsChris Wilson
Now with streaming uploads and downloads for composite operations in place, shared memory pixmaps are no longer that dire performance wise. With careful use these can in fact be the most efficient means of transfer between a wholly software renderer in the client and a backing store. For instance, Chromium renders internally to an ARGB32 image buffer and uses a shared pixmap to composite dirty regions into the backing store. Thereby using the GPU to either perform the blit or the format conversion. Enabling shared pixmaps, reduces our CPU overhead whilst scrolling by a factor of 5 or so. And this is achieved simply by deleting obsolete code! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-06-07Use the direct dixGevPrivate() API when availableChris Wilson
This is quicker and smaller than the old indirect function call to dixLookupPrivate(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-06-06Adapt to DevPrivate API changesKeith Packard
This allows the driver to be built against either the old or new DevPrivate API. Signed-off-by: Keith Packard <keithp@keithp.com>
2010-05-31Disable acceleration if we detect a hardware error.Chris Wilson
This is wildly optimistic, but it should work in a surprising number of error situations and some output in those cases will be hopefully be better than none... If we submit a batchbuffer and the kernel reports the GPU is hung (which will be caused by an earlier execbuffer, and so the kernel should have had enough time to determine whether or not it could reset the GPU) then disable any further attempt to accelerate gfx and force fallbacks to map the buffers and use the CPU. We cannot normally map any more buffers if the GPU is hung, so only those already mapped prior to the hang can be written to, or those allocated in system memory. However, we can expect that the framebuffer is already mapped, and so have a reasonable expectation to continue to see the display update. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-05-31uxa: Mega-Glyphs!Chris Wilson
Rewrite glyph rendering to avoid the intermediate buffer, accumulating the glyph rectangles directly in the backend composite routines. And modify the glyph cache routines to fully utilise the allocated size of the tiled buffer on older hardware. To do this we alias all glyph sizes into the same texture using a technique suggested by Keith Packard. PineView: 885/856-> 1150/1110 kglyph/s (aa/rgb) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-05-28uxa: Make the glyph caches' fixed size explicit.Chris Wilson
Until we actual resize the glyph cache dynamically, make it obvious to the reader and the compiler that the size is fixed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-05-28uxa: Use a glyph private rather than a hash table.Chris Wilson
Store the cache position directly on the glyph using a devPrivate rather than an through auxiliary hash table. x11perf on PineView: 650/638 kglyphs/s -> 701/686 kglyphs/s [aa/rgb] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-05-24uxa: Composite glyphs directly onto dst when possible.Chris Wilson
Without using a mask and compositing directly onto the destination, takes us from 580 kglyphs/s to 850 kglyphs/s on i945 [x11perf -aa10text]. However, the extra intersection check almost entirely cancels out the speed up and we discover that the glyphs in x11perf are always overlapping. Nothing is ever easy. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-05-23uxa: Spans! OMG!Chris Wilson
Use composite rather than solid blits in order to bring performance on a par with the CPU when using GEM and relocations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-05-12uxa: solid rectsChris Wilson
The cost of performing relocations outweigh the advantages of using the blitter for solids with lots of rectangles. References: Bug 22127 - [UXA] 50% performance regression for XRenderFillRectangles https://bugs.freedesktop.org/show_bug.cgi?id=22127 By using the 3D pipeline we improve our performance by around 4x on i945, measured by the jxbench microbenchmark, and a factor of 10x by short-cutting to the 3D pipeline for blended rectangles. Before, on a i945GME: 19982.412060 Ops/s; rects (!); 15x15 9599.131693 Ops/s; rects (!); 75x75 3803.654743 Ops/s; rects (!); 250x250 6836.743772 Ops/s; rects blended; 15x15 1443.750000 Ops/s; rects blended; 75x75 495.335821 Ops/s; rects blended; 250x250 23247.933884 Ops/s; rects composition (!); 15x15 10993.073048 Ops/s; rects composition (!); 75x75 3595.905172 Ops/s; rects composition (!); 250x250 After: 87271.145975 Ops/s; rects (!); 15x15 32347.744361 Ops/s; rects (!); 75x75 5884.177215 Ops/s; rects (!); 250x250 73500.000000 Ops/s; rects blended; 15x15 33580.882353 Ops/s; rects blended; 75x75 5858.811749 Ops/s; rects blended; 250x250 25582.317073 Ops/s; rects composition (!); 15x15 6664.728682 Ops/s; rects composition (!); 75x75 14965.909091 Ops/s; rects composition (!); 250x250 [suspicious] This has no impact on Cairo, but I have a suspicion from watching xtrace that Qt likes to blit thousands of 1x1 rectangles with the same colour. However, we are still around 2-3x slower than the reported figures for EXA! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2009-12-07uxa: Cache solid fills.Chris Wilson
Maintain a small cache of pixmaps to hold SolidFill pictures. Currently we create a pixmap the size of the damaged region and fill that using pixman before downloading it to the GPU and compositing. Needless to say this is extremely expensive compared to simply emitting the solid colour. To mitigate this cost, we maintain a small cache of 1x1R pictures which is recognised by the driver as being a solid, but at the very least is maintained as a GPU ready pixmap. This gives a good boost to cairo-xcb (which uses solid fills) on a gm45: Before: gnome-terminal-vim: 41.9s After: gnome-terminal-vim: 31.7s Compare with using a cache of 1x1R pixmaps in cairo-xcb: gnome-terminal-vim: 31.6s Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2009-10-06Move to kernel coding style.Eric Anholt
We've talked about doing this since the start of the project, putting it off until "some convenient time". Just after removing a third of the driver seems like a convenient time, when backporting's probably not happening much anyway.
2009-08-25Fix SHM functions to work with server after 1.6.0Keith Packard
Signed-off-by: Keith Packard <keithp@keithp.com>
2009-07-18Update to xextproto 7.1 support.Peter Hutterer
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers need to include dpmsconst.h if xextproto 7.1 is available. SHM is now shm.h instead of shmstr. Requires definition of ShmFuncs that's not exported by the server. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2009-04-27Remove pre-server-1.5 support.Eric Anholt
2009-04-24Fix UXA to build with Sun compilers (use __func__ instead of __FUNCTION__)Alan Coopersmith
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
2009-02-26Fix UXA for server 1.4.Eric Anholt
2009-02-10uxa: Fix breakage from UXA_FALLBACK conversion from "do {} while (0)" construct.Eric Anholt
Thanks to keithp for post-commit review.
2009-02-10uxa: Fix driver against fbDoCopy -> miDoCopy change in the server.Eric Anholt
2009-02-10uxa: hook up the fallback debug to the driver's fallback debug option.Eric Anholt
2009-01-06uxa: handle uxa_prepare_access failureKeith Packard
uxa_prepare_access may fail to map the pixmap into user space. Recover from this without crashing. Signed-off-by: Keith Packard <keithp@keithp.com>
2008-12-05uxa: Add in EnableDisableFBAccess handling like examodule.c did.Eric Anholt
This fixes assertion failures when rendering text while VT switched.
2008-08-26Change uxa private keys to integer variables.Eamon Walsh
Prepares for a devPrivates system that will store an index.
2008-08-05Rename uxa using _ instead of capsKeith Packard
2008-08-05Change PrepareAccess to take access mode rather than indexKeith Packard
2008-08-05Add UXA - the unified memory acceleration architecture.Keith Packard
This eliminates the cost of EXA migration management while providing full pixmap allocation control to the driver. The goal is to make something useful for UMA drivers.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 01:59:37 +0000