Max Staudt writes:
> Low-spec'd platforms such as the Raspberry Pi tend to run out of VRAM
> since GLAMOR only frees its BO cache once it grows beyond 1 GB.
>
> These patches reduce the cache and also flush it more often (based on
> BO age and GL_OUT_OF_MEMORY).
>
>
> Is there a reason why GLAMOR
On Fri, 2016-07-01 at 12:34 +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes incorrect clipping for redirected windows which don't happen to be
> located at the top left corner of the screen.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96742
> Signed-off-by: Michel Dänz
On Tue, 2016-07-12 at 15:56 +0200, Michael Thayer wrote:
> I know it has just been two days, but still, a polite ping. I would
> also generally be interested in the question of what I can do to get
> this sort of patch moving. Would reviewing other people's patches be
> the right way to go, o
This error code can mean we're submitting more rects at once than the
driver can handle. If that happens, resubmit one at a time.
Signed-off-by: Adam Jackson
---
hw/xfree86/drivers/modesetting/driver.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/xfree86/drivers/modesettin
On Fri, 2016-07-08 at 16:09 +0200, Arnaud Vrac wrote:
> From: Arnaud Vrac
This all looks great, thanks. Merged with a typo fix in one of the
commit messages:
remote: I: patch #97826 updated using rev
68300f92f3686ecea239d5050d604463cb3be2ca.
remote: I: patch #97832 updated using rev
d88c5544b7
On Tue, 2016-07-12 at 15:55 -0700, Keith Packard wrote:
> Adam Jackson writes:
>
> > The original list is just whatever readdir() gave us, filtered to match
> > *_drv.so (although doing that bit with regex instead of glob because
> > why not). Which is how I found the bug in the first place: if y
On Fri, Jul 15, 2016 at 10:57:04AM -0400, Adam Jackson wrote:
> On Wed, 2016-07-13 at 10:57 -0500, Andrew Eikum wrote:
> > Ping, anyone had a chance to look at this?
>
> remote: I: patch #97386 updated using rev
> 4926845a57fa8b53e18ea7d3434bf5539e9b7782.
> remote: I: 1 patch(es) updated to state
On Wed, 2016-07-13 at 10:57 -0500, Andrew Eikum wrote:
> Ping, anyone had a chance to look at this?
remote: I: patch #97386 updated using rev
4926845a57fa8b53e18ea7d3434bf5539e9b7782.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
9fcb554..49268
On Thu, 2016-07-14 at 08:54 +0800, Jonas Ådahl wrote:
> Reviewed-by: Jonas Ådahl
Thanks.
remote: I: patch #97873 updated using rev
9fcb554e9bfdf3eed2c2250d89150e3e7b907f01.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
cf6730c..9fcb554 mast
On Thu, 2016-07-14 at 08:41 +0800, Jonas Ådahl wrote:
> On Wed, Jul 13, 2016 at 07:19:09PM +0200, Rui Matos wrote:
> > Otherwise if the geometry changes but the mode doesn't we end up
> > with
> > the previous geometry from RR's point of view.
> >
> > Fixes https://bugzilla.gnome.org/show_bug.cgi?
On Fri, 2016-07-15 at 09:30 -0400, Alex Deucher wrote:
> On Tue, Jun 28, 2016 at 4:22 AM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > Some games incorrectly use non-premultiplied ARGB cursor data, presumably
> > because that's what Windows uses. On some hardware (and with SWcursor),
> >
Deduplify code and make sure glamor_priv->tick++ actually happens.
This ensures that GLAMOR's BO cache is expunged every now and then
even if it's not full yet.
Note: glamor_block_handler() contains both lines removed in this
change, so the old functionality persists.
Signed-off-by: Max Staudt
If we run out of memory, we have most likely hogged it with our huge
cache. DRI drivers flush their caches in OOM situations, so we should
do so, too.
NOTE: This may still not free the memory we need as the DRI drivers
typically have a time delay until they actually release the buffers
that GLAMOR
With the previous size, we would quickly accumulate >1GB of unused
memory.
This was because the code didn't take into account:
- Pixels usually take 4 bytes these days, not 1 byte.
- BOs are allocated larger than the actual width*height used.
- Few GPUs have this much VRAM and the cache easily
Low-spec'd platforms such as the Raspberry Pi tend to run out of VRAM
since GLAMOR only frees its BO cache once it grows beyond 1 GB.
These patches reduce the cache and also flush it more often (based on
BO age and GL_OUT_OF_MEMORY).
Is there a reason why GLAMOR's cache was set at 1 GB in size?
Signed-off-by: Max Staudt
---
glamor/glamor_fbo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index b27f652..733c3a8 100644
--- a/glamor/glamor_fbo.c
+++ b/glamor/glamor_fbo.c
@@ -164,7 +164,7 @@ glamor_pixmap_fbo_cache_put(glamor_
On Tue, Jun 28, 2016 at 4:22 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Some games incorrectly use non-premultiplied ARGB cursor data, presumably
> because that's what Windows uses. On some hardware (and with SWcursor),
> this breaks areas of the cursor which are supposed to be transparen
On Fri, Jul 15, 2016 at 1:17 PM, Pekka Paalanen wrote:
> wl_output interface version 1 does not have a 'done' event. Is that
> case handled somehow?
xwayland only binds if the interface is version 2.
Rui
___
xorg-devel@lists.x.org: X.Org development
Ar
On Wed, 13 Jul 2016 19:19:09 +0200
Rui Matos wrote:
> Otherwise if the geometry changes but the mode doesn't we end up with
> the previous geometry from RR's point of view.
>
> Fixes https://bugzilla.gnome.org/show_bug.cgi?id=768710
>
> Signed-off-by: Rui Matos
> ---
> hw/xwayland/xwayland-ou
19 matches
Mail list logo
