Hi, all
The commit
commit 63e7a4c6e5bf51d8090046ebc5adcb4207448565
Author: José Fonseca jfons...@vmware.com
Date: Wed Nov 9 10:20:51 2011 +
mesa,glsl,mapi: Put extern C { ... } where appropriate.
Probably a several places missing, but enough to cover all headers
(in)directly
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the buffer is created.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 43 +++--
1 files changed, 40
On 12/05/2011 11:38 PM, Eric Anholt wrote:
On Mon, 05 Dec 2011 15:21:57 +0100, Thomas Hellstromthellst...@vmware.com
wrote:
Hi!
Currently the DRI state tracker sends the bits per pixel (bpp) value in
the format member of a
getbufferswithformat request, and assumes it can reinterpret the
On 12/06/2011 02:00 PM, Christoph Bumiller wrote:
On 12/06/2011 10:19 AM, Thomas Hellstrom wrote:
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the buffer is created.
Signed-off-by: Thomas Hellstromthellst...@vmware.com
On 12/06/2011 11:54 AM, Michel Dänzer wrote:
On Die, 2011-12-06 at 10:19 +0100, Thomas Hellstrom wrote:
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the buffer is created.
Signed-off-by: Thomas Hellstromthellst
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the buffer is created.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 43 +++--
1 files changed, 40
On 12/06/2011 07:58 PM, Eric Anholt wrote:
On Tue, 6 Dec 2011 16:44:30 +, Dave Airlieairl...@gmail.com wrote:
Hi,
So GLX has a rule about not swapping pixmaps, and I've been trying to
track down why with DRI2 my driver gets requests for swapping pixmaps
(piglit glx-swap-pixmap test).
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the buffer is created.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 41 ++--
1 files changed, 38
On 12/06/2011 06:51 PM, Brian Paul wrote:
Hi Thomas,
Just a couple nit-picky things below:
OK, sent out a v3.
/Thomas
On 12/06/2011 10:32 AM, Thomas Hellstrom wrote:
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when
The X server has limited throttle support on the server side,
but doing this in the client has some benefits:
1) X server throttling is per client. Client side throttling can be done
per drawable.
2) It's easier to control the throttling based on what client is run,
for example using driconf.
Hi!
If we want to add optional driver stuff, like throttling, to a state
tracker, what's the best way to do that?
I was thinking of either adding a new throttling member to the drm
driver_descriptor?
Any suggestions?
/Thomas
___
mesa-dev
) X server throttling requires drm swap complete events.
So implement a dri2 throttling extension intended to be used by direct
rendering clients.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/GL/internal/dri_interface.h | 22 ++
src/glx/dri2_glx.c
But don't hook it up just yet until we figure out a good way to do that.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
.../state_trackers/dri/common/dri_drawable.c | 126 +++-
.../state_trackers/dri/common/dri_drawable.h | 12 ++-
2 files changed, 136
Needed for throttling.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/winsys/svga/drm/vmw_context.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_context.c
b/src/gallium/winsys/svga/drm/vmw_context.c
index
Adds a possibility for the state tracker manager to query the
target for a specific configuration.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/include/state_tracker/drm_driver.h| 47 -
src/gallium/targets/dri-i915/target.c |2
Returns a configuration that makes the dri state-tracker-manager
throttle.
Also disable kernel-based throttling.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/targets/dri-vmwgfx/target.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff
Thanks for reviewing, Michel.
On 10/11/2011 05:29 PM, Michel Dänzer wrote:
On Die, 2011-10-11 at 15:44 +0200, Thomas Hellstrom wrote:
The X server has limited throttle support on the server side,
but doing this in the client has some benefits:
1) X server throttling is per client. Client
) X server throttling requires drm swap complete events.
So implement a dri2 throttling extension intended to be used by direct
rendering clients.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/GL/internal/dri_interface.h | 22 ++
src/glx/dri2_glx.c
On 10/13/2011 02:04 PM, Jakob Bornecrantz wrote:
- Original Message -
Adds a possibility for the state tracker manager to query the
target for a specific configuration.
All these patches looks good. There is one thing I'm wondering, is there
really a driconf option exposed
On 10/12/2010 03:12 PM, Jakob Bornecrantz wrote:
On 12 okt 2010, at 15.09, Thomas Hellstrom wrote:
Module: Mesa
Branch: 7.9
Commit: 6730630804b6948dbb42340b1de1cf9ee04bf0fd
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=6730630804b6948dbb42340b1de1cf9ee04bf0fd
Author: Thomas
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/mesa/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index c41c38c..7a6936e 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -34,7 +34,7 @@ ES1_CPPFLAGS
On 10/15/2010 01:15 AM, Stephan Raue wrote:
Hi,
i crosscompiling Mesa-7.9. if xorg-server-1.9 already installed in
toolchain (headers, libs) and i (re)build Mesa it fails. if i remove the
devel packages from toolchain and build xorg-server again after Mesa it
compiles:
On 10/15/2010 03:26 PM, Stephan Raue wrote:
Hi Thomas,
Am 15.10.2010 09:46, schrieb Thomas Hellstrom:
On 10/15/2010 01:15 AM, Stephan Raue wrote:
Hi,
i crosscompiling Mesa-7.9. if xorg-server-1.9 already installed in
toolchain (headers, libs) and i (re)build Mesa it fails
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/mesa/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index c41c38c..7a6936e 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -34,7 +34,7 @@ ES1_CPPFLAGS
On 10/19/2010 01:55 PM, Julien Cristau wrote:
On Tue, Oct 19, 2010 at 13:31:35 +0200, Thomas Hellstrom wrote:
Hi!
I've been trying to send a patch to mesa-dev a couple of times using
git send-email, but the message never makes it to the list. Am I the
only one having trouble
These are build fixups for crosscompiling builds
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/mesa/Makefile |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index 7a6936e..8b0756b 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -35,8 +35,8
Hmm,
for the uninformed, where do we need to use spinlocks in gallium and how do
we avoid using them on an UP system?
/Thomas
On 12/14/2010 02:15 PM, Marek Olšák wrote:
---
src/gallium/auxiliary/os/os_thread.h | 51 ++
1 files changed, 51 insertions(+), 0
On 12/15/2010 09:23 AM, Marek Olšák wrote:
On Tue, Dec 14, 2010 at 8:10 PM, Thomas Hellstrom
thellst...@vmware.com mailto:thellst...@vmware.com wrote:
Hmm,
for the uninformed, where do we need to use spinlocks in gallium
and how do
we avoid using them on an UP system?
I plan
OK, Some info to back this up, please see inline.
On 12/15/2010 01:20 PM, Thomas Hellstrom wrote:
On 12/15/2010 09:23 AM, Marek Olšák wrote:
On Tue, Dec 14, 2010 at 8:10 PM, Thomas Hellstrom
thellst...@vmware.com mailto:thellst...@vmware.com wrote:
Hmm,
for the uninformed, where do
Hi!
I have a couple of quick EGL questions that I hope someone knows the
answer to:
1) I'm trying to test the vmwgfx_dri driver with EGL driver egl_dri2,
platform drm, but it doesn't seem like this
configuration supports EGL_MESA_screen_surface so basically all relevant
EGL demos fail. Is
On 02/09/2012 03:18 PM, Benjamin Franzke wrote:
2012/2/9 Thomas Hellstromthellst...@vmware.com:
Hi!
I have a couple of quick EGL questions that I hope someone knows the answer
to:
1) I'm trying to test the vmwgfx_dri driver with EGL driver egl_dri2,
platform drm, but it doesn't seem like this
Hi, Chia-I,
Looking at the EGL DRM implementation of swapbuffers, it looks like
we're sort of ad-hoc attaching the backbuffer as a new scanout surface,
using drmModeSetCrtc.
I don't think this works very well on all hardware. In particular, I
think drmModeSetCrtc may return before the swap
On 02/22/2011 07:44 PM, Chia-I Wu wrote:
On Tue, Feb 22, 2011 at 1:56 AM, Thomas Hellstromtho...@shipmail.org wrote:
Hi, Chia-I,
Looking at the EGL DRM implementation of swapbuffers, it looks like we're
sort of ad-hoc attaching the backbuffer as a new scanout surface, using
Use the pageflip ioctl when available.
Otherwise, or when the backbuffer contents need to be preserved,
fall back to a copy operation.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/egl/drm/modeset.c| 37 ++
src/gallium
This patch series addresses a problem with DRM EGL where the swapbuffer
implementation does not sync with the rendering pipeline. It does so by
implementing swapbuffers either as a DRM pageflip or as a gallium blit.
It also adds swapbuffer throttling in the gallium case to improve
interactivity
This makes it usable also for native helpers.
Also add inline functions to access the context and to
uninit the native display structure.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/egl/common/egl_g3d.c|3 --
src/gallium/state_trackers/egl/common
The copy swap can be used when we need to preserve the contents of
the back buffer or when there is no way to do native page-flipping.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
.../state_trackers/egl/common/native_helper.c | 41
.../state_trackers/egl
will never get called, and googleearth will still show random triangles
with svga.
What usage of new_array causes saurebraten to brake? Is it safe to use
the real value to determine whether to call redefine_user_buffers?
Thanks,
Thomas
Marek
On Mon, Mar 7, 2011 at 11:24 AM, Thomas Hellstrom
On 03/08/2011 05:11 PM, José Fonseca wrote:
On Mon, 2011-03-07 at 02:38 -0800, Keith Whitwell wrote:
On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
2) is_resource_referenced
Now that the transfer functions are in pipe_context, is this hook
really
necessary?
Good
On 03/08/2011 11:22 PM, Marek Olšák wrote:
On Tue, Mar 8, 2011 at 10:17 PM, Thomas Hellstrom
thellst...@vmware.com mailto:thellst...@vmware.com wrote:
On 03/08/2011 05:11 PM, José Fonseca wrote:
On Mon, 2011-03-07 at 02:38 -0800, Keith Whitwell wrote:
On Sun, 2011-03
Hi,
I've been working a bit on optimizing uploads of non-vbo vertex arrays
on the svga device.
Since we have no knowledge of the vertex array size before a draw call
and the vertex array may change values in between subsequent draw calls
it's pretty pointless to upload the whole array to gpu
On 03/11/2011 12:03 AM, Marek Olšák wrote:
On Thu, Mar 10, 2011 at 11:45 PM, Thomas Hellstrom
thellst...@vmware.com mailto:thellst...@vmware.com wrote:
Hi,
I've been working a bit on optimizing uploads of non-vbo vertex
arrays on the svga device.
Since we have no knowledge
On 03/10/2011 04:57 PM, José Fonseca wrote:
On Thu, 2011-03-10 at 06:01 -0800, Thomas Hellstrom wrote:
Make sure that the upload manager doesn't upload data that's not
dirty. This speeds up the viewperf test proe-04/1 a factor 5 or so on svga.
Sweet!
A few comments inline
Also
Hi,
I'm not sure when this use of drawable - context bindings started, but
the below commit uses an invalid assumption to fix a problem the root
cause of which is also an invalid assumption.
It's incorrect to associate a drawable with a context.
A drawable may have multiple contexts bound to
On 05/24/2011 12:13 PM, Jakob Bornecrantz wrote:
On Tue, May 24, 2011 at 11:53 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
Hi,
I'm not sure when this use of drawable- context bindings started, but the
below commit uses an invalid assumption to fix a problem the root cause of
which
Hi!
While trying to improve the vmwgfx X driver to better cope with OpenGL
compositors, I noticed that compiz never calls glxWaitX() to make sure
the pixmaps that it textures from are updated.
Since we migrate X rendered data to the dri2 drawables only on demand,
we miss a lot of data.
On 06/06/2011 05:20 PM, James Jones wrote:
On 6/6/11 2:09 AM, Thomas Hellstromthellst...@vmware.com wrote:
Hi!
While trying to improve the vmwgfx X driver to better cope with OpenGL
compositors, I noticed that compiz never calls glxWaitX() to make sure
the pixmaps that it textures from
Hi!
I just pushed an initial commit of an X Acceleration state tracker to
the xa_branch.
The idea is that in the long run it will be replacing the Xorg state
tracker, which can then move back to a modular xf86-video-modesetting.
It will also be responsible for the acceleration part of an
all
contexts binding to a drawable.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/include/state_tracker/st_api.h | 26 ++-
.../state_trackers/dri/common/dri_drawable.c |3 +
src/gallium/state_trackers/dri/drm/dri2.c |4 +-
src/gallium
It's incorrect to assume a single context bound to a drawable.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
.../state_trackers/dri/common/dri_context.c|4
.../state_trackers/dri/common/dri_drawable.h |1 -
2 files changed, 0 insertions(+), 5 deletions
On 06/28/2011 04:27 PM, Jose Fonseca wrote:
Looks good to me Thomas.
Jose
Jakob pointed out that the state trackers (vega mesa) will actually
create a window system draw buffer / framebuffer per context, even if
they represent the same window system drawable, so I need to do some
all
contexts binding to a drawable
Note that the state trackers themselves don't use atomic stamps on
frame-buffers. Multiple context rendering to the same drawable should
be protected by the application.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/include/state_tracker
Jon,
Thanks for pointing this out. I apparently missed at least one case.
I'll fix ASAP.
/Thomas
On 06/29/2011 02:20 PM, Jon TURNEY wrote:
On 28/06/2011 13:19, Thomas Hellstrom wrote:
The api and the state tracker manager code as well as the state tracker code
assumed that only a single
From: José Fonseca jfons...@vmware.com
Also, only flush when going from HW TNL to SW TNL, given it is impossible
for the buffers resulting from SWTNL to be ever referred by HW TNL path.
---
src/gallium/drivers/svga/svga_context.h |3 ---
src/gallium/drivers/svga/svga_pipe_draw.c | 23
can basically reuse the
upload buffer across flushes.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/auxiliary/util/u_upload_mgr.c | 35 +---
src/gallium/auxiliary/util/u_upload_mgr.h | 20 +---
2 files changed, 42 insertions(+), 13
This enables us to pack more data into single upload buffers.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/drivers/svga/svga_context.c |8
src/gallium/drivers/svga/svga_draw.c|4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git
Stream user buffer contents rather than trying to maintain persistent
host / hardware copies.
Resulting negative array offsets are not allowed by the hardware,
(well, at least not according to header files), so adjust index bias
to make all array offsets positive.
Signed-off-by: Thomas Hellstrom
From: José Fonseca jfons...@vmware.com
---
src/gallium/drivers/svga/svga_resource_buffer.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_resource_buffer.h
b/src/gallium/drivers/svga/svga_resource_buffer.h
index 2ae44d2..69d6f72
From: Brian Paul bri...@vmware.com
Viewperf uses some unusual vertex arrays where the stride is less
than the element size. In this case, the stride was 4 while the
element size was 12. The difference of 8 bytes causes us to miss
uploading the tail bit of the array data.
Typically the stride
From: Brian Paul bri...@vmware.com
See preceeding commit for more info.
---
src/gallium/drivers/svga/svga_pipe_draw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_draw.c
b/src/gallium/drivers/svga/svga_pipe_draw.c
index
If a user-buffer was referenced twice by a draw command, the affected ranges
were uploaded separately, with only the last one being referenced by the
hardware. Make sure we upload only a single range.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/drivers/svga
Hmm.
Forgive my ignorance, but isn't memcmp() on structs pretty prone to give
incorrect != results, given that there may be padding between members in
structs and that IIRC gcc struct assignment is member-wise.
What happens if there's padding between the jit_context and variant
members of
Hi!
I'm planning to merge the xa_branch to master. Let me know if there are
any objections.
Thanks,
Thomas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/glx/xlib/xm_api.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
b/src/gallium/state_trackers/glx/xlib/xm_api.c
index 1be6dd9..8f6406d
https://bugs.freedesktop.org/show_bug.cgi?id=38988
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/mesa/state_tracker/st_manager.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker
Hi!
I'm not completely sure what's the correct list for this nowadays, so
forgive me for crossposting.
I've got an interesting problem in that when any dri2 operations are
carried out while the X server is switched away, they are pushed all the
way down to the kernel graphics driver, which
Hi!
As discussed also offline, this is not a good thing to do, for the
following reasons:
1) The bo handle does not necessarily represent a gem object. Calling
gem_flink on such a handle is illegal.
2) Dumb bos and BO_USE_RENDERING may be totally different objects.
It's incorrect to assume
On 10/08/2013 12:48 AM, christopher.halse.rog...@canonical.com wrote:
This is a prerequisite for the Mir EGL platform, which I'm sure everyone is
excited about.
It's also necessary for Wayland hybrid graphics support.
Sorry for replying this late, I just started looking at this patch series.
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
From: Thomas Hellstrom thellst...@vmware.com
This needs a prime-aware vmwgfx kernel module to work properly.
(With additions by Christopher James Halse Rogers r...@ubuntu.com)
Signed-off-by: Thomas Hellstrom thellst
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
From: Christopher James Halse Rogers r...@ubuntu.com
Otherwise the default is TYPE_SHARED, which will flink the bo. This seems
rather unnecessary for a simple stride query.
Is there no way we can cache this stuff in a
for patch 3
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 11/25/2013 05:06 AM, Christopher James Halse Rogers wrote:
On Thu, 2013-11-21 at 14:12 +0100, Thomas Hellstrom wrote:
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
From: Christopher James Halse Rogers r...@ubuntu.com
Otherwise the default is TYPE_SHARED, which
On 11/25/2013 05:38 AM, Ben Skeggs wrote:
On Mon, Nov 25, 2013 at 1:57 PM,
christopher.halse.rog...@canonical.com wrote:
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
http://cgit.freedesktop.org/~keithp/mesa/log/?h=dri3
Ben,
Christopher's patches have apparently
The dri2 state tracker is checking for driver support before enabling
dri2ImageExtension version 7. This commit adds a check that also the
kernel driver supports fd sharing through prime.
Note that this adds a libdrm dependency on dri2.c.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
This avoids the kernel driver spewing out errors about the param not being
supported.
Also correct the max surface size used when the kernel does not support the
query.
Reported-by: Brian Paul bri...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Reviewed-by: Charmaine Lee
This is to avoid running out of query buffer space due to winsys
limitations.
Reported-and-tested-by: Brian Paul bri...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa_sta...@lists.freedesktop.org
---
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 14
This is to avoid running out of query buffer space due to winsys
limitations.
v2: Correct email addresses.
Reported-and-tested-by: Brian Paul bri...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/winsys/svga/drm
On 04/01/2014 06:18 PM, Rob Clark wrote:
On Tue, Apr 1, 2014 at 12:14 PM, Zack Rusin za...@vmware.com wrote:
- Original Message -
From: Rob Clark robcl...@freedesktop.org
While still more of a stop-gap solution (until glamor) for freedreno,
with these few relatively simple changes I
documentation and log message.
Reported-and-tested-by: Brian Paul bri...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 18 +-
1 file changed, 13 insertions(+), 5
, yuv);
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
@@ renderer_bind_destination(struct xa_context *r,
struct pipe_framebuffer_state fb;
struct pipe_viewport_state viewport;
+xa_scissor_reset(r);
+
/* Framebuffer uses actual surface width/height
*/
memset(fb, 0, sizeof fb);
Otherwise,
Reviewed-by: Thomas Hellstrom
On 04/01/2014 05:04 PM, Rob Clark wrote:
From: Rob Clark robcl...@freedesktop.org
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling
On 04/02/2014 04:40 PM, Rob Clark wrote:
On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom thellst...@vmware.com
wrote:
On 04/01/2014 05:04 PM, Rob Clark wrote:
From: Rob Clark robcl...@freedesktop.org
Otherwise it will trick the gallium driver into thinking that the render
target has
On 04/01/2014 05:04 PM, Rob Clark wrote:
From: Rob Clark robcl...@freedesktop.org
Add support to property handle solid-fill src and/or mask. Without this
we fallback to sw a lot for common things like text rendering.
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
-by: Thomas Hellstrom thellst...@vmware.com
---
configure.ac |1 +
src/gallium/state_trackers/xa/xa_tracker.h| 200 -
src/gallium/state_trackers/xa/xa_tracker.h.in | 200 +
3 files changed, 201 insertions(+), 200
On 04/03/2014 04:49 PM, Rob Clark wrote:
On Thu, Apr 3, 2014 at 2:05 AM, Thomas Hellstrom thellst...@vmware.com
wrote:
The xa version number had to be set in two places. In configure.ac and in
xa_tracker.h. Furthermore, xa_tracker.h is an installed header so we can't
use mesa internal
NAK!
No generic mmap() APIs of GBM bos, please.
The reason is that this impossible to implement in an efficient way on
non-coherent architectures, and once the interface is there, people will
start using it and ignore the non-coherent architectures. And these
will, in the end, have to implement
On 04/04/2014 12:13 PM, Emil Velikov wrote:
On 03/04/14 07:05, Thomas Hellstrom wrote:
The xa version number had to be set in two places. In configure.ac and in
xa_tracker.h. Furthermore, xa_tracker.h is an installed header so we can't
use mesa internal defines. So therefore, at configure time
-curr.sampler_views[i]-texture;
struct svga_texture *stex = svga_texture(tex);
SVGA3dSurfaceFormat format = stex-key.format;
Looks good otherwise
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
/Thomas
___
mesa-dev mailing list
mesa-dev
Cc: 10.1 mesa-sta...@lists.freedesktop.org
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
b/src/gallium/winsys/svga/drm
Implement guest-backed surface sharing using prime fds. Previously only
legacy surfaces could use this functionality. Also use the vmwgfx 2.6
single-ioctl prime fd reference if available.
Cc: 10.1 mesa-sta...@lists.freedesktop.org
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src
be a valid reason for the svga driver to emit partially set up
state, but to avoid future uncertainties, make sure this doesn't happen
anyway.
Found while auditing the state tracker for inconsistent sampler state /
sampler view setup.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src
,
xa_tracker.h is an installed header and thus must include the correct
defines.
(see my commit message).
If we don't parse it using autoconf, we need to use sed or some other
tool to
fix the header.
Otherwise Acked-by: Thomas Hellstrom thellst...@vmware.com
/Thomas
This reverts commit
,
and we should move the version definitions to a build system
independent file (similar to VERSION) once any of the other two
decide to join the fun.
Cc: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Hi!
nak.
The users of libxatracker expects
On 04/07/2014 02:49 PM, Emil Velikov wrote:
On 07/04/14 10:50, Thomas Hellstrom wrote:
Cc: 10.1 mesa-sta...@lists.freedesktop.org
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Rather silly question:
Why do you guys pull this header inside mesa and over using the one provided
renderer_copy_prepare was setting the first sampler but never telling
the cso code how many samplers were actually used. Fix this.
Cc: 10.1 mesa-sta...@freedesktop.org
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/xa/xa_renderer.c | 5 +++--
1 file changed
Hi!
Thanks, This looks good to me.
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
/Thomas
On 04/07/2014 03:45 PM, Emil Velikov wrote:
This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c.
As the header is the one defining the API/ABI and is distributed
during installation, we
On 04/08/2014 10:28 PM, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Changes from previous version:
- make it clearer that the interface is optional;
No! this is still a NAK!
The reason is, just like the last time, that as soon
On 04/03/2014 04:07 PM, Brian Paul wrote:
On 04/02/2014 11:17 PM, Thomas Hellstrom wrote:
On 04/01/2014 05:04 PM, Rob Clark wrote:
From: Rob Clark robcl...@freedesktop.org
Add support to property handle solid-fill src and/or mask. Without
this
we fallback to sw a lot for common things like
1 - 100 of 349 matches
Mail list logo
