search for: screen's

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 23 +++++--- src/gallium/drivers/nouveau/nv50/nv50_context.c | 4 +- src/gallium/drivers/nouveau/nv50/nv50_scre...

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 23 +++++--- src/gallium/drivers/nouveau/nv50/nv50_context.c | 4 +- src/gallium/drivers/nouveau/nv50/nv50_screen.c...

...anonical.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 14 +- src/gallium/drivers/nouveau/nouveau_context.h | 5 + src/gallium/drivers/nouveau/nouveau_fence.c | 10 + src/gallium/drivers/nouveau/nouveau_fence.h | 6 +- src/gallium/drivers/nouveau/nouveau_screen.c | 16 -- src/gallium/drivers/nouveau/nouveau_screen.h | 5 - src/gallium/drivers/nouveau/nv30/nv30_context.c | 104 +++++++-- src/gallium/drivers/nouveau/nv30/nv30_context.h | 2 + src/gallium/drivers/nouveau/nv30/nv30_draw.c | 4 +- src/gallium/drivers/nouveau/nv30...

...mewhat consistent way with the device being cleaned up in one place or another but not both? On Thu, Nov 26, 2015 at 8:04 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > From: Ben Skeggs <bskeggs at redhat.com> > > The winsys layer would attempt to cleanup the nouveau_device if screen > init failed, however, in most paths the pipe driver would have already > destroyed it, resulting in accesses to freed memory etc. > > This commit fixes the problem by allowing the winsys to detect whether > the pipe driver's destroy function needs to be called or not. > >...

...done in the commit description, as well as what the "new way" is (if any) for the various concepts. This change doesn't have any of the locking -- is that coming in a future change? Otherwise we're still vulnerable to multiple threads trying to render at the same time. (Now with screen sharing, even if they end up with separate screens, we'd still be in trouble.) I'm still a bit concerned with moving the fence stuff to the context... there might be an assumption in gallium that fences are context-independent, in which case you need to make sure to have just a single fenc...

- unreference state objects so that buffer objects are unreferenced and eventually destroyed - free channel at screen's destruction Index: nv50/nv50_screen.c =================================================================== --- nv50/nv50_screen.c (wersja 32083) +++ nv50/nv50_screen.c (kopia robocza) @@ -162,7 +162,22 @@ nv50_screen_destroy(struct pipe_screen *pscreen) { struct nv50_screen *screen = n...

...5 01:40 PM, Ilia Mirkin wrote: >> This all seems very roundabout... Can't we do this in a somewhat >> consistent way with the device being cleaned up in one place or >> another but not both? > That would be lovely, but not possible. It has to be cleaned up by the > pipe screen destroy() function, as that's the normal exit path. If the > pipe driver creation path fails before it's got a struct, then the > winsys will have to clean up after itself instead. Couldn't you make the pipe_screen_create() function destroy the device in all failure paths? >...

Full_Name: Steve Koehler Version: 1.8.1 OS: Solaris and Windows Submission from: (NULL) (192.55.214.50) In the following program, if output is sent to X11, you get all four graphs, but if output is sent to .jpeg, you only get the C and D graphs. A workaround is to do all the screen splitting at the top, before using any screens. This also fails with .png output. jpeg ("test.jpeg") #x11() a <- split.screen (c(2, 1)) screen (a[1]) b <- split.screen (c(1, 2)) screen (b[1]) plot (1:10, main="a") screen (b[2]) plot (1:10, main="b")...

...what effect it has on their workloads, or if I messed something up. src/gallium/drivers/nouveau/nouveau_buffer.c | 29 +++++++++-- src/gallium/drivers/nouveau/nouveau_fence.c | 18 +++++++ src/gallium/drivers/nouveau/nouveau_fence.h | 5 +- src/gallium/drivers/nouveau/nouveau_screen.c | 12 ++++- src/gallium/drivers/nouveau/nouveau_screen.h | 3 ++ src/gallium/drivers/nouveau/nv50/nv50_compute.c | 4 ++ src/gallium/drivers/nouveau/nv50/nv50_context.c | 11 +++++ src/gallium/drivers/nouveau/nv50/nv50_context.h | 5 ++ src/gallium/drivers/nouveau/nv50/nv5...

This series is to allow NVIDIA chips with shared memory to operate more efficiently (and to operate at all once we disable VRAM from the kernel driver) by allowing nouveau_screen to specify a domain to use for objects originally allocated into VRAM. If the domain is not overridden, the default NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be used in place of NOUVEAU_BO_VRAM when allocating objects, so the right domain for the chip is used. Doing s...

From: Ben Skeggs <bskeggs at redhat.com> The winsys layer would attempt to cleanup the nouveau_device if screen init failed, however, in most paths the pipe driver would have already destroyed it, resulting in accesses to freed memory etc. This commit fixes the problem by allowing the winsys to detect whether the pipe driver's destroy function needs to be called or not. Signed-off-by: Ben Skeggs <bs...

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

On 12/07/2015 01:40 PM, Ilia Mirkin wrote: > This all seems very roundabout... Can't we do this in a somewhat > consistent way with the device being cleaned up in one place or > another but not both? That would be lovely, but not possible. It has to be cleaned up by the pipe screen destroy() function, as that's the normal exit path. If the pipe driver creation path fails before it's got a struct, then the winsys will have to clean up after itself instead. > > On Thu, Nov 26, 2015 at 8:04 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> From: Ben Sk...

nouveau_fence_wait has the expectation that an external entity is holding onto the fence being waited on, not that it is merely held onto by the current pointer. Fixes a use-after-free in nouveau_fence_wait when used on the screen's current fence. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75279 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Should the waiting be predicated on the current fence having been emitted? I removed that from nv30 (which would just go ahead and _leak_ that fence it...

From: Ben Skeggs <bskeggs at redhat.com> v2. forgot bump for non-gallium driver Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b6680d0..965c6f7 100644 --- a/configure.ac +++ b/configure.ac @@ -72,8 +72,8 @@ LIBDRM_REQUIRED=2.4.60

Please see the Ubuntu bug report for photographs and logs of this problem "Clipped area for multiple X screens with different dimensions": https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/331918 Thanks to some great support and suggestions in #compiz-fusion-dev I've made some progress in trying to pin this issue down. I've operated with compiz and multiple X screens for about 2 years,...

...c/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 8 ++++---- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 12 ++++++------ src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 2 +- src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 2 +- 11 files chang...

Hi, I want to connect to my server, run screen as root and then let another person log in a root also and let him run screen and attach to mine so he can "see" what im doing on the server. I haven't played with screen a lot but it seems a nice feature to teach him how to configure certain things. Sorry for the newbie question. th...

...u/nvc0/nvc0_compute.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 ++-- > src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 8 ++++---- > src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 12 ++++++------ > src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nve4_compute.c...