Re: [Mesa-dev] [PATCH] gallium/vl: remove remaining softpipe video functions

2014-02-13 Thread Maarten Lankhorst

Hey,

On 11-02-14 11:57, Christian König wrote:

From: Christian König christian.koe...@amd.com

Unused and unmaintained for quite a while.


Good riddance!

Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Maarten Lankhorst

Hey,

On 11-02-14 05:26, Emil Velikov wrote:

Hello list,

The recent patches from Rob gave me a nice kick to give another stab at
integrating the pipe-loader into the vdpau/dri targets.

What:
  - With these patches one library will be created for hardware and one for
software driven backends - eg. libvdpau_gallium_dri, libvdpau_gallium_sw
  - Each library can use every possible pipe driver, determined at runtime.
  - To get the dri (galliumdrm_dri) or vdpau library working create hardlink
(or symlink) to it (libvdpau_nouveau.so - libvdpau_gallium_dri.so)

Why:
  - Smaller overall size while having no extra exported symbols. This is
a nice method of us to share most of gallium (read mesagallium and
aux/gallium) without exporting every symbol either one to those two contain.
  - Drop the multiple duplicated
  - With those done, some additional symbol cleanup can be made using the
linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
libaries.

Thanks, I've been meaning to do his myself but didn't find the time yet.
Up until 7/13 look good at least. and 11 looks like it could be 
committed too.


The rest would need some more testing than simply reviewing the code and 
looking for obvious bugs. :-)


Would it help to change the vdpau abi? I have a patch in my vdpau loader 
to look for an entry point similar to the one used in megadrivers, but 
it could be changed to add the name of the library too as argument.

What has been tested:
  - (st/dri) nouveau and swrast were spinning glxgears and nouveau was
glretrace-ing lol, dota2 and portal traces.
  - (st/vdpau) nouveau - tested using mplayer in benchmark mode. no
significant changes were noticed. swrast was broken while using vdpau,
as to why it was dropped a while back.

swrast never worked right with vdpau, good riddance. :-)

What has not been tested/known to be broken:
  - (st/dri) currently the drm_configuration() and the driver options
(__dri2ConfigOptions) are not wired up.
  - (st/vdpau) the driver specific create_winsys are not exported by the
vdpau library, thus gl-vdpau interop is not tested and possibly broken.
If pipe-loader is used for dri, then that problem will fix itself 
without needing exports. ;-)

  - Resolve all the linking between the library and all backends
nouveau_dri.so - galliumdrm_dri.so
  - Scons and drivers having multiple winsys (i915)

In the weeks ahead:
  - Cleanup/resolve the above issues
  - Tackle the remaining two st (omx and xvmc), which should be trivial.
  - Compact the dri/drm and dri/sw state-trackers into a single library.


Please let me know how you feel on the subject, and as ususal some
testing including opencl, gbm, egl and gl-vdpau interop would be greatly
appreciated.

Hooray, removing all duplication is a good thing!

The complete patchset can be found in the pipe-loader-to-all branch over at
https://github.com/evelikov/Mesa/

Note: the first 10 patches should be fine as is as.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] nv50: make sure to clear _all_ layers of all attachments

2014-02-13 Thread Ilia Mirkin
Unfortunately there's only one RT_ARRAY_MODE setting for all
attachments, so clears were previously truncated to the minimum number
of layers any attachment had. Instead set the RT_ARRAY_MODE to 512 (the
max number of layers) before doing the clear. This fixes
gl-3.2-layered-rendering-clear-color-mismatched-layer-count.

Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---

Haven't had a chance to do a full piglit run on this yet, but it does fix the
failing test. Have a look. I'm not sure if zeta can have layers, it seems like
a couple of things assumed it couldn't. I've changed that assumption around.

 src/gallium/drivers/nouveau/nv50/nv50_context.h   |  2 ++
 .../drivers/nouveau/nv50/nv50_state_validate.c|  1 +
 src/gallium/drivers/nouveau/nv50/nv50_surface.c   | 19 +--
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.h 
b/src/gallium/drivers/nouveau/nv50/nv50_context.h
index 57a3090..84ff46e 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_context.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_context.h
@@ -173,6 +173,8 @@ struct nv50_context {
 
boolean vbo_push_hint;
 
+   uint32_t rt_array_mode;
+
struct pipe_query *cond_query;
boolean cond_cond;
uint cond_mode;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c 
b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
index f953422..100d02d 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
@@ -65,6 +65,7 @@ nv50_validate_fb(struct nv50_context *nv50)
  PUSH_DATA (push, sf-height);
  BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
  PUSH_DATA (push, array_mode | array_size);
+ nv50-rt_array_mode = array_mode | array_size;
   } else {
  PUSH_DATA (push, 0);
  PUSH_DATA (push, 0);
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c 
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index a22436b..68924c9 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
@@ -303,7 +303,7 @@ nv50_clear_render_target(struct pipe_context *pipe,
   PUSH_DATA(push, NV50_3D_RT_HORIZ_LINEAR | mt-level[0].pitch);
PUSH_DATA (push, sf-height);
BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
-   PUSH_DATA (push, 1);
+   PUSH_DATA (push, 512);
 
if (!nouveau_bo_memtype(bo)) {
   BEGIN_NV04(push, NV50_3D(ZETA_ENABLE), 1);
@@ -366,7 +366,7 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
PUSH_DATA (push, bo-offset + sf-offset);
PUSH_DATA (push, nv50_format_table[dst-format].rt);
PUSH_DATA (push, mt-level[sf-base.u.tex.level].tile_mode);
-   PUSH_DATA (push, 0);
+   PUSH_DATA (push, mt-layer_stride  2);
BEGIN_NV04(push, NV50_3D(ZETA_ENABLE), 1);
PUSH_DATA (push, 1);
BEGIN_NV04(push, NV50_3D(ZETA_HORIZ), 3);
@@ -374,6 +374,9 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
PUSH_DATA (push, sf-height);
PUSH_DATA (push, (1  16) | 1);
 
+   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
+   PUSH_DATA (push, 512);
+
BEGIN_NV04(push, NV50_3D(VIEWPORT_HORIZ(0)), 2);
PUSH_DATA (push, (width  16) | dstx);
PUSH_DATA (push, (height  16) | dsty);
@@ -402,6 +405,14 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
if (!nv50_state_validate(nv50, NV50_NEW_FRAMEBUFFER, 9 + (fb-nr_cbufs * 
2)))
   return;
 
+   /* We have to clear ALL of the layers, not up to the min number of layers
+* of any attachment. Don't touch 3d textures, they can't be arrays. The
+* above nv50_state_validate call will have written to rt_array_mode. */
+   if (!(nv50-rt_array_mode  NV50_3D_RT_ARRAY_MODE_MODE_3D)) {
+  BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
+  PUSH_DATA (push, 512);
+   }
+
if (buffers  PIPE_CLEAR_COLOR  fb-nr_cbufs) {
   BEGIN_NV04(push, NV50_3D(CLEAR_COLOR(0)), 4);
   PUSH_DATAf(push, color-f[0]);
@@ -459,6 +470,10 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
 (j  NV50_3D_CLEAR_BUFFERS_LAYER__SHIFT));
   }
}
+
+   /* restore the array mode */
+   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
+   PUSH_DATA (push, nv50-rt_array_mode);
 }
 
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] glx/dri2: Respect --enable/disable-driglx-direct

2014-02-13 Thread Daniel Martin
Encapsulate the code in src/glx/dri2_query_renderer.c within a

#ifdef GLX_DIRECT_RENDERING

as done in src/glx/dri2*.c.

Signed-off-by: Daniel Martin consume.no...@gmail.com
---
... compile it, when enabled only.

Cheers,
Daniel

 src/glx/dri2_query_renderer.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/glx/dri2_query_renderer.c b/src/glx/dri2_query_renderer.c
index b50a202..3bc90c7 100644
--- a/src/glx/dri2_query_renderer.c
+++ b/src/glx/dri2_query_renderer.c
@@ -20,6 +20,9 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  * DEALINGS IN THE SOFTWARE.
  */
+
+#ifdef GLX_DIRECT_RENDERING
+
 #include glxclient.h
 #include glx_error.h
 #include xf86drm.h
@@ -95,3 +98,5 @@ dri2_query_renderer_string(struct glx_screen *base, int 
attribute,
 
return psc-rendererQuery-queryString(psc-driScreen, dri_attribute, 
value);
 }
+
+#endif /* GLX_DIRECT_RENDERING */
-- 
1.7.2.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Maarten Lankhorst

op 11-02-14 11:30, Christian König schreef:

Am 11.02.2014 05:26, schrieb Emil Velikov:

Hello list,

The recent patches from Rob gave me a nice kick to give another stab at
integrating the pipe-loader into the vdpau/dri targets.

What:
  - With these patches one library will be created for hardware and one for
software driven backends - eg. libvdpau_gallium_dri, libvdpau_gallium_sw


Just drop, the software driven backends. I was about to remove them anyway.


  - Each library can use every possible pipe driver, determined at runtime.
  - To get the dri (galliumdrm_dri) or vdpau library working create hardlink
(or symlink) to it (libvdpau_nouveau.so - libvdpau_gallium_dri.so)

Why:
  - Smaller overall size while having no extra exported symbols. This is
a nice method of us to share most of gallium (read mesagallium and
aux/gallium) without exporting every symbol either one to those two contain.
  - Drop the multiple duplicated
  - With those done, some additional symbol cleanup can be made using the
linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
libaries.


NAK, at least for the VDPAU drivers that doesn't sounds like such a good idea 
to me.

Reducing the number of exported symbols can be archived otherwise and giving up 
their self containing without any external dependencies just to save some extra 
space on disk doesn't sound like a valid reason to me.

This is a great idea. It doesn't just save diskspace, it also makes life for 
packagers easier. Right now I'm not packaging vdpau in ubuntu because of the 
extra disk space involved.
Not everyone can download packages with 10 mbit connections.

I really dislike building libgallium shared, so getting rid of that hack while 
keeping the size reduction is great. :-)

Preventing symbol clashing is easy by carefully choosing which symbols to 
export. And in the case of pipe-loader we would only need to export
very few, and those exports are very controlled. Even radeon_drm_winsys_create 
doesn't need to be exported any more if vdpau and dri use the same shared 
pipe-loader library.

~Maarten

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Christian König

Am 13.02.2014 12:28, schrieb Maarten Lankhorst:

op 11-02-14 11:30, Christian König schreef:

Am 11.02.2014 05:26, schrieb Emil Velikov:

Hello list,

The recent patches from Rob gave me a nice kick to give another stab at
integrating the pipe-loader into the vdpau/dri targets.

What:
  - With these patches one library will be created for hardware and 
one for
software driven backends - eg. libvdpau_gallium_dri, 
libvdpau_gallium_sw


Just drop, the software driven backends. I was about to remove them 
anyway.


  - Each library can use every possible pipe driver, determined at 
runtime.
  - To get the dri (galliumdrm_dri) or vdpau library working create 
hardlink

(or symlink) to it (libvdpau_nouveau.so - libvdpau_gallium_dri.so)

Why:
  - Smaller overall size while having no extra exported symbols. 
This is

a nice method of us to share most of gallium (read mesagallium and
aux/gallium) without exporting every symbol either one to those two 
contain.

  - Drop the multiple duplicated
  - With those done, some additional symbol cleanup can be made 
using the

linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
libaries.


NAK, at least for the VDPAU drivers that doesn't sounds like such a 
good idea to me.


Reducing the number of exported symbols can be archived otherwise and 
giving up their self containing without any external dependencies 
just to save some extra space on disk doesn't sound like a valid 
reason to me.
This is a great idea. It doesn't just save diskspace, it also makes 
life for packagers easier.


Please reconsider that for a moment, it means that we make the gallium 
pipe screen and context a public interface of a shared library.


That means we either need to put everything into a single package, make 
hard dependencies on the packages between each other or declare the pipe 
interfaces as stable. Neither of those options sounds like a good idea 
(ok, maybe putting everything into a single package).


Right now I'm not packaging vdpau in ubuntu because of the extra disk 
space involved.

Not everyone can download packages with 10 mbit connections.

I really dislike building libgallium shared, so getting rid of that 
hack while keeping the size reduction is great. :-)




Yeah, agree.

Preventing symbol clashing is easy by carefully choosing which symbols 
to export. And in the case of pipe-loader we would only need to export
very few, and those exports are very controlled. Even 
radeon_drm_winsys_create doesn't need to be exported any more if vdpau 
and dri use the same shared pipe-loader library.


Removing the unnecessary exported symbols is probably the better way to 
go, the last time I checked r600 had something ~200kb of actually binary 
and over 1mb of symbols.


Christian.



~Maarten



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nouveau: fix chipset checks for nv1a by using the oclass instead

2014-02-13 Thread Francisco Jerez
Ilia Mirkin imir...@alum.mit.edu writes:

 Commit f4ebcd133b9 (dri/nouveau: NV17_3D class is not available for
 NV1a chipset) fixed this partially by using the correct 3d class.
 However there were a lot of checks left over comparing against the
 chipset.

 Reported-and-tested-by: John F. Godfrey jfgodf...@gmail.com
 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 ---

 I guess I didn't have to change the = 0x11 checks, but seemed nicer for
 consistency.

Looks good to me,

Reviewed-by: Francisco Jerez curroje...@riseup.net


  src/mesa/drivers/dri/nouveau/nv10_context.c  | 8 
  src/mesa/drivers/dri/nouveau/nv10_state_fb.c | 4 ++--
  src/mesa/drivers/dri/nouveau/nv10_state_raster.c | 3 ++-
  3 files changed, 8 insertions(+), 7 deletions(-)

 diff --git a/src/mesa/drivers/dri/nouveau/nv10_context.c 
 b/src/mesa/drivers/dri/nouveau/nv10_context.c
 index 8582cb2..4773014 100644
 --- a/src/mesa/drivers/dri/nouveau/nv10_context.c
 +++ b/src/mesa/drivers/dri/nouveau/nv10_context.c
 @@ -63,7 +63,7 @@ nv10_use_viewport_zclear(struct gl_context *ctx)
   struct gl_framebuffer *fb = ctx-DrawBuffer;
   struct gl_renderbuffer *depthRb = 
 fb-Attachment[BUFFER_DEPTH].Renderbuffer;
  
 - return context_chipset(ctx)  0x17 
 + return context_eng3d(ctx)-oclass  NV17_3D_CLASS 
   !nctx-hierz.clear_blocked  depthRb 
   (_mesa_get_format_bits(depthRb-Format,
  GL_DEPTH_BITS) = 24);
 @@ -184,7 +184,7 @@ nv10_clear(struct gl_context *ctx, GLbitfield buffers)
   }
  
   if ((buffers  BUFFER_BIT_DEPTH)  ctx-Depth.Mask) {
 - if (context_chipset(ctx) = 0x17)
 + if (context_eng3d(ctx)-oclass = NV17_3D_CLASS)
   nv17_zclear(ctx, buffers);
   else
   nv10_zclear(ctx, buffers);
 @@ -245,7 +245,7 @@ nv10_hwctx_init(struct gl_context *ctx)
   BEGIN_NV04(push, NV04_GRAPH(3D, NOP), 1);
   PUSH_DATA (push, 0);
  
 - if (context_chipset(ctx) = 0x17) {
 + if (context_eng3d(ctx)-oclass = NV17_3D_CLASS) {
   BEGIN_NV04(push, NV17_3D(UNK01AC), 2);
   PUSH_DATA (push, fifo-vram);
   PUSH_DATA (push, fifo-vram);
 @@ -257,7 +257,7 @@ nv10_hwctx_init(struct gl_context *ctx)
   PUSH_DATA (push, 1);
   }
  
 - if (context_chipset(ctx) = 0x11) {
 + if (context_eng3d(ctx)-oclass = NV15_3D_CLASS) {
   BEGIN_NV04(push, SUBC_3D(0x120), 3);
   PUSH_DATA (push, 0);
   PUSH_DATA (push, 1);
 diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_fb.c 
 b/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
 index 19769e5..fb66b2d 100644
 --- a/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
 +++ b/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
 @@ -106,7 +106,7 @@ nv10_emit_framebuffer(struct gl_context *ctx, int emit)
  
   /* At least nv11 seems to get sad if we don't do this before
* swapping RTs.*/
 - if (context_chipset(ctx)  0x17) {
 + if (context_eng3d(ctx)-oclass  NV17_3D_CLASS) {
   int i;
  
   for (i = 0; i  6; i++) {
 @@ -140,7 +140,7 @@ nv10_emit_framebuffer(struct gl_context *ctx, int emit)
   PUSH_MTHDl(push, NV10_3D(ZETA_OFFSET), BUFCTX_FB,
s-bo, 0, bo_flags);
  
 - if (context_chipset(ctx) = 0x17) {
 + if (context_eng3d(ctx)-oclass = NV17_3D_CLASS) {
   setup_hierz_buffer(ctx);
   context_dirty(ctx, ZCLEAR);
   }
 diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c 
 b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
 index bd4a78e..da414a0 100644
 --- a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
 +++ b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
 @@ -28,6 +28,7 @@
  #include nouveau_context.h
  #include nouveau_gldefs.h
  #include nouveau_util.h
 +#include nv_object.xml.h
  #include nv10_3d.xml.h
  #include nv10_driver.h
  
 @@ -120,7 +121,7 @@ nv10_emit_logic_opcode(struct gl_context *ctx, int emit)
   struct nouveau_pushbuf *push = context_push(ctx);
  
   assert(!ctx-Color.ColorLogicOpEnabled
 -|| context_chipset(ctx) = 0x11);
 +|| context_eng3d(ctx)-oclass = NV15_3D_CLASS);
  
   BEGIN_NV04(push, NV11_3D(COLOR_LOGIC_OP_ENABLE), 2);
   PUSH_DATAb(push, ctx-Color.ColorLogicOpEnabled);
 -- 
 1.8.3.2


pgpsVV1Adc4H8.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] st/omx/dec/h264: fix pic_order_cnt_type==2

2014-02-13 Thread Christian König
From: Christian König christian.koe...@amd.com

Signed-off-by: Christian König christian.koe...@amd.com
---
 src/gallium/state_trackers/omx/vid_dec_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/omx/vid_dec_h264.c 
b/src/gallium/state_trackers/omx/vid_dec_h264.c
index 20a6d9f..5f4a261 100644
--- a/src/gallium/state_trackers/omx/vid_dec_h264.c
+++ b/src/gallium/state_trackers/omx/vid_dec_h264.c
@@ -308,7 +308,7 @@ static void seq_parameter_set(vid_dec_PrivateType *priv, 
struct vl_rbsp *rbsp)
 
if (sps-pic_order_cnt_type == 0)
   sps-log2_max_pic_order_cnt_lsb_minus4 = vl_rbsp_ue(rbsp);
-   else {
+   else if (sps-pic_order_cnt_type == 1) {
   sps-delta_pic_order_always_zero_flag = vl_rbsp_u(rbsp, 1);
 
   sps-offset_for_non_ref_pic = vl_rbsp_se(rbsp);
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Emil Velikov
On 13/02/14 11:48, Christian König wrote:
 Am 13.02.2014 12:28, schrieb Maarten Lankhorst:
 op 11-02-14 11:30, Christian König schreef:
 Am 11.02.2014 05:26, schrieb Emil Velikov:
 Hello list,

 The recent patches from Rob gave me a nice kick to give another stab at
 integrating the pipe-loader into the vdpau/dri targets.

 What:
   - With these patches one library will be created for hardware and
 one for
 software driven backends - eg. libvdpau_gallium_dri,
 libvdpau_gallium_sw

 Just drop, the software driven backends. I was about to remove them
 anyway.

   - Each library can use every possible pipe driver, determined at
 runtime.
   - To get the dri (galliumdrm_dri) or vdpau library working create
 hardlink
 (or symlink) to it (libvdpau_nouveau.so - libvdpau_gallium_dri.so)

 Why:
   - Smaller overall size while having no extra exported symbols.
 This is
 a nice method of us to share most of gallium (read mesagallium and
 aux/gallium) without exporting every symbol either one to those two
 contain.
   - Drop the multiple duplicated
   - With those done, some additional symbol cleanup can be made
 using the
 linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
 ~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
 libaries.

 NAK, at least for the VDPAU drivers that doesn't sounds like such a
 good idea to me.

 Reducing the number of exported symbols can be archived otherwise and
 giving up their self containing without any external dependencies
 just to save some extra space on disk doesn't sound like a valid
 reason to me.
 This is a great idea. It doesn't just save diskspace, it also makes
 life for packagers easier.
 
 Please reconsider that for a moment, it means that we make the gallium
 pipe screen and context a public interface of a shared library.
 
 That means we either need to put everything into a single package, make
 hard dependencies on the packages between each other or declare the pipe
 interfaces as stable. Neither of those options sounds like a good idea
 (ok, maybe putting everything into a single package).
 
Hmm the whole declare pipe interfaces as stable is currently implied
by it's current users - egl-static, gbm, opencl :)

But if people are not happy with that there is another solution
suggested by Jakob Bornecrantz on IRC - get all those pipe-drivers and
push them into a single blob which then we link against for each st to
create a megadriver target.

This will result in alot less space saving as the ~2MiB per driver will
be duplicated in - dri, vdpau, xvmc, younameit... but a very nice
approach to your concerns.

 Right now I'm not packaging vdpau in ubuntu because of the extra disk
 space involved.
 Not everyone can download packages with 10 mbit connections.

 I really dislike building libgallium shared, so getting rid of that
 hack while keeping the size reduction is great. :-)

 
 Yeah, agree.
 
Seconded

 Preventing symbol clashing is easy by carefully choosing which symbols
 to export. And in the case of pipe-loader we would only need to export
 very few, and those exports are very controlled. Even
 radeon_drm_winsys_create doesn't need to be exported any more if vdpau
 and dri use the same shared pipe-loader library.
 
 Removing the unnecessary exported symbols is probably the better way to
 go, the last time I checked r600 had something ~200kb of actually binary
 and over 1mb of symbols.
 
As you've noticed I've been that path, and static linking against LLVM
gave me a subtle kick in the nuts. The day when someone fixes that with
the LLVM people I'll be a happy bunny. I'm suspecting that's the reason
for the numbers you're quoting.

Btw, bringing back vdpau-softpipe was a very nice experiment to check if
I've piped all the functions correctly, than anything else.

-Emil
 Christian.
 

 ~Maarten

 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 10/13] pipe-loader: introduce pipe_loader_sw_probe_null helper function

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/gallium/auxiliary/pipe-loader/pipe_loader.h| 10 ++
  src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 18 +-
  2 files changed, 27 insertions(+), 1 deletion(-)

 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 index f5a7252..026f809 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 @@ -133,6 +133,16 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device 
 **devs,
  
  
  /**
 + * Initialize a null sw device.
 + *
 + * This function is platform-specific.
 + *
 + * \sa pipe_loader_probe
 + */
 +bool
 +pipe_loader_sw_probe_null(struct pipe_loader_device **devs);
 +
 +/**
   * Get a list of known software devices.
   *
   * This function is platform-specific.
 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 index 954e16e..618a911 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 @@ -85,7 +85,23 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device **devs, 
 struct drisw_loader_f
 return true;
  }
  
 -int
 +bool
 +pipe_loader_sw_probe_null(struct pipe_loader_device **devs)
 +{
 +   struct pipe_loader_sw_device *sdev = CALLOC_STRUCT(pipe_loader_sw_device);
 +
 +   if (!sdev)
 +  return false;
 +
 +   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
 +   sdev-base.driver_name = swrast;
 +   sdev-base.ops = pipe_loader_sw_ops;
 +   sdev-ws = null_sw_create();
 +   *devs = sdev-base;
 +
 +   return true;
 +}
 +

Missing return type here.

  pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev)
  {
 int i;

Maybe remove pipe_loader_sw_probe() altogether and change pipe_loader.c
to use pipe_loader_sw_probe_null() instead?

 -- 
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgpGZCsPbCULI.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/13] targets/pipe-loader: link pipe-nouveau against libdrm

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Reviewed-by: Francisco Jerez curroje...@riseup.net

 ---
  src/gallium/targets/pipe-loader/Makefile.am | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
 b/src/gallium/targets/pipe-loader/Makefile.am
 index 97733c1..cb2eff7 100644
 --- a/src/gallium/targets/pipe-loader/Makefile.am
 +++ b/src/gallium/targets/pipe-loader/Makefile.am
 @@ -72,6 +72,7 @@ pipe_nouveau_la_LIBADD = \
   $(PIPE_LIBS) \
   $(top_builddir)/src/gallium/winsys/nouveau/drm/libnouveaudrm.la \
   $(top_builddir)/src/gallium/drivers/nouveau/libnouveau.la \
 + $(LIBDRM_LIBS) \
   $(NOUVEAU_LIBS)
  pipe_nouveau_la_LDFLAGS = -no-undefined -avoid-version -module
  if HAVE_MESA_LLVM
 -- 
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgpQJKmZwRNjQ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 04/13] pipe-loader: build pipe_loader_drm_x_auth whenever HAVE_PIPE_LOADER_XCB is defined

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 Currently HAVE_PIPE_LOADER_XCB is defined, rather than being set to 1/0.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Reviewed-by: Francisco Jerez curroje...@riseup.net

 ---
  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 index d6869fd..16f8a58 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 @@ -62,7 +62,7 @@ static struct pipe_loader_ops pipe_loader_drm_ops;
  static void
  pipe_loader_drm_x_auth(int fd)
  {
 -#if HAVE_PIPE_LOADER_XCB
 +#ifdef HAVE_PIPE_LOADER_XCB
 /* Try authenticate with the X server to give us access to devices that X
  * is running on. */
 xcb_connection_t *xcb_conn;
 -- 
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgp2U049fwF_P.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 03/13] pipe-loader: destroy sw_winsys on sw_release

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 The sw pipe-loader implicitly handles winsys_create, thus we
 it would make sense to implicitly destroy it upon releasing
 the loader.

 Currently we leak the sw_winsys when releasing the pipe-loader.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Reviewed-by: Francisco Jerez curroje...@riseup.net

 ---
  src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 index 95a4f84..fd3d989 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 @@ -75,6 +75,9 @@ pipe_loader_sw_release(struct pipe_loader_device **dev)
  {
 struct pipe_loader_sw_device *sdev = pipe_loader_sw_device(*dev);
  
 +   if (sdev-ws  sdev-ws-destroy)
 +  sdev-ws-destroy(sdev-ws);
 +
 if (sdev-lib)
util_dl_close(sdev-lib);
  
 -- 
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgpUT4isPHYz_.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 07/13] pipe-loader: use bool type for pipe_loader_drm_probe_fd()

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Reviewed-by: Francisco Jerez curroje...@riseup.net

 ---
  src/gallium/auxiliary/pipe-loader/pipe_loader.h | 2 +-
  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 8 
  2 files changed, 5 insertions(+), 5 deletions(-)

 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 index e0525df..cc6b183 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 @@ -129,7 +129,7 @@ pipe_loader_drm_probe(struct pipe_loader_device **devs, 
 int ndev);
   *
   * \sa pipe_loader_probe
   */
 -boolean
 +bool
  pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd);
  
  #endif
 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 index c5f191f..f15d5c8 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 @@ -112,14 +112,14 @@ disconnect:
  #endif
  }
  
 -boolean
 +bool
  pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd)
  {
 struct pipe_loader_drm_device *ddev = 
 CALLOC_STRUCT(pipe_loader_drm_device);
 int vendor_id, chip_id;
  
 if (!ddev)
 -  return FALSE;
 +  return false;
  
 if (loader_get_pci_id_for_fd(fd, vendor_id, chip_id)) {
ddev-base.type = PIPE_LOADER_DEVICE_PCI;
 @@ -138,11 +138,11 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device 
 **dev, int fd)
goto fail;
  
 *dev = ddev-base;
 -   return TRUE;
 +   return true;
  
fail:
 FREE(ddev);
 -   return FALSE;
 +   return false;
  }
  
  static int
 -- 
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgpqMizAjKKwY.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 05/13] pipe-loader: handle memory allocation failure

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 3 +++
  src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c  | 1 +
  2 files changed, 4 insertions(+)

 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 index 16f8a58..c5f191f 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
 @@ -118,6 +118,9 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, 
 int fd)
 struct pipe_loader_drm_device *ddev = 
 CALLOC_STRUCT(pipe_loader_drm_device);
 int vendor_id, chip_id;
  
 +   if (!ddev)
 +  return FALSE;
 +
 if (loader_get_pci_id_for_fd(fd, vendor_id, chip_id)) {
ddev-base.type = PIPE_LOADER_DEVICE_PCI;
ddev-base.u.pci.vendor_id = vendor_id;
 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 index fd3d989..7f3f93b 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 @@ -58,6 +58,7 @@ pipe_loader_sw_probe(struct pipe_loader_device **devs, int 
 ndev)
 for (i = 0; i  Elements(backends); i++) {
if (i  ndev) {
   struct pipe_loader_sw_device *sdev = 
 CALLOC_STRUCT(pipe_loader_sw_device);
 +  /* TODO: handle CALLOC_STRUCT failure */

We could use separate counters for the backends[] and devs[] array, and
only increment the latter if the memory allocation/initialization
succeeds (and if 'i = ndev').  Or just get rid of this function.
Either way this patch is:

Reviewed-by: Francisco Jerez curroje...@riseup.net

  
   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
   sdev-base.driver_name = swrast;
 -- 
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgpnvKPp4nMuv.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 08/13] pipe-loader: introduce pipe_loader_sw_probe_xlib helper

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 Will be used in the upcoming patches.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/gallium/auxiliary/pipe-loader/Makefile.am  |  4 
  src/gallium/auxiliary/pipe-loader/pipe_loader.h| 19 +++
  src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 22 
 +++---
  3 files changed, 42 insertions(+), 3 deletions(-)

 diff --git a/src/gallium/auxiliary/pipe-loader/Makefile.am 
 b/src/gallium/auxiliary/pipe-loader/Makefile.am
 index 8e4d034..bcee58e 100644
 --- a/src/gallium/auxiliary/pipe-loader/Makefile.am
 +++ b/src/gallium/auxiliary/pipe-loader/Makefile.am
 @@ -8,6 +8,10 @@ AM_CPPFLAGS = $(DEFINES) \
   -I$(top_srcdir)/src/gallium/auxiliary \
   -I$(top_srcdir)/src/gallium/winsys
  
 +if NEED_WINSYS_XLIB
 +AM_CPPFLAGS += -DHAVE_WINSYS_XLIB
 +endif
 +
  noinst_LTLIBRARIES =
  
  if HAVE_LOADER_GALLIUM
 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 index cc6b183..1073dc4 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 @@ -34,6 +34,11 @@
  #define PIPE_LOADER_H
  
  #include pipe/p_compiler.h
 +#include stdbool.h
 +

I think this is already pulled in by the p_compiler.h include?

 +#ifdef HAVE_WINSYS_XLIB
 +#include X11/Xlib.h
 +#endif
  
  #ifdef __cplusplus
  extern C {
 @@ -100,6 +105,20 @@ pipe_loader_create_screen(struct pipe_loader_device *dev,
  void
  pipe_loader_release(struct pipe_loader_device **devs, int ndev);
  
 +#ifdef HAVE_WINSYS_XLIB
 +
 +/**
 + * Initialize Xlib for an associated display.
 + *
 + * This function is platform-specific.
 + *
 + * \sa pipe_loader_probe
 + */
 +bool
 +pipe_loader_sw_probe_xlib(struct pipe_loader_device **devs, Display 
 *display);
 +
 +#endif
 +
  /**
   * Get a list of known software devices.
   *
 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 index 90d2975..8cf8980 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 @@ -44,12 +44,28 @@ struct pipe_loader_sw_device {
  static struct pipe_loader_ops pipe_loader_sw_ops;
  
  static struct sw_winsys *(*backends[])() = {
 -#ifdef HAVE_WINSYS_XLIB
 -   x11_sw_create,
 -#endif
 null_sw_create
  };
  
 +#ifdef HAVE_WINSYS_XLIB
 +bool
 +pipe_loader_sw_probe_xlib(struct pipe_loader_device **devs, Display *display)
 +{
 +   struct pipe_loader_sw_device *sdev = CALLOC_STRUCT(pipe_loader_sw_device);
 +
 +   if (!sdev)
 +  return false;
 +
 +   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
 +   sdev-base.driver_name = swrast;
 +   sdev-base.ops = pipe_loader_sw_ops;
 +   sdev-ws = xlib_create_sw_winsys(display);

Shouldn't we handle failure here too?

 +   *devs = sdev-base;
 +
 +   return true;
 +}
 +#endif
 +
  int
  pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev)
  {
 -- 
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgp5YkJeyv2vT.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Christian König

Am 13.02.2014 13:20, schrieb Emil Velikov:

On 13/02/14 11:48, Christian König wrote:

Am 13.02.2014 12:28, schrieb Maarten Lankhorst:

op 11-02-14 11:30, Christian König schreef:

Am 11.02.2014 05:26, schrieb Emil Velikov:

Hello list,

The recent patches from Rob gave me a nice kick to give another stab at
integrating the pipe-loader into the vdpau/dri targets.

What:
   - With these patches one library will be created for hardware and
one for
software driven backends - eg. libvdpau_gallium_dri,
libvdpau_gallium_sw

Just drop, the software driven backends. I was about to remove them
anyway.


   - Each library can use every possible pipe driver, determined at
runtime.
   - To get the dri (galliumdrm_dri) or vdpau library working create
hardlink
(or symlink) to it (libvdpau_nouveau.so - libvdpau_gallium_dri.so)

Why:
   - Smaller overall size while having no extra exported symbols.
This is
a nice method of us to share most of gallium (read mesagallium and
aux/gallium) without exporting every symbol either one to those two
contain.
   - Drop the multiple duplicated
   - With those done, some additional symbol cleanup can be made
using the
linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
libaries.

NAK, at least for the VDPAU drivers that doesn't sounds like such a
good idea to me.

Reducing the number of exported symbols can be archived otherwise and
giving up their self containing without any external dependencies
just to save some extra space on disk doesn't sound like a valid
reason to me.

This is a great idea. It doesn't just save diskspace, it also makes
life for packagers easier.

Please reconsider that for a moment, it means that we make the gallium
pipe screen and context a public interface of a shared library.

That means we either need to put everything into a single package, make
hard dependencies on the packages between each other or declare the pipe
interfaces as stable. Neither of those options sounds like a good idea
(ok, maybe putting everything into a single package).


Hmm the whole declare pipe interfaces as stable is currently implied
by it's current users - egl-static, gbm, opencl :)

But if people are not happy with that there is another solution
suggested by Jakob Bornecrantz on IRC - get all those pipe-drivers and
push them into a single blob which then we link against for each st to
create a megadriver target.

This will result in alot less space saving as the ~2MiB per driver will
be duplicated in - dri, vdpau, xvmc, younameit... but a very nice
approach to your concerns.


Yeah that sounds better, but I would still like to avoid this altogether.


Preventing symbol clashing is easy by carefully choosing which symbols
to export. And in the case of pipe-loader we would only need to export
very few, and those exports are very controlled. Even
radeon_drm_winsys_create doesn't need to be exported any more if vdpau
and dri use the same shared pipe-loader library.

Removing the unnecessary exported symbols is probably the better way to
go, the last time I checked r600 had something ~200kb of actually binary
and over 1mb of symbols.


As you've noticed I've been that path, and static linking against LLVM
gave me a subtle kick in the nuts. The day when someone fixes that with
the LLVM people I'll be a happy bunny. I'm suspecting that's the reason
for the numbers you're quoting.


Taking a closer look I would rather suspect that we have an issue with 
the build system here. I've just finished building 
libvdpau_radeonsi.so.1.0.0 from a complete clean checkout with the 
following configure options:


./configure --with-dri-drivers= --with-gallium-drivers=radeonsi 
--enable-vdpau --with-llvm-prefix=/usr/src/llvm/Debug+Asserts/ 
--with-llvm-shared-libs --disable-dri3 --disable-debug


The resulting binary is something like 11M in size, but applying strip 
libvdpau_radeonsi.so.1.0.0 reduces it's size to only 2.2M. Taking a 
closer look it looks like even with --disable-debug we are building 
debugging symbols into it.


That's not necessary an issue for packaging, cause distributions usually 
separate the debugging symbols anyway, but it still looks odd to me.


Christian.


Btw, bringing back vdpau-softpipe was a very nice experiment to check if
I've piped all the functions correctly, than anything else.

-Emil

Christian.


~Maarten



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] configure: Use pkg-config for libselinux

2014-02-13 Thread Kusanagi Kouichi
libselinux provides pkgconfig file since 2.0.89 (2009-10-29).

Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp
---
 configure.ac | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 00a0eaa..949aaa2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -506,12 +506,7 @@ AC_ARG_ENABLE([selinux],
 [MESA_SELINUX=$enableval],
 [MESA_SELINUX=no])
 if test x$enable_selinux = xyes; then
-AC_CHECK_HEADER([selinux/selinux.h],[],
-[AC_MSG_ERROR([SELinux headers not found])])
-AC_CHECK_LIB([selinux],[is_selinux_enabled],[],
- [AC_MSG_ERROR([SELinux library not found])])
-SELINUX_LIBS=-lselinux
-DEFINES=$DEFINES -DMESA_SELINUX
+PKG_CHECK_MODULES([SELINUX], [libselinux], [DEFINES=$DEFINES 
-DMESA_SELINUX])
 fi
 AC_SUBST([SELINUX_LIBS])
 
-- 
1.9.0.rc3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCHv3 1/4] pipe-loader: split out client version

2014-02-13 Thread Emil Velikov
On 11/02/14 23:51, Rob Clark wrote:
 From: Rob Clark robcl...@freedesktop.org
 
 Build two versions of pipe-loader, with only the client version linking
 in x11 client side dependencies.  This will allow the XA state tracker
 to use pipe-loader.
 
 Signed-off-by: Rob Clark robcl...@freedesktop.org
 ---
  configure.ac   | 14 +++--
  src/gallium/auxiliary/pipe-loader/Makefile.am  | 24 
 ++
  src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c |  2 ++
  src/gallium/targets/gbm/Makefile.am|  4 ++--
  src/gallium/targets/opencl/Makefile.am |  4 ++--
  src/gallium/tests/trivial/Makefile.am  |  4 ++--
  6 files changed, 40 insertions(+), 12 deletions(-)
 
[snip]
 diff --git a/src/gallium/targets/opencl/Makefile.am 
 b/src/gallium/targets/opencl/Makefile.am
 index 653302c..a75b49c 100644
 --- a/src/gallium/targets/opencl/Makefile.am
 +++ b/src/gallium/targets/opencl/Makefile.am
 @@ -7,11 +7,11 @@ lib@OPENCL_LIBNAME@_la_LDFLAGS = \
   -version-number 1:0
  
  lib@OPENCL_LIBNAME@_la_LIBADD = \
 - $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \
 + 
 $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la \
   $(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
   $(top_builddir)/src/gallium/state_trackers/clover/libclover.la \
   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
 - $(GALLIUM_PIPE_LOADER_LIBS) $(LIBUDEV_LIBS) \
 + $(GALLIUM_PIPE_LOADER_CLIENT_LIBS) $(LIBUDEV_LIBS) \
 
I've nuked all libudev references outside of src/loader recently. Keep
an eye open during rebase

-Emil

   -ldl \
   -lclangCodeGen \
   -lclangFrontendTool \
 diff --git a/src/gallium/tests/trivial/Makefile.am 
 b/src/gallium/tests/trivial/Makefile.am
 index d65eb86..65fa90d 100644
 --- a/src/gallium/tests/trivial/Makefile.am
 +++ b/src/gallium/tests/trivial/Makefile.am
 @@ -11,8 +11,8 @@ AM_CPPFLAGS = \
   -DPIPE_SEARCH_DIR=\$(PIPE_SRC_DIR)/.libs\ \
   $(GALLIUM_PIPE_LOADER_DEFINES)
  
 -LDADD = $(GALLIUM_PIPE_LOADER_LIBS) \
 - $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \
 +LDADD = $(GALLIUM_PIPE_LOADER_CLIENT_LIBS) \
 + 
 $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la \
   $(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
   $(LIBUDEV_LIBS) \
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Maarten Lankhorst

op 13-02-14 14:14, Christian König schreef:

Am 13.02.2014 13:20, schrieb Emil Velikov:

On 13/02/14 11:48, Christian König wrote:

Am 13.02.2014 12:28, schrieb Maarten Lankhorst:

op 11-02-14 11:30, Christian König schreef:

Am 11.02.2014 05:26, schrieb Emil Velikov:

Hello list,

The recent patches from Rob gave me a nice kick to give another stab at
integrating the pipe-loader into the vdpau/dri targets.

What:
   - With these patches one library will be created for hardware and
one for
software driven backends - eg. libvdpau_gallium_dri,
libvdpau_gallium_sw

Just drop, the software driven backends. I was about to remove them
anyway.


   - Each library can use every possible pipe driver, determined at
runtime.
   - To get the dri (galliumdrm_dri) or vdpau library working create
hardlink
(or symlink) to it (libvdpau_nouveau.so - libvdpau_gallium_dri.so)

Why:
   - Smaller overall size while having no extra exported symbols.
This is
a nice method of us to share most of gallium (read mesagallium and
aux/gallium) without exporting every symbol either one to those two
contain.
   - Drop the multiple duplicated
   - With those done, some additional symbol cleanup can be made
using the
linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
libaries.

NAK, at least for the VDPAU drivers that doesn't sounds like such a
good idea to me.

Reducing the number of exported symbols can be archived otherwise and
giving up their self containing without any external dependencies
just to save some extra space on disk doesn't sound like a valid
reason to me.

This is a great idea. It doesn't just save diskspace, it also makes
life for packagers easier.

Please reconsider that for a moment, it means that we make the gallium
pipe screen and context a public interface of a shared library.

That means we either need to put everything into a single package, make
hard dependencies on the packages between each other or declare the pipe
interfaces as stable. Neither of those options sounds like a good idea
(ok, maybe putting everything into a single package).


Hmm the whole declare pipe interfaces as stable is currently implied
by it's current users - egl-static, gbm, opencl :)

But if people are not happy with that there is another solution
suggested by Jakob Bornecrantz on IRC - get all those pipe-drivers and
push them into a single blob which then we link against for each st to
create a megadriver target.

This will result in alot less space saving as the ~2MiB per driver will
be duplicated in - dri, vdpau, xvmc, younameit... but a very nice
approach to your concerns.


Yeah that sounds better, but I would still like to avoid this altogether.

I already did the megablob approach, it works but it's nasty. :-)

Disabling the megablob resulted in even bigger binaries if linking statically,
or nasty makefile hacks to handle building the !megablob case.
If we go down this path I would rather not support !megablob building any more.


Preventing symbol clashing is easy by carefully choosing which symbols
to export. And in the case of pipe-loader we would only need to export
very few, and those exports are very controlled. Even
radeon_drm_winsys_create doesn't need to be exported any more if vdpau
and dri use the same shared pipe-loader library.

Removing the unnecessary exported symbols is probably the better way to
go, the last time I checked r600 had something ~200kb of actually binary
and over 1mb of symbols.


As you've noticed I've been that path, and static linking against LLVM
gave me a subtle kick in the nuts. The day when someone fixes that with
the LLVM people I'll be a happy bunny. I'm suspecting that's the reason
for the numbers you're quoting.


Taking a closer look I would rather suspect that we have an issue with the 
build system here. I've just finished building libvdpau_radeonsi.so.1.0.0 from 
a complete clean checkout with the following configure options:

./configure --with-dri-drivers= --with-gallium-drivers=radeonsi --enable-vdpau 
--with-llvm-prefix=/usr/src/llvm/Debug+Asserts/ --with-llvm-shared-libs 
--disable-dri3 --disable-debug

The resulting binary is something like 11M in size, but applying strip 
libvdpau_radeonsi.so.1.0.0 reduces it's size to only 2.2M. Taking a closer look it looks like 
even with --disable-debug we are building debugging symbols into it.
That's not necessary an issue for packaging, cause distributions usually 
separate the debugging symbols anyway, but it still looks odd to me.

--disable-debug is used by distro builds, so having the debug symbols still 
available is still required. I would rather have --enable-debug stop fiddling 
with CFLAGS, so it doesn't revert to -g -O0, that is weirder to be honest. :-)

~Maarten

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCHv3 2/4] st/xa: use pipe-loader to get screen

2014-02-13 Thread Emil Velikov
On 11/02/14 23:51, Rob Clark wrote:
 From: Rob Clark robcl...@freedesktop.org
 
 This lets multiple gallium drivers use XA.
 
 Signed-off-by: Rob Clark robcl...@freedesktop.org
 ---
  configure.ac   |  9 +--
  src/gallium/auxiliary/pipe-loader/Makefile.am  |  1 -
  src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c |  2 -
  src/gallium/state_trackers/xa/Makefile.am  |  3 +
  src/gallium/state_trackers/xa/xa_priv.h|  1 +
  src/gallium/state_trackers/xa/xa_tracker.c |  7 ++-
  src/gallium/targets/Makefile.am|  8 +--
  src/gallium/targets/xa-vmwgfx/Makefile.am  | 61 
  src/gallium/targets/xa-vmwgfx/vmw_target.c | 26 -
  src/gallium/targets/xa-vmwgfx/xatracker.pc.in  |  9 ---
  src/gallium/targets/xa/Makefile.am | 67 
 ++
  src/gallium/targets/xa/xatracker.pc.in |  9 +++
  12 files changed, 95 insertions(+), 108 deletions(-)
  delete mode 100644 src/gallium/targets/xa-vmwgfx/Makefile.am
  delete mode 100644 src/gallium/targets/xa-vmwgfx/vmw_target.c
  delete mode 100644 src/gallium/targets/xa-vmwgfx/xatracker.pc.in
  create mode 100644 src/gallium/targets/xa/Makefile.am
  create mode 100644 src/gallium/targets/xa/xatracker.pc.in
 
 diff --git a/configure.ac b/configure.ac
 index cba6301..29ca954 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1270,6 +1270,7 @@ dnl XA configuration
  dnl
  if test x$enable_xa = xyes; then
  GALLIUM_STATE_TRACKERS_DIRS=xa $GALLIUM_STATE_TRACKERS_DIRS
 +enable_gallium_loader=yes
  fi
  AM_CONDITIONAL(HAVE_ST_XA, test x$enable_xa = xyes)
  
 @@ -1743,7 +1744,7 @@ if test x$with_gallium_drivers != x; then
  xsvga)
  HAVE_GALLIUM_SVGA=yes
  GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS svga softpipe
 -gallium_check_st svga/drm dri-vmwgfx xa-vmwgfx
 +gallium_check_st svga/drm dri-vmwgfx 
  ;;
  xi915)
  HAVE_GALLIUM_I915=yes
 @@ -1962,7 +1963,7 @@ AC_SUBST([XVMC_MAJOR], 1)
  AC_SUBST([XVMC_MINOR], 0)
  
  AC_SUBST([XA_MAJOR], 2)
 -AC_SUBST([XA_MINOR], 1)
 +AC_SUBST([XA_MINOR], 2)
  AC_SUBST([XA_TINY], 0)
  AC_SUBST([XA_VERSION], $XA_MAJOR.$XA_MINOR.$XA_TINY)
  
 @@ -2035,6 +2036,8 @@ AC_CONFIG_FILES([Makefile
   src/gallium/targets/egl-static/Makefile
   src/gallium/targets/gbm/Makefile
   src/gallium/targets/opencl/Makefile
 + src/gallium/targets/xa/Makefile
 + src/gallium/targets/xa/xatracker.pc
   src/gallium/targets/osmesa/Makefile
   src/gallium/targets/osmesa/osmesa.pc
   src/gallium/targets/pipe-loader/Makefile
 @@ -2046,8 +2049,6 @@ AC_CONFIG_FILES([Makefile
   src/gallium/targets/r600/xvmc/Makefile
   src/gallium/targets/libgl-xlib/Makefile
   src/gallium/targets/vdpau-nouveau/Makefile
 - src/gallium/targets/xa-vmwgfx/Makefile
 - src/gallium/targets/xa-vmwgfx/xatracker.pc
   src/gallium/targets/xvmc-nouveau/Makefile
   src/gallium/tests/trivial/Makefile
   src/gallium/tests/unit/Makefile
 diff --git a/src/gallium/auxiliary/pipe-loader/Makefile.am 
 b/src/gallium/auxiliary/pipe-loader/Makefile.am
 index 72b4798..2901a71 100644
 --- a/src/gallium/auxiliary/pipe-loader/Makefile.am
 +++ b/src/gallium/auxiliary/pipe-loader/Makefile.am
 @@ -30,7 +30,6 @@ COMMON_LIBADD = \
  endif
  
  libpipe_loader_la_CFLAGS  = \
 - -DSTANDALONE_LOADER \
   $(GALLIUM_PIPE_LOADER_DEFINES) \
   $(AM_CFLAGS) $(AM_CPPFLAGS)
  libpipe_loader_la_SOURCES = $(COMMON_SOURCES)
 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 index e53e8af..95a4f84 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 @@ -47,9 +47,7 @@ static struct sw_winsys *(*backends[])() = {
  #ifdef HAVE_WINSYS_XLIB
 x11_sw_create,
  #endif
 -#ifndef STANDALONE_LOADER
 null_sw_create
 -#endif
  };
  
  int
 diff --git a/src/gallium/state_trackers/xa/Makefile.am 
 b/src/gallium/state_trackers/xa/Makefile.am
 index 7d0b366..72486b9 100644
 --- a/src/gallium/state_trackers/xa/Makefile.am
 +++ b/src/gallium/state_trackers/xa/Makefile.am
 @@ -29,6 +29,9 @@ AM_CFLAGS = \
   $(VISIBILITY_CFLAGS)
  
  AM_CPPFLAGS = \
 + $(GALLIUM_PIPE_LOADER_DEFINES) \
 + -DPIPE_SEARCH_DIR=\$(libdir)/gallium-pipe\ \
 + -I$(top_srcdir)/src/gallium/targets/xa \
^^ left out from the wrappers approach.

   -I$(top_srcdir)/src/gallium/ \
   -I$(top_srcdir)/src/gallium/winsys \
   -I$(top_srcdir)/src/gallium/drivers
 diff --git a/src/gallium/state_trackers/xa/xa_priv.h 
 b/src/gallium/state_trackers/xa/xa_priv.h
 index ee182e7..b99c214 100644
 --- a/src/gallium/state_trackers/xa/xa_priv.h
 +++ 

Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Christian König

Am 13.02.2014 14:33, schrieb Maarten Lankhorst:
[SNIP]
--disable-debug is used by distro builds, so having the debug symbols 
still available is still required.


Ok than that was just my wrong expectation what --disable-debug does.

I would rather have --enable-debug stop fiddling with CFLAGS, so it 
doesn't revert to -g -O0, that is weirder to be honest. :-)


We have merged the -O0 stuff for --enable-debug? I'm using that as 
well, but it's indeed a bit strange.




~Maarten



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 10/13] pipe-loader: introduce pipe_loader_sw_probe_null helper function

2014-02-13 Thread Emil Velikov

On 13/02/14 12:49, Francisco Jerez wrote:

Emil Velikov emil.l.veli...@gmail.com writes:


Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
  src/gallium/auxiliary/pipe-loader/pipe_loader.h| 10 ++
  src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 18 +-
  2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index f5a7252..026f809 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -133,6 +133,16 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device **devs,


  /**
+ * Initialize a null sw device.
+ *
+ * This function is platform-specific.
+ *
+ * \sa pipe_loader_probe
+ */
+bool
+pipe_loader_sw_probe_null(struct pipe_loader_device **devs);
+
+/**
   * Get a list of known software devices.
   *
   * This function is platform-specific.
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index 954e16e..618a911 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -85,7 +85,23 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device **devs, 
struct drisw_loader_f
 return true;
  }

-int
+bool
+pipe_loader_sw_probe_null(struct pipe_loader_device **devs)
+{
+   struct pipe_loader_sw_device *sdev = CALLOC_STRUCT(pipe_loader_sw_device);
+
+   if (!sdev)
+  return false;
+
+   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
+   sdev-base.driver_name = swrast;
+   sdev-base.ops = pipe_loader_sw_ops;
+   sdev-ws = null_sw_create();
+   *devs = sdev-base;
+
+   return true;
+}
+


Missing return type here.


Too much git rebase... :\


  pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev)
  {
 int i;


Maybe remove pipe_loader_sw_probe() altogether and change pipe_loader.c
to use pipe_loader_sw_probe_null() instead?

Mind if we keep that as a follow up. Last time I've checked the 
pipe-loader was used by clover and I've no idea how deep those waters are.


Thanks for the review and comments.

-Emil

P.S. Thunderbird does not like when I reply to your signed email :\ More 
on that at 11.



--
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCHv3 2/4] st/xa: use pipe-loader to get screen

2014-02-13 Thread Rob Clark
On Thu, Feb 13, 2014 at 8:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 +if HAVE_MESA_LLVM
 +# Mention a dummy pure C++ file to trigger generation of the $(LINK) 
 variable
 +nodist_EXTRA_libxatracker_la_SOURCES = dummy-cpp.cpp
 Move before the HAVE_MESA_LLVM. It will translate to no-on if not required.

 +
 +libxatracker_la_LIBADD += $(LLVM_LIBS)
 +libxatracker_la_LDFLAGS += $(LLVM_LDFLAGS)
 +else
 +# Mention a dummy pure C file to trigger generation of the $(LINK) variable
 +nodist_EXTRA_libxatracker_la_SOURCES = dummy-c.c
 +endif
 Drop the else hunk


it does mean that you will always have a c++ dummy even if no llvm.  I
don't really know if that is a problem or not, but this is why I'd
kept it similar to the other targets.

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCHv3 2/4] st/xa: use pipe-loader to get screen

2014-02-13 Thread Emil Velikov

On 13/02/14 13:53, Rob Clark wrote:

On Thu, Feb 13, 2014 at 8:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote:

+if HAVE_MESA_LLVM
+# Mention a dummy pure C++ file to trigger generation of the $(LINK) variable
+nodist_EXTRA_libxatracker_la_SOURCES = dummy-cpp.cpp

Move before the HAVE_MESA_LLVM. It will translate to no-on if not required.


+
+libxatracker_la_LIBADD += $(LLVM_LIBS)
+libxatracker_la_LDFLAGS += $(LLVM_LDFLAGS)
+else
+# Mention a dummy pure C file to trigger generation of the $(LINK) variable
+nodist_EXTRA_libxatracker_la_SOURCES = dummy-c.c
+endif

Drop the else hunk



it does mean that you will always have a c++ dummy even if no llvm.  I
don't really know if that is a problem or not, but this is why I'd
kept it similar to the other targets.

Two/thirds of the targets follow your approach, while the rest what I 
have in mind. There was a recent patch for vdpau/r600 that reminded me 
that this needs to stop :)


I'm not fussed if it's done here or not, as your patches focus another 
topic.


-Emil

BR,
-R



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 10/13] pipe-loader: introduce pipe_loader_sw_probe_null helper function

2014-02-13 Thread Francisco Jerez
Emil Velikov emil.l.veli...@gmail.com writes:

 On 13/02/14 12:49, Francisco Jerez wrote:
 Emil Velikov emil.l.veli...@gmail.com writes:

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
   src/gallium/auxiliary/pipe-loader/pipe_loader.h| 10 ++
   src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 18 +-
   2 files changed, 27 insertions(+), 1 deletion(-)

 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 index f5a7252..026f809 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
 @@ -133,6 +133,16 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device 
 **devs,


   /**
 + * Initialize a null sw device.
 + *
 + * This function is platform-specific.
 + *
 + * \sa pipe_loader_probe
 + */
 +bool
 +pipe_loader_sw_probe_null(struct pipe_loader_device **devs);
 +
 +/**
* Get a list of known software devices.
*
* This function is platform-specific.
 diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
 b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 index 954e16e..618a911 100644
 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
 @@ -85,7 +85,23 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device 
 **devs, struct drisw_loader_f
  return true;
   }

 -int
 +bool
 +pipe_loader_sw_probe_null(struct pipe_loader_device **devs)
 +{
 +   struct pipe_loader_sw_device *sdev = 
 CALLOC_STRUCT(pipe_loader_sw_device);
 +
 +   if (!sdev)
 +  return false;
 +
 +   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
 +   sdev-base.driver_name = swrast;
 +   sdev-base.ops = pipe_loader_sw_ops;
 +   sdev-ws = null_sw_create();
 +   *devs = sdev-base;
 +
 +   return true;
 +}
 +

 Missing return type here.

 Too much git rebase... :\

   pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev)
   {
  int i;

 Maybe remove pipe_loader_sw_probe() altogether and change pipe_loader.c
 to use pipe_loader_sw_probe_null() instead?

 Mind if we keep that as a follow up. Last time I've checked the 
 pipe-loader was used by clover and I've no idea how deep those waters are.


Not very :P, clover doesn't run on sw devices ATM.

Thanks.

 Thanks for the review and comments.

 -Emil

 P.S. Thunderbird does not like when I reply to your signed email :\ More 
 on that at 11.

 --
 1.8.5.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgprlTRBcvBzl.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] configure: Use pkg-config for libselinux

2014-02-13 Thread Emil Velikov
On 13/02/14 13:20, Kusanagi Kouichi wrote:
 libselinux provides pkgconfig file since 2.0.89 (2009-10-29).
 
Can you check how many of the currently supported distros include that
version or later ?
I was nicely surprised when I did a similar change with expat

Thanks
-Emil

 Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp
 ---
  configure.ac | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index 00a0eaa..949aaa2 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -506,12 +506,7 @@ AC_ARG_ENABLE([selinux],
  [MESA_SELINUX=$enableval],
  [MESA_SELINUX=no])
  if test x$enable_selinux = xyes; then
 -AC_CHECK_HEADER([selinux/selinux.h],[],
 -[AC_MSG_ERROR([SELinux headers not found])])
 -AC_CHECK_LIB([selinux],[is_selinux_enabled],[],
 - [AC_MSG_ERROR([SELinux library not found])])
 -SELINUX_LIBS=-lselinux
 -DEFINES=$DEFINES -DMESA_SELINUX
 +PKG_CHECK_MODULES([SELINUX], [libselinux], [DEFINES=$DEFINES 
 -DMESA_SELINUX])
  fi
  AC_SUBST([SELINUX_LIBS])
  
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nv50: make sure to clear _all_ layers of all attachments

2014-02-13 Thread Emil Velikov
On 13/02/14 10:13, Ilia Mirkin wrote:
 Unfortunately there's only one RT_ARRAY_MODE setting for all
 attachments, so clears were previously truncated to the minimum number
 of layers any attachment had. Instead set the RT_ARRAY_MODE to 512 (the
 max number of layers) before doing the clear. This fixes
 gl-3.2-layered-rendering-clear-color-mismatched-layer-count.
 
Pardon my ignorance but how did you gather the maximum number of layers
? The headers list values up-to 0x.

Guessing that setting the maximum number of layers is a slight overkill
but I'm definitely not opposed to it.

 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 ---
 
 Haven't had a chance to do a full piglit run on this yet, but it does fix the
 failing test. Have a look. I'm not sure if zeta can have layers, it seems like
 a couple of things assumed it couldn't. I've changed that assumption around.
 
  src/gallium/drivers/nouveau/nv50/nv50_context.h   |  2 ++
  .../drivers/nouveau/nv50/nv50_state_validate.c|  1 +
  src/gallium/drivers/nouveau/nv50/nv50_surface.c   | 19 
 +--
  3 files changed, 20 insertions(+), 2 deletions(-)
 
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.h 
 b/src/gallium/drivers/nouveau/nv50/nv50_context.h
 index 57a3090..84ff46e 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_context.h
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_context.h
 @@ -173,6 +173,8 @@ struct nv50_context {
  
 boolean vbo_push_hint;
  
 +   uint32_t rt_array_mode;
 +
 struct pipe_query *cond_query;
 boolean cond_cond;
 uint cond_mode;
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
 index f953422..100d02d 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
 @@ -65,6 +65,7 @@ nv50_validate_fb(struct nv50_context *nv50)
   PUSH_DATA (push, sf-height);
   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
   PUSH_DATA (push, array_mode | array_size);
 + nv50-rt_array_mode = array_mode | array_size;
} else {
   PUSH_DATA (push, 0);
   PUSH_DATA (push, 0);
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 index a22436b..68924c9 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 @@ -303,7 +303,7 @@ nv50_clear_render_target(struct pipe_context *pipe,
PUSH_DATA(push, NV50_3D_RT_HORIZ_LINEAR | mt-level[0].pitch);
 PUSH_DATA (push, sf-height);
 BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 -   PUSH_DATA (push, 1);
 +   PUSH_DATA (push, 512);
  
 if (!nouveau_bo_memtype(bo)) {
BEGIN_NV04(push, NV50_3D(ZETA_ENABLE), 1);
 @@ -366,7 +366,7 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
 PUSH_DATA (push, bo-offset + sf-offset);
 PUSH_DATA (push, nv50_format_table[dst-format].rt);
 PUSH_DATA (push, mt-level[sf-base.u.tex.level].tile_mode);
 -   PUSH_DATA (push, 0);
 +   PUSH_DATA (push, mt-layer_stride  2);
I'm guessing that this hunk could be separated, as it does make sense to
set the stride when doing the clears.

Does this make make any difference wrt the test in question ?

-Emil

 BEGIN_NV04(push, NV50_3D(ZETA_ENABLE), 1);
 PUSH_DATA (push, 1);
 BEGIN_NV04(push, NV50_3D(ZETA_HORIZ), 3);
 @@ -374,6 +374,9 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
 PUSH_DATA (push, sf-height);
 PUSH_DATA (push, (1  16) | 1);
  
 +   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 +   PUSH_DATA (push, 512);
 +
 BEGIN_NV04(push, NV50_3D(VIEWPORT_HORIZ(0)), 2);
 PUSH_DATA (push, (width  16) | dstx);
 PUSH_DATA (push, (height  16) | dsty);
 @@ -402,6 +405,14 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
 if (!nv50_state_validate(nv50, NV50_NEW_FRAMEBUFFER, 9 + (fb-nr_cbufs * 
 2)))
return;
  
 +   /* We have to clear ALL of the layers, not up to the min number of layers
 +* of any attachment. Don't touch 3d textures, they can't be arrays. The
 +* above nv50_state_validate call will have written to rt_array_mode. */
 +   if (!(nv50-rt_array_mode  NV50_3D_RT_ARRAY_MODE_MODE_3D)) {
 +  BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 +  PUSH_DATA (push, 512);
 +   }
 +
 if (buffers  PIPE_CLEAR_COLOR  fb-nr_cbufs) {
BEGIN_NV04(push, NV50_3D(CLEAR_COLOR(0)), 4);
PUSH_DATAf(push, color-f[0]);
 @@ -459,6 +470,10 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
  (j  NV50_3D_CLEAR_BUFFERS_LAYER__SHIFT));
}
 }
 +
 +   /* restore the array mode */
 +   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 +   PUSH_DATA (push, nv50-rt_array_mode);
  }
  
  
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH 09/18] mesa: Refactor set_atomic_buffer_binding()

2014-02-13 Thread Francisco Jerez
Fredrik Höglund fred...@kde.org writes:

 Make set_atomic_buffer_binding() just update the binding, and move
 the code that does validation, flushes the vertices etc. into a new
 bind_atomic_buffer() function.

If you add two short comments on the difference between
set_atomic_buffer_binding() and bind_atomic_buffer(), as Brian
suggested, this patch is:

Reviewed-by: Francisco Jerez curroje...@riseup.net

 ---
  src/mesa/main/bufferobj.c |   42 ++
  1 file changed, 26 insertions(+), 16 deletions(-)

 diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
 index e46516d..4094e31 100644
 --- a/src/mesa/main/bufferobj.c
 +++ b/src/mesa/main/bufferobj.c
 @@ -2474,11 +2474,29 @@ bind_buffer_base_uniform_buffer(struct gl_context 
 *ctx,
  
  static void
  set_atomic_buffer_binding(struct gl_context *ctx,
 -  unsigned index,
 +  struct gl_atomic_buffer_binding *binding,
struct gl_buffer_object *bufObj,
GLintptr offset,
 -  GLsizeiptr size,
 -  const char *name)
 +  GLsizeiptr size)
 +{
 +   _mesa_reference_buffer_object(ctx, binding-BufferObject, bufObj);
 +
 +   if (bufObj == ctx-Shared-NullBufferObj) {
 +  binding-Offset = -1;
 +  binding-Size = -1;
 +   } else {
 +  binding-Offset = offset;
 +  binding-Size = size;
 +   }
 +}
 +
 +static void
 +bind_atomic_buffer(struct gl_context *ctx,
 +   unsigned index,
 +   struct gl_buffer_object *bufObj,
 +   GLintptr offset,
 +   GLsizeiptr size,
 +   const char *name)
  {
 struct gl_atomic_buffer_binding *binding;
  
 @@ -2506,15 +2524,7 @@ set_atomic_buffer_binding(struct gl_context *ctx,
 FLUSH_VERTICES(ctx, 0);
 ctx-NewDriverState |= ctx-DriverFlags.NewAtomicBuffer;
  
 -   _mesa_reference_buffer_object(ctx, binding-BufferObject, bufObj);
 -
 -   if (bufObj == ctx-Shared-NullBufferObj) {
 -  binding-Offset = -1;
 -  binding-Size = -1;
 -   } else {
 -  binding-Offset = offset;
 -  binding-Size = size;
 -   }
 +   set_atomic_buffer_binding(ctx, binding, bufObj, offset, size);
  }
  
  void GLAPIENTRY
 @@ -2556,8 +2566,8 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
bind_buffer_range_uniform_buffer(ctx, index, bufObj, offset, size);
return;
 case GL_ATOMIC_COUNTER_BUFFER:
 -  set_atomic_buffer_binding(ctx, index, bufObj, offset, size,
 -glBindBufferRange);
 +  bind_atomic_buffer(ctx, index, bufObj, offset, size,
 + glBindBufferRange);
return;
 default:
_mesa_error(ctx, GL_INVALID_ENUM, glBindBufferRange(target));
 @@ -2620,8 +2630,8 @@ _mesa_BindBufferBase(GLenum target, GLuint index, 
 GLuint buffer)
bind_buffer_base_uniform_buffer(ctx, index, bufObj);
return;
 case GL_ATOMIC_COUNTER_BUFFER:
 -  set_atomic_buffer_binding(ctx, index, bufObj, 0, 0,
 -glBindBufferBase);
 +  bind_atomic_buffer(ctx, index, bufObj, 0, 0,
 + glBindBufferBase);
return;
 default:
_mesa_error(ctx, GL_INVALID_ENUM, glBindBufferBase(target));
 -- 
 1.7.10.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgp5h8lyBpAJ6.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Mesa install - Doubts..

2014-02-13 Thread sathishkumar sivagurunathan
Hi,

   I am trying to check the graphics card that I have.. From internet
search, I found the following command lists the graphics card in a system.

1) sudo lshw -C display; lsb_release -a; uname -a; xrandr

The output of the command is as follows..

  *-display
   description: VGA compatible controller
   product: RV620/M82 [Mobility Radeon HD 3450/3470]
   vendor: Advanced Micro Devices, Inc. [AMD/ATI]
   physical id: 0
   bus info: pci@:01:00.0
   version: 00
   width: 32 bits
   clock: 33MHz
   capabilities: pm pciexpress msi vga_controller bus_master cap_list
rom
   configuration: driver=radeon latency=0
   resources: irq:51 memory:c000-cfff ioport:2000(size=256)
memory:bfff-bfff memory:bff0-bff1
  *-display
   description: Display controller
   product: Mobile 4 Series Chipset Integrated Graphics Controller
   vendor: Intel Corporation
   physical id: 2
   bus info: pci@:00:02.0
   version: 07
   width: 64 bits
   clock: 33MHz
   capabilities: msi pm bus_master cap_list rom
   configuration: driver=i915 latency=0
   resources: irq:47 memory:fc00-fc3f memory:d000-dfff

From the listing, I have two controllers listed. Does it mean I have two
graphics card ??

2) Curently I have Mesa 9.2.1.. I want to upgrade it to the latest 10..

   In the install step, what should be the dri drivers of each of the
cards..

  Mobile 4 Series Chipset Integrated Graphics Controller = i915

  RV620/M82 [Mobility Radeon HD 3450/3470] = r600 ???

  will these chipsets support the latest Mesa ??

3) when I run glxinfo, I get the following result..

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 9.2.1
OpenGL shading language version string: 1.20

Does this result mean I have only one gaphic card, the intel based one ?

Thanks,
Sathish
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Vm ware - 3d acceleration

2014-02-13 Thread sathishkumar sivagurunathan
Hi,

I have installed wayland and mesa in vm ware. I am able to launch weston
from terminal. But I am not sure whether it uses 3d acceleration.

My question is how to find wayland uses 3d acceleration or not.

Thanks,
Sathish
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 16/18] mesa: Implement glBindImageTextures()

2014-02-13 Thread Francisco Jerez
Fredrik Höglund fred...@kde.org writes:

 ---
  src/mesa/main/shaderimage.c |  164 
 +++
  1 file changed, 164 insertions(+)

 diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
 index ce63bee..27695a3 100644
 --- a/src/mesa/main/shaderimage.c
 +++ b/src/mesa/main/shaderimage.c
 @@ -33,6 +33,7 @@
  #include context.h
  #include texobj.h
  #include teximage.h
 +#include enums.h
  
  /*
   * Define endian-invariant aliases for some mesa formats that are
 @@ -481,6 +482,169 @@ _mesa_BindImageTexture(GLuint unit, GLuint texture, 
 GLint level,
  void GLAPIENTRY
  _mesa_BindImageTextures(GLuint first, GLsizei count, const GLuint *textures)
  {
 +   GET_CURRENT_CONTEXT(ctx);
 +   int i;
 +
 +   if (!ctx-Extensions.ARB_shader_image_load_store) {
 +  _mesa_error(ctx, GL_INVALID_OPERATION, glBindImageTextures());
 +  return;
 +   }
 +
 +   if (first + count  ctx-Const.MaxImageUnits) {
 +  /* The ARB_multi_bind spec says:
 +   *
 +   *An INVALID_OPERATION error is generated if first + count
 +   * is greater than the number of image units supported by
 +   * the implementation.
 +   */
 +  _mesa_error(ctx, GL_INVALID_OPERATION,
 +  glBindImageTextures(first=%u + count=%u  the value of 
 +  GL_MAX_IMAGE_UNITS=%u),
 +  first, count, ctx-Const.MaxImageUnits);
 +  return;
 +   }
 +
 +   /* Assume that at least one binding will be changed */
 +   FLUSH_VERTICES(ctx, 0);
 +   ctx-NewDriverState |= ctx-DriverFlags.NewImageUnits;
 +
 +   if (!textures) {
 +  /* The ARB_multi_bind spec says:
 +   *
 +   *If textures is NULL, each affected image unit from
 +   * first through first+count-1 will be reset to have
 +   * no bound texture object.
 +   */
 +  for (i = 0; i  count; i++) {
 + struct gl_image_unit *u = ctx-ImageUnits[first + i];
 +
 + u-Level = 0;
 + u-Layered = GL_FALSE;
 + u-Layer = 0;
 + u-Access = GL_READ_ONLY;
 + u-Format = GL_R8;
 + u-_ActualFormat = MESA_FORMAT_R8;
 + u-_Valid = GL_FALSE;
 + _mesa_reference_texobj(u-TexObj, NULL);
 +
 + if (ctx-Driver.BindImageTexture)
 +ctx-Driver.BindImageTexture(ctx, u, NULL, 0, GL_FALSE,
 + 0, GL_READ_ONLY, GL_R8);
 +  }
 +
 +  return;
 +   }

Can't you get rid of the whole block above by declaring 'const GLuint
texture = (textures ? textures[i] : 0);' in the loop below, and then
's/textures[i]/texture/'?

 +
 +   /* Note that the error semantics for multi-bind commands differ from
 +* those of other GL commands.
 +*
 +* The Issues section in the ARB_multi_bind spec says:
 +*
 +*(11) Typically, OpenGL specifies that if an error is generated by
 +*  a command, that command has no effect.  This is somewhat
 +*  unfortunate for multi-bind commands, because it would require
 +*  a first pass to scan the entire list of bound objects for
 +*  errors and then a second pass to actually perform the
 +*  bindings.  Should we have different error semantics?
 +*
 +*   RESOLVED:  Yes.  In this specification, when the parameters for
 +*   one of the count binding points are invalid, that binding
 +*   point is not updated and an error will be generated.  However,
 +*   other binding points in the same command will be updated if
 +*   their parameters are valid and no other error occurs.
 +*/
 +
 +   _mesa_begin_texture_lookups(ctx);
 +
 +   for (i = 0; i  count; i++) {
 +  struct gl_image_unit *u = ctx-ImageUnits[first + i];
 +
 +  if (textures[i] != 0) {
 + struct gl_texture_object *texObj;
 + struct gl_texture_image *image;
 + gl_format actualFormat;
 +
 + if (!u-TexObj || u-TexObj-Name != textures[i]) {
 +texObj = _mesa_lookup_texture_without_locking(ctx, textures[i]);
 +if (!texObj) {
 +   /* The ARB_multi_bind spec says:
 +*
 +*An INVALID_OPERATION error is generated if any value
 +* in textures is not zero or the name of an existing
 +* texture object (per binding).
 +*/
 +   _mesa_error(ctx, GL_INVALID_OPERATION,
 +   glBindImageTextures(textures[%u]=%u 
 +   is not zero or the name of an existing texture 
 +   object), i, textures[i]);
 +   continue;
 +}
 + } else {
 +texObj = u-TexObj;
 + }
 +
 + image = texObj-Image[0][0];
 +
 + if (image-Width == 0 || image-Height == 0 || image-Depth == 0) {
 +/* The ARB_multi_bind spec says:
 + *
 + *An INVALID_OPERATION 

Re: [Mesa-dev] What is DRI_IMAGE and do I want it?

2014-02-13 Thread Emil Velikov
On 13/02/14 05:33, Ilia Mirkin wrote:
 Hello list,
 
 A number of piglit tests fail with the nouveau dri driver (for
 pre-nv30 cards), e.g.
 
 http://people.freedesktop.org/~imirkin/nv10-comparison/nv18-imirkin/spec/EGL_EXT_client_extensions/conformance%20test%203.html
 
 libEGL fatal: DRI2: did not find extension DRI_IMAGE version 1
 
 I noticed that the nouveau driver extensions are specified as
 
 static const __DRIextension *nouveau_driver_extensions[] = {
 driCoreExtension.base,
 driDRI2Extension.base,
 nouveau_vtable.base,
 NULL
 };
 
 without driImageDriverExtension.base in there (which is only used by
 i915/i965, although I assume st/dri implements it in its own way),
 which is most likely the cause of that failure. I looked at the
 functions pointed at by the structure, and they all seem to be
 available with the nouveau driver (but there could be something subtle
 I'm missing). So... should I just drop in
 driImageDriverExtension.base into the list? What is it for? Is there
 a downside to including it?
 
Extension names are messy and there is a bunch of DRI_IMAGE* out there.
- driImageDriverExtension is DRI_IMAGE_DRIVER.

The main user of DRI_IMAGE is egl, with is DRI3 using v7 for it's
createImageFromFds(read prime).

Seems relatively easy (v1 at least) but not in a way of use the
dri_util implementation, as there is none. Feels free to pursue if
you're planning on adding EGL and/or DRI3 support for pre nv30 cards.

-Emil
 As a side-note, what _does_ appear to be missing is
 Allocate/ReleaseBuffer, seemingly needed by the DRI2 stuff. Perhaps
 some of the failures are due to that :)
 
 Thanks,
 
   -ilia
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74935] New: intel hd4600 missing features

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74935

  Priority: medium
Bug ID: 74935
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: intel hd4600 missing features
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: m...@gotu.dk
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.0
 Component: Mesa core
   Product: Mesa

I'm running Gentoo on a Thinkpad t440p, with the nvidia card disabled.
It seems runner2,rbdoom3bfg, and pcsx2 don't recognize the new supposed
features in mesa 10.

After installing Mesa 10.0.3 my glxinfo says:
...
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.0.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
...
...
OpenGL version string: 3.0 Mesa 10.0.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
...
...


runner2 writes this in its log:
...
GL vendor: Intel Open Source Technology Center, renderer Mesa DRI Intel(R)
Haswell Mobile , version 3.0 Mesa 10.0.3, GLSL 1.30
...

rbdoom3bfg draws a black screen and in the console writes:
...
OpenGL Version: 3.0
OpenGL Vendor : Intel Open Source Technology Center
OpenGL GLSL   : 1.3
...
...
error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, 1.30,
1.00 ES, and 3.00 ES


Is this a Gentoo specific error or are some features disabled in mesa 10?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Marek Olšák
Yes, -O0 has been part of --enable-debug, because debugging is often
difficult with -O2. That's why I change CFLAGS and CXXFLAGS manually,
because I only want -g -O2.

Marek

On Thu, Feb 13, 2014 at 2:47 PM, Christian König
deathsim...@vodafone.de wrote:
 Am 13.02.2014 14:33, schrieb Maarten Lankhorst:
 [SNIP]

 --disable-debug is used by distro builds, so having the debug symbols
 still available is still required.


 Ok than that was just my wrong expectation what --disable-debug does.


 I would rather have --enable-debug stop fiddling with CFLAGS, so it
 doesn't revert to -g -O0, that is weirder to be honest. :-)


 We have merged the -O0 stuff for --enable-debug? I'm using that as well,
 but it's indeed a bit strange.



 ~Maarten


 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Maarten Lankhorst


On 13-02-14 16:27, Marek Olšák wrote:

Yes, -O0 has been part of --enable-debug, because debugging is often
difficult with -O2. That's why I change CFLAGS and CXXFLAGS manually,
because I only want -g -O2.
Could just remove --disable-debug. Afaict it amounts to calling autoconf 
with CFLAGS='-g -O0 -DNDEBUG' CXXFLAGS=same

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74935] intel hd4600 missing features

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74935

--- Comment #1 from Emil Velikov emil.l.veli...@gmail.com ---
Most likely the applications do not request core profile, which implies 3.1 and
GLSL 1.40 (or later).

From the mesa 9.2 release notes OpenGL 3.1 is only available if requested at
context creation because GL_ARB_compatibility is not supported. Similar story
for mesa 10.

Open a bug with the respective programs and link them to this bugreport if
needed.

-Emil

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nv50: make sure to clear _all_ layers of all attachments

2014-02-13 Thread Ilia Mirkin
On Thu, Feb 13, 2014 at 9:57 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 On 13/02/14 10:13, Ilia Mirkin wrote:
 Unfortunately there's only one RT_ARRAY_MODE setting for all
 attachments, so clears were previously truncated to the minimum number
 of layers any attachment had. Instead set the RT_ARRAY_MODE to 512 (the
 max number of layers) before doing the clear. This fixes
 gl-3.2-layered-rendering-clear-color-mismatched-layer-count.

 Pardon my ignorance but how did you gather the maximum number of layers
 ? The headers list values up-to 0x.

 Guessing that setting the maximum number of layers is a slight overkill
 but I'm definitely not opposed to it.

The headers sure do...

[369050.901062] nouveau E[  PGRAPH][:02:00.0] DATA_ERROR INVALID_VALUE
[369050.901069] nouveau E[  PGRAPH][:02:00.0] ch 4 [0x003f92e000
gl-3.2-layered-[13468]] subc 3 class 0x8297 mthd 0x1224 data
0x
[369178.121557] nouveau E[  PGRAPH][:02:00.0] DATA_ERROR INVALID_VALUE
[369178.121567] nouveau E[  PGRAPH][:02:00.0] ch 4 [0x003f92e000
gl-3.2-layered-[14400]] subc 3 class 0x8297 mthd 0x1224 data
0x0201

And also

   case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
  return 512;

So I'm pretty sure that 512 is max. I'll have to check whether the
rnndb can support a max value like that.

CLEAR_BUFFERS explicitly gets the layer id from the code, so we'll
never try to clear a layer that we don't think is there. The whole
problem originates from the issues around multiple attachments with
different numbers of layers. Setting the max just avoids the card from
checking whether the layer id is valid or not based on the
RT_ARRAY_MODE.

 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 index a22436b..68924c9 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 @@ -366,7 +366,7 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
 PUSH_DATA (push, bo-offset + sf-offset);
 PUSH_DATA (push, nv50_format_table[dst-format].rt);
 PUSH_DATA (push, mt-level[sf-base.u.tex.level].tile_mode);
 -   PUSH_DATA (push, 0);
 +   PUSH_DATA (push, mt-layer_stride  2);
 I'm guessing that this hunk could be separated, as it does make sense to
 set the stride when doing the clears.

I guess it could be. But it's related to clearing and layers and I
noticed it when I was doing this exercise, so... seems reasonable to
throw it in here.


 Does this make make any difference wrt the test in question ?

Not in the least. The test goes down the nv50_clear path. No idea what
hits this path, but it's part of the pipe interface.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 07/10] pipe-loader: use bool type for pipe_loader_drm_probe_fd()

2014-02-13 Thread Emil Velikov
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
 src/gallium/auxiliary/pipe-loader/pipe_loader.h | 2 +-
 src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index e0525df..cc6b183 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -129,7 +129,7 @@ pipe_loader_drm_probe(struct pipe_loader_device **devs, int 
ndev);
  *
  * \sa pipe_loader_probe
  */
-boolean
+bool
 pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd);
 
 #endif
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 2d26e79..b5eb1e2 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -111,14 +111,14 @@ disconnect:
 #endif
 }
 
-boolean
+bool
 pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd)
 {
struct pipe_loader_drm_device *ddev = CALLOC_STRUCT(pipe_loader_drm_device);
int vendor_id, chip_id;
 
if (!ddev)
-  return FALSE;
+  return false;
 
if (loader_get_pci_id_for_fd(fd, vendor_id, chip_id)) {
   ddev-base.type = PIPE_LOADER_DEVICE_PCI;
@@ -137,11 +137,11 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, 
int fd)
   goto fail;
 
*dev = ddev-base;
-   return TRUE;
+   return true;
 
   fail:
FREE(ddev);
-   return FALSE;
+   return false;
 }
 
 static int
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 02/10] vl/winsys_dri: cleanup vl_screen_create error path

2014-02-13 Thread Emil Velikov
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
---
 src/gallium/auxiliary/vl/vl_winsys_dri.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index fb4aaad..5d83e57 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -330,7 +330,7 @@ vl_screen_create(Display *display, int screen)
dri2_query_cookie = xcb_dri2_query_version (scrn-conn, 
XCB_DRI2_MAJOR_VERSION, XCB_DRI2_MINOR_VERSION);
dri2_query = xcb_dri2_query_version_reply (scrn-conn, dri2_query_cookie, 
error);
if (dri2_query == NULL || error != NULL || dri2_query-minor_version  2)
-  goto free_screen;
+  goto free_query;
 
s = xcb_setup_roots_iterator(xcb_get_setup(scrn-conn));
while (screen--)
@@ -353,48 +353,54 @@ vl_screen_create(Display *display, int screen)
connect_cookie = xcb_dri2_connect_unchecked(scrn-conn, s.data-root, 
driverType);
connect = xcb_dri2_connect_reply(scrn-conn, connect_cookie, NULL);
if (connect == NULL || connect-driver_name_length + 
connect-device_name_length == 0)
-  goto free_screen;
+  goto free_connect;
 
device_name_length = xcb_dri2_connect_device_name_length(connect);
device_name = CALLOC(1, device_name_length + 1);
+   if (!device_name)
+  goto free_connect;
memcpy(device_name, xcb_dri2_connect_device_name(connect), 
device_name_length);
fd = open(device_name, O_RDWR);
free(device_name);
 
if (fd  0)
-  goto free_screen;
+  goto free_connect;
 
if (drmGetMagic(fd, magic))
-  goto free_screen;
+  goto free_connect;
 
authenticate_cookie = xcb_dri2_authenticate_unchecked(scrn-conn, 
s.data-root, magic);
authenticate = xcb_dri2_authenticate_reply(scrn-conn, authenticate_cookie, 
NULL);
 
if (authenticate == NULL || !authenticate-authenticated)
-  goto free_screen;
+  goto free_authenticate;
 
scrn-base.pscreen = driver_descriptor.create_screen(fd);
+
if (!scrn-base.pscreen)
-  goto free_screen;
+  goto free_authenticate;
 
scrn-base.pscreen-flush_frontbuffer = vl_dri2_flush_frontbuffer;
vl_compositor_reset_dirty_area(scrn-dirty_areas[0]);
vl_compositor_reset_dirty_area(scrn-dirty_areas[1]);
 
-   free(dri2_query);
-   free(connect);
free(authenticate);
+   free(connect);
+   free(dri2_query);
+   free(error);
 
return scrn-base;
 
-free_screen:
-   FREE(scrn);
-
-   free(dri2_query);
-   free(connect);
+free_authenticate:
free(authenticate);
+free_connect:
+   free(connect);
+free_query:
+   free(dri2_query);
free(error);
 
+free_screen:
+   FREE(scrn);
return NULL;
 }
 
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 09/10] pipe-loader: introduce pipe_loader_sw_probe_dri helper

2014-02-13 Thread Emil Velikov
Will be used in the following commits.

v2: Link gallium tests against the library.
v3: Handle dri_create_sw_winsys failure

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com (v2)
---
 src/gallium/auxiliary/pipe-loader/pipe_loader.h| 13 
 src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 23 ++
 src/gallium/tests/trivial/Makefile.am  |  1 +
 3 files changed, 37 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index 4b449fd..f80defe 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -44,6 +44,7 @@ extern C {
 #endif
 
 struct pipe_screen;
+struct drisw_loader_funcs;
 
 enum pipe_loader_device_type {
PIPE_LOADER_DEVICE_SOFTWARE,
@@ -119,6 +120,18 @@ pipe_loader_sw_probe_xlib(struct pipe_loader_device 
**devs, Display *display);
 #endif
 
 /**
+ * Initialize sw dri device give the drisw_loader_funcs.
+ *
+ * This function is platform-specific.
+ *
+ * \sa pipe_loader_probe
+ */
+bool
+pipe_loader_sw_probe_dri(struct pipe_loader_device **devs,
+ struct drisw_loader_funcs *drisw_lf);
+
+
+/**
  * Get a list of known software devices.
  *
  * This function is platform-specific.
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index 7e2585e..abc87a2 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -29,9 +29,11 @@
 
 #include util/u_memory.h
 #include util/u_dl.h
+#include sw/dri/dri_sw_winsys.h
 #include sw/null/null_sw_winsys.h
 #include sw/xlib/xlib_sw_winsys.h
 #include target-helpers/inline_sw_helper.h
+#include state_tracker/drisw_api.h
 
 struct pipe_loader_sw_device {
struct pipe_loader_device base;
@@ -70,6 +72,27 @@ pipe_loader_sw_probe_xlib(struct pipe_loader_device **devs, 
Display *display)
 }
 #endif
 
+bool
+pipe_loader_sw_probe_dri(struct pipe_loader_device **devs, struct 
drisw_loader_funcs *drisw_lf)
+{
+   struct pipe_loader_sw_device *sdev = CALLOC_STRUCT(pipe_loader_sw_device);
+
+   if (!sdev)
+  return false;
+
+   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
+   sdev-base.driver_name = swrast;
+   sdev-base.ops = pipe_loader_sw_ops;
+   sdev-ws = dri_create_sw_winsys(drisw_lf);
+   if (!sdev-ws) {
+  FREE(sdev);
+  return false;
+   }
+   *devs = sdev-base;
+
+   return true;
+}
+
 int
 pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev)
 {
diff --git a/src/gallium/tests/trivial/Makefile.am 
b/src/gallium/tests/trivial/Makefile.am
index 0702f68..934e46b 100644
--- a/src/gallium/tests/trivial/Makefile.am
+++ b/src/gallium/tests/trivial/Makefile.am
@@ -13,6 +13,7 @@ AM_CPPFLAGS = \
 
 LDADD = $(GALLIUM_PIPE_LOADER_LIBS) \
$(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \
+   $(top_builddir)/src/gallium/winsys/sw/dri/libswdri.la \
$(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
$(DLOPEN_LIBS) \
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 03/10] pipe-loader: destroy sw_winsys on sw_release

2014-02-13 Thread Emil Velikov
The sw pipe-loader implicitly handles winsys_create, thus we
it would make sense to implicitly destroy it upon releasing
the loader.

Currently we leak the sw_winsys when releasing the pipe-loader.

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
 src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index 95a4f84..fd3d989 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -75,6 +75,9 @@ pipe_loader_sw_release(struct pipe_loader_device **dev)
 {
struct pipe_loader_sw_device *sdev = pipe_loader_sw_device(*dev);
 
+   if (sdev-ws  sdev-ws-destroy)
+  sdev-ws-destroy(sdev-ws);
+
if (sdev-lib)
   util_dl_close(sdev-lib);
 
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 01/10] targets/pipe-loader: link pipe-nouveau against libdrm

2014-02-13 Thread Emil Velikov
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
 src/gallium/targets/pipe-loader/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
b/src/gallium/targets/pipe-loader/Makefile.am
index 97733c1..cb2eff7 100644
--- a/src/gallium/targets/pipe-loader/Makefile.am
+++ b/src/gallium/targets/pipe-loader/Makefile.am
@@ -72,6 +72,7 @@ pipe_nouveau_la_LIBADD = \
$(PIPE_LIBS) \
$(top_builddir)/src/gallium/winsys/nouveau/drm/libnouveaudrm.la \
$(top_builddir)/src/gallium/drivers/nouveau/libnouveau.la \
+   $(LIBDRM_LIBS) \
$(NOUVEAU_LIBS)
 pipe_nouveau_la_LDFLAGS = -no-undefined -avoid-version -module
 if HAVE_MESA_LLVM
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 06/10] winsys/xlib: move xlib_create_sw_winsys within the winsys

2014-02-13 Thread Emil Velikov
v2: Rebase on top of vl_winsys_xsp.c removal
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com (v1)
---
 src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c |  2 +-
 src/gallium/include/state_tracker/xlib_sw_winsys.h | 29 --
 src/gallium/include/state_tracker/xlibsw_api.h | 19 ++
 src/gallium/state_trackers/egl/Makefile.am |  1 +
 src/gallium/state_trackers/egl/SConscript  |  1 +
 src/gallium/state_trackers/egl/x11/native_ximage.c |  3 ++-
 src/gallium/state_trackers/glx/xlib/xm_api.h   |  2 +-
 src/gallium/targets/graw-xlib/SConscript   |  1 +
 src/gallium/targets/graw-xlib/graw_xlib.c  |  3 ++-
 src/gallium/winsys/sw/xlib/xlib_sw_winsys.c|  3 ++-
 src/gallium/winsys/sw/xlib/xlib_sw_winsys.h| 10 
 11 files changed, 40 insertions(+), 34 deletions(-)
 delete mode 100644 src/gallium/include/state_tracker/xlib_sw_winsys.h
 create mode 100644 src/gallium/include/state_tracker/xlibsw_api.h
 create mode 100644 src/gallium/winsys/sw/xlib/xlib_sw_winsys.h

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index 7f3f93b..90d2975 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -30,8 +30,8 @@
 #include util/u_memory.h
 #include util/u_dl.h
 #include sw/null/null_sw_winsys.h
+#include sw/xlib/xlib_sw_winsys.h
 #include target-helpers/inline_sw_helper.h
-#include state_tracker/xlib_sw_winsys.h
 
 struct pipe_loader_sw_device {
struct pipe_loader_device base;
diff --git a/src/gallium/include/state_tracker/xlib_sw_winsys.h 
b/src/gallium/include/state_tracker/xlib_sw_winsys.h
deleted file mode 100644
index 4e7ccc1..000
--- a/src/gallium/include/state_tracker/xlib_sw_winsys.h
+++ /dev/null
@@ -1,29 +0,0 @@
-#ifndef XLIB_SW_WINSYS_H
-#define XLIB_SW_WINSYS_H
-
-#include state_tracker/sw_winsys.h
-#include X11/Xlib.h
-
-
-struct pipe_screen;
-struct pipe_resource;
-
-/* This is what the xlib software winsys expects to find in the
- * private field of flush_frontbuffers().
- *
- * Xlib-based state trackers somehow need to know this.
- */
-struct xlib_drawable {
-   Visual *visual;
-   int depth;
-   Drawable drawable;
-};
-
-
-/* This is the public interface to the ws/xlib module.  Why isn't it
- * being defined in that directory?
- */
-struct sw_winsys *xlib_create_sw_winsys( Display *display );
-
-
-#endif
diff --git a/src/gallium/include/state_tracker/xlibsw_api.h 
b/src/gallium/include/state_tracker/xlibsw_api.h
new file mode 100644
index 000..9301279
--- /dev/null
+++ b/src/gallium/include/state_tracker/xlibsw_api.h
@@ -0,0 +1,19 @@
+#ifndef XLIB_SW_WINSYS_H
+#define XLIB_SW_WINSYS_H
+
+#include state_tracker/sw_winsys.h
+#include X11/Xlib.h
+
+
+/* This is what the xlib software winsys expects to find in the
+ * private field of flush_frontbuffers().
+ *
+ * Xlib-based state trackers somehow need to know this.
+ */
+struct xlib_drawable {
+   Visual *visual;
+   int depth;
+   Drawable drawable;
+};
+
+#endif
diff --git a/src/gallium/state_trackers/egl/Makefile.am 
b/src/gallium/state_trackers/egl/Makefile.am
index 9c00f06..26266ed 100644
--- a/src/gallium/state_trackers/egl/Makefile.am
+++ b/src/gallium/state_trackers/egl/Makefile.am
@@ -42,6 +42,7 @@ AM_CFLAGS += \
$(LIBDRM_CFLAGS) \
$(DRI2PROTO_CFLAGS)
 AM_CPPFLAGS += \
+   -I$(top_srcdir)/src/gallium/winsys \
-I$(top_srcdir)/src/gallium/drivers \
-I$(top_srcdir)/src/glx \
-I$(top_srcdir)/src/mapi \
diff --git a/src/gallium/state_trackers/egl/SConscript 
b/src/gallium/state_trackers/egl/SConscript
index 066a7fd..3ddf0bc 100644
--- a/src/gallium/state_trackers/egl/SConscript
+++ b/src/gallium/state_trackers/egl/SConscript
@@ -7,6 +7,7 @@ env = env.Clone()
 
 env.Append(CPPPATH = [
 '#/src/egl/main',
+'#/src/gallium/winsys',
 '#/src/gallium/winsys/sw',
 '.',
 ])
diff --git a/src/gallium/state_trackers/egl/x11/native_ximage.c 
b/src/gallium/state_trackers/egl/x11/native_ximage.c
index 019e535..d3d1924 100644
--- a/src/gallium/state_trackers/egl/x11/native_ximage.c
+++ b/src/gallium/state_trackers/egl/x11/native_ximage.c
@@ -29,7 +29,8 @@
 #include util/u_format.h
 #include pipe/p_compiler.h
 #include util/u_inlines.h
-#include state_tracker/xlib_sw_winsys.h
+#include state_tracker/xlibsw_api.h
+#include sw/xlib/xlib_sw_winsys.h
 #include util/u_debug.h
 #include egllog.h
 
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.h 
b/src/gallium/state_trackers/glx/xlib/xm_api.h
index fa97ea4..6d0bc3f 100644
--- a/src/gallium/state_trackers/glx/xlib/xm_api.h
+++ b/src/gallium/state_trackers/glx/xlib/xm_api.h
@@ -61,7 +61,7 @@ and create a window, you must do the following to use the 
X/Mesa interface:
 #include state_tracker/st_api.h
 #include os/os_thread.h
 
-#include state_tracker/xlib_sw_winsys.h
+#include 

[Mesa-dev] [PATCH 04/10] pipe-loader: build pipe_loader_drm_x_auth whenever HAVE_PIPE_LOADER_XCB is defined

2014-02-13 Thread Emil Velikov
Currently HAVE_PIPE_LOADER_XCB is defined, rather than being set to 1/0.

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
 src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 597a9b5..ff01054 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -61,7 +61,7 @@ static struct pipe_loader_ops pipe_loader_drm_ops;
 static void
 pipe_loader_drm_x_auth(int fd)
 {
-#if HAVE_PIPE_LOADER_XCB
+#ifdef HAVE_PIPE_LOADER_XCB
/* Try authenticate with the X server to give us access to devices that X
 * is running on. */
xcb_connection_t *xcb_conn;
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 10/10] pipe-loader: introduce pipe_loader_sw_probe_null helper function

2014-02-13 Thread Emil Velikov
v2: Handle null_sw_create failure, add missing function return type

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com (v1)
---
 src/gallium/auxiliary/pipe-loader/pipe_loader.h| 10 ++
 src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 21 +
 2 files changed, 31 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index f80defe..6ab2752 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -132,6 +132,16 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device **devs,
 
 
 /**
+ * Initialize a null sw device.
+ *
+ * This function is platform-specific.
+ *
+ * \sa pipe_loader_probe
+ */
+bool
+pipe_loader_sw_probe_null(struct pipe_loader_device **devs);
+
+/**
  * Get a list of known software devices.
  *
  * This function is platform-specific.
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index abc87a2..ece687b 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -93,6 +93,27 @@ pipe_loader_sw_probe_dri(struct pipe_loader_device **devs, 
struct drisw_loader_f
return true;
 }
 
+bool
+pipe_loader_sw_probe_null(struct pipe_loader_device **devs)
+{
+   struct pipe_loader_sw_device *sdev = CALLOC_STRUCT(pipe_loader_sw_device);
+
+   if (!sdev)
+  return false;
+
+   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
+   sdev-base.driver_name = swrast;
+   sdev-base.ops = pipe_loader_sw_ops;
+   sdev-ws = null_sw_create();
+   if (!sdev-ws) {
+  FREE(sdev);
+  return false;
+   }
+   *devs = sdev-base;
+
+   return true;
+}
+
 int
 pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev)
 {
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 08/10] pipe-loader: introduce pipe_loader_sw_probe_xlib helper

2014-02-13 Thread Emil Velikov
Will be used in the upcoming patches.

v2: handle xlib_create_sw_winsys failure, drop unneeded header

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com (v1)
---
 src/gallium/auxiliary/pipe-loader/Makefile.am  |  4 
 src/gallium/auxiliary/pipe-loader/pipe_loader.h| 18 +++
 src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 26 +++---
 3 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/pipe-loader/Makefile.am 
b/src/gallium/auxiliary/pipe-loader/Makefile.am
index 74a61a3..b6a99c3 100644
--- a/src/gallium/auxiliary/pipe-loader/Makefile.am
+++ b/src/gallium/auxiliary/pipe-loader/Makefile.am
@@ -9,6 +9,10 @@ AM_CPPFLAGS = $(DEFINES) \
-I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/gallium/winsys
 
+if NEED_WINSYS_XLIB
+AM_CPPFLAGS += -DHAVE_WINSYS_XLIB
+endif
+
 noinst_LTLIBRARIES =
 
 if HAVE_LOADER_GALLIUM
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index cc6b183..4b449fd 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -35,6 +35,10 @@
 
 #include pipe/p_compiler.h
 
+#ifdef HAVE_WINSYS_XLIB
+#include X11/Xlib.h
+#endif
+
 #ifdef __cplusplus
 extern C {
 #endif
@@ -100,6 +104,20 @@ pipe_loader_create_screen(struct pipe_loader_device *dev,
 void
 pipe_loader_release(struct pipe_loader_device **devs, int ndev);
 
+#ifdef HAVE_WINSYS_XLIB
+
+/**
+ * Initialize Xlib for an associated display.
+ *
+ * This function is platform-specific.
+ *
+ * \sa pipe_loader_probe
+ */
+bool
+pipe_loader_sw_probe_xlib(struct pipe_loader_device **devs, Display *display);
+
+#endif
+
 /**
  * Get a list of known software devices.
  *
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index 90d2975..7e2585e 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -44,12 +44,32 @@ struct pipe_loader_sw_device {
 static struct pipe_loader_ops pipe_loader_sw_ops;
 
 static struct sw_winsys *(*backends[])() = {
-#ifdef HAVE_WINSYS_XLIB
-   x11_sw_create,
-#endif
null_sw_create
 };
 
+#ifdef HAVE_WINSYS_XLIB
+bool
+pipe_loader_sw_probe_xlib(struct pipe_loader_device **devs, Display *display)
+{
+   struct pipe_loader_sw_device *sdev = CALLOC_STRUCT(pipe_loader_sw_device);
+
+   if (!sdev)
+  return false;
+
+   sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
+   sdev-base.driver_name = swrast;
+   sdev-base.ops = pipe_loader_sw_ops;
+   sdev-ws = xlib_create_sw_winsys(display);
+   if (!sdev-ws) {
+  FREE(sdev);
+  return false;
+   }
+   *devs = sdev-base;
+
+   return true;
+}
+#endif
+
 int
 pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev)
 {
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 05/10] pipe-loader: handle memory allocation failure

2014-02-13 Thread Emil Velikov
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
---
 src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 3 +++
 src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c  | 1 +
 2 files changed, 4 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index ff01054..2d26e79 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -117,6 +117,9 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, 
int fd)
struct pipe_loader_drm_device *ddev = CALLOC_STRUCT(pipe_loader_drm_device);
int vendor_id, chip_id;
 
+   if (!ddev)
+  return FALSE;
+
if (loader_get_pci_id_for_fd(fd, vendor_id, chip_id)) {
   ddev-base.type = PIPE_LOADER_DEVICE_PCI;
   ddev-base.u.pci.vendor_id = vendor_id;
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index fd3d989..7f3f93b 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -58,6 +58,7 @@ pipe_loader_sw_probe(struct pipe_loader_device **devs, int 
ndev)
for (i = 0; i  Elements(backends); i++) {
   if (i  ndev) {
  struct pipe_loader_sw_device *sdev = 
CALLOC_STRUCT(pipe_loader_sw_device);
+/* TODO: handle CALLOC_STRUCT failure */
 
  sdev-base.type = PIPE_LOADER_DEVICE_SOFTWARE;
  sdev-base.driver_name = swrast;
-- 
1.8.5.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] pipe-loader cleanups

2014-02-13 Thread Emil Velikov
Brief update on the first 10 patches, addressing the points raised and
adding the reviewed-by tags.

Note those are separate from the whole pipe-ification of the targets
and should be safe as is.


Cheers
-Emil

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] What is DRI_IMAGE and do I want it?

2014-02-13 Thread Ilia Mirkin
On Thu, Feb 13, 2014 at 10:15 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 On 13/02/14 05:33, Ilia Mirkin wrote:
 Hello list,

 A number of piglit tests fail with the nouveau dri driver (for
 pre-nv30 cards), e.g.

 http://people.freedesktop.org/~imirkin/nv10-comparison/nv18-imirkin/spec/EGL_EXT_client_extensions/conformance%20test%203.html

 libEGL fatal: DRI2: did not find extension DRI_IMAGE version 1

 I noticed that the nouveau driver extensions are specified as

 static const __DRIextension *nouveau_driver_extensions[] = {
 driCoreExtension.base,
 driDRI2Extension.base,
 nouveau_vtable.base,
 NULL
 };

 without driImageDriverExtension.base in there (which is only used by
 i915/i965, although I assume st/dri implements it in its own way),
 which is most likely the cause of that failure. I looked at the
 functions pointed at by the structure, and they all seem to be
 available with the nouveau driver (but there could be something subtle
 I'm missing). So... should I just drop in
 driImageDriverExtension.base into the list? What is it for? Is there
 a downside to including it?

 Extension names are messy and there is a bunch of DRI_IMAGE* out there.
 - driImageDriverExtension is DRI_IMAGE_DRIVER.

OK, so what is DRI_IMAGE_DRIVER good for? I assume only useful if you
also implement DRI_IMAGE?


 The main user of DRI_IMAGE is egl, with is DRI3 using v7 for it's
 createImageFromFds(read prime).

 Seems relatively easy (v1 at least) but not in a way of use the
 dri_util implementation, as there is none. Feels free to pursue if
 you're planning on adding EGL and/or DRI3 support for pre nv30 cards.

In what way is driImageDriverExtension not generic? It just calls
stuff in the driver vtable which is already available (like
create/destroy buffer, I forget). However it doesn't appear that
there's a generic DRI_IMAGE impl.

Anyways, this is the crucial bit of information though -- this is only
for EGL and DRI3, neither of which I have. DRI3 might become a thing
though... in which case I guess the work will have to be done. For
now, it'll be -x egl for future piglit runs :)

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/10] vl/winsys_dri: cleanup vl_screen_create error path

2014-02-13 Thread Christian König

Am 13.02.2014 17:18, schrieb Emil Velikov:

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com


Reviewed-by: Christian König christian.koe...@amd.com


---
  src/gallium/auxiliary/vl/vl_winsys_dri.c | 32 +++-
  1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index fb4aaad..5d83e57 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -330,7 +330,7 @@ vl_screen_create(Display *display, int screen)
 dri2_query_cookie = xcb_dri2_query_version (scrn-conn, 
XCB_DRI2_MAJOR_VERSION, XCB_DRI2_MINOR_VERSION);
 dri2_query = xcb_dri2_query_version_reply (scrn-conn, dri2_query_cookie, 
error);
 if (dri2_query == NULL || error != NULL || dri2_query-minor_version  2)
-  goto free_screen;
+  goto free_query;
  
 s = xcb_setup_roots_iterator(xcb_get_setup(scrn-conn));

 while (screen--)
@@ -353,48 +353,54 @@ vl_screen_create(Display *display, int screen)
 connect_cookie = xcb_dri2_connect_unchecked(scrn-conn, s.data-root, 
driverType);
 connect = xcb_dri2_connect_reply(scrn-conn, connect_cookie, NULL);
 if (connect == NULL || connect-driver_name_length + 
connect-device_name_length == 0)
-  goto free_screen;
+  goto free_connect;
  
 device_name_length = xcb_dri2_connect_device_name_length(connect);

 device_name = CALLOC(1, device_name_length + 1);
+   if (!device_name)
+  goto free_connect;
 memcpy(device_name, xcb_dri2_connect_device_name(connect), 
device_name_length);
 fd = open(device_name, O_RDWR);
 free(device_name);
  
 if (fd  0)

-  goto free_screen;
+  goto free_connect;
  
 if (drmGetMagic(fd, magic))

-  goto free_screen;
+  goto free_connect;
  
 authenticate_cookie = xcb_dri2_authenticate_unchecked(scrn-conn, s.data-root, magic);

 authenticate = xcb_dri2_authenticate_reply(scrn-conn, 
authenticate_cookie, NULL);
  
 if (authenticate == NULL || !authenticate-authenticated)

-  goto free_screen;
+  goto free_authenticate;
  
 scrn-base.pscreen = driver_descriptor.create_screen(fd);

+
 if (!scrn-base.pscreen)
-  goto free_screen;
+  goto free_authenticate;
  
 scrn-base.pscreen-flush_frontbuffer = vl_dri2_flush_frontbuffer;

 vl_compositor_reset_dirty_area(scrn-dirty_areas[0]);
 vl_compositor_reset_dirty_area(scrn-dirty_areas[1]);
  
-   free(dri2_query);

-   free(connect);
 free(authenticate);
+   free(connect);
+   free(dri2_query);
+   free(error);
  
 return scrn-base;
  
-free_screen:

-   FREE(scrn);
-
-   free(dri2_query);
-   free(connect);
+free_authenticate:
 free(authenticate);
+free_connect:
+   free(connect);
+free_query:
+   free(dri2_query);
 free(error);
  
+free_screen:

+   FREE(scrn);
 return NULL;
  }
  


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glx/dri2: Respect --enable/disable-driglx-direct

2014-02-13 Thread Ian Romanick
On 02/13/2014 02:11 AM, Daniel Martin wrote:
 Encapsulate the code in src/glx/dri2_query_renderer.c within a
 
 #ifdef GLX_DIRECT_RENDERING
 
 as done in src/glx/dri2*.c.

I noticed a couple things, and I'm not sure what the right answer is.

First, dri2_glx.c and dri3_glx.c use:

#if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)

but dri2.c uses

#ifdef GLX_DIRECT_RENDERING

I'm not sure why they're different or which is actually correct.

Second, couldn't we just not build the file at all when
GLX_DIRECT_RENDERING isn't selected?  Do something like the following in
src/glx/Makefile.am:

if HAVE_DRI2 || HAVE_DRI3
libglx_la_SOURCES += \
  dri2_glx.c
  dri2.c
  dri2_query_renderer.c
endif

(and remove those files from the default libglx_la_SOURCES list, of course).

 Signed-off-by: Daniel Martin consume.no...@gmail.com
 ---
 ... compile it, when enabled only.
 
 Cheers,
 Daniel
 
  src/glx/dri2_query_renderer.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/src/glx/dri2_query_renderer.c b/src/glx/dri2_query_renderer.c
 index b50a202..3bc90c7 100644
 --- a/src/glx/dri2_query_renderer.c
 +++ b/src/glx/dri2_query_renderer.c
 @@ -20,6 +20,9 @@
   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   * DEALINGS IN THE SOFTWARE.
   */
 +
 +#ifdef GLX_DIRECT_RENDERING
 +
  #include glxclient.h
  #include glx_error.h
  #include xf86drm.h
 @@ -95,3 +98,5 @@ dri2_query_renderer_string(struct glx_screen *base, int 
 attribute,
  
 return psc-rendererQuery-queryString(psc-driScreen, dri_attribute, 
 value);
  }
 +
 +#endif /* GLX_DIRECT_RENDERING */
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nv50: make sure to clear _all_ layers of all attachments

2014-02-13 Thread Roland Scheidegger
Hmm that reminds me when I implemented layered rendering in llvmpipe I
figured we'd only need to store the min amount of layers, because
rendering is undefined if the index is higher anyway. But of course I
didn't think about clears so we can't do that now correctly. Ah well if
anyone would really care it is fixable...
In any case the idea behind the patch looks good to me.

Roland


Am 13.02.2014 11:13, schrieb Ilia Mirkin:
 Unfortunately there's only one RT_ARRAY_MODE setting for all
 attachments, so clears were previously truncated to the minimum number
 of layers any attachment had. Instead set the RT_ARRAY_MODE to 512 (the
 max number of layers) before doing the clear. This fixes
 gl-3.2-layered-rendering-clear-color-mismatched-layer-count.
 
 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 ---
 
 Haven't had a chance to do a full piglit run on this yet, but it does fix the
 failing test. Have a look. I'm not sure if zeta can have layers, it seems like
 a couple of things assumed it couldn't. I've changed that assumption around.
 
  src/gallium/drivers/nouveau/nv50/nv50_context.h   |  2 ++
  .../drivers/nouveau/nv50/nv50_state_validate.c|  1 +
  src/gallium/drivers/nouveau/nv50/nv50_surface.c   | 19 
 +--
  3 files changed, 20 insertions(+), 2 deletions(-)
 
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.h 
 b/src/gallium/drivers/nouveau/nv50/nv50_context.h
 index 57a3090..84ff46e 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_context.h
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_context.h
 @@ -173,6 +173,8 @@ struct nv50_context {
  
 boolean vbo_push_hint;
  
 +   uint32_t rt_array_mode;
 +
 struct pipe_query *cond_query;
 boolean cond_cond;
 uint cond_mode;
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
 index f953422..100d02d 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
 @@ -65,6 +65,7 @@ nv50_validate_fb(struct nv50_context *nv50)
   PUSH_DATA (push, sf-height);
   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
   PUSH_DATA (push, array_mode | array_size);
 + nv50-rt_array_mode = array_mode | array_size;
} else {
   PUSH_DATA (push, 0);
   PUSH_DATA (push, 0);
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 index a22436b..68924c9 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 @@ -303,7 +303,7 @@ nv50_clear_render_target(struct pipe_context *pipe,
PUSH_DATA(push, NV50_3D_RT_HORIZ_LINEAR | mt-level[0].pitch);
 PUSH_DATA (push, sf-height);
 BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 -   PUSH_DATA (push, 1);
 +   PUSH_DATA (push, 512);
  
 if (!nouveau_bo_memtype(bo)) {
BEGIN_NV04(push, NV50_3D(ZETA_ENABLE), 1);
 @@ -366,7 +366,7 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
 PUSH_DATA (push, bo-offset + sf-offset);
 PUSH_DATA (push, nv50_format_table[dst-format].rt);
 PUSH_DATA (push, mt-level[sf-base.u.tex.level].tile_mode);
 -   PUSH_DATA (push, 0);
 +   PUSH_DATA (push, mt-layer_stride  2);
 BEGIN_NV04(push, NV50_3D(ZETA_ENABLE), 1);
 PUSH_DATA (push, 1);
 BEGIN_NV04(push, NV50_3D(ZETA_HORIZ), 3);
 @@ -374,6 +374,9 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
 PUSH_DATA (push, sf-height);
 PUSH_DATA (push, (1  16) | 1);
  
 +   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 +   PUSH_DATA (push, 512);
 +
 BEGIN_NV04(push, NV50_3D(VIEWPORT_HORIZ(0)), 2);
 PUSH_DATA (push, (width  16) | dstx);
 PUSH_DATA (push, (height  16) | dsty);
 @@ -402,6 +405,14 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
 if (!nv50_state_validate(nv50, NV50_NEW_FRAMEBUFFER, 9 + (fb-nr_cbufs * 
 2)))
return;
  
 +   /* We have to clear ALL of the layers, not up to the min number of layers
 +* of any attachment. Don't touch 3d textures, they can't be arrays. The
 +* above nv50_state_validate call will have written to rt_array_mode. */
 +   if (!(nv50-rt_array_mode  NV50_3D_RT_ARRAY_MODE_MODE_3D)) {
 +  BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 +  PUSH_DATA (push, 512);
 +   }
 +
 if (buffers  PIPE_CLEAR_COLOR  fb-nr_cbufs) {
BEGIN_NV04(push, NV50_3D(CLEAR_COLOR(0)), 4);
PUSH_DATAf(push, color-f[0]);
 @@ -459,6 +470,10 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
  (j  NV50_3D_CLEAR_BUFFERS_LAYER__SHIFT));
}
 }
 +
 +   /* restore the array mode */
 +   BEGIN_NV04(push, NV50_3D(RT_ARRAY_MODE), 1);
 +   PUSH_DATA (push, nv50-rt_array_mode);
  }
  
  
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Convert vdpau and dri targets to the pipe-loader

2014-02-13 Thread Marek Olšák
Actually, I also need -DDEBUG, so that assertions are turned on, and
also -fno-omit-frame-pointer on 32-bit. This is my Mesa config:

http://pastebin.com/raw.php?i=feEkffU1

Marek

On Thu, Feb 13, 2014 at 4:59 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:

 On 13-02-14 16:27, Marek Olšák wrote:

 Yes, -O0 has been part of --enable-debug, because debugging is often
 difficult with -O2. That's why I change CFLAGS and CXXFLAGS manually,
 because I only want -g -O2.

 Could just remove --disable-debug. Afaict it amounts to calling autoconf
 with CFLAGS='-g -O0 -DNDEBUG' CXXFLAGS=same
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] st/omx/enc: fix scaling src alignment issue

2014-02-13 Thread Christian König
From: Leo Liu leo@amd.com

Signed-off-by: Leo Liu leo@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
 src/gallium/state_trackers/omx/vid_enc.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/omx/vid_enc.c 
b/src/gallium/state_trackers/omx/vid_enc.c
index 1761bcb..6e65274 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -746,10 +746,24 @@ static OMX_ERRORTYPE 
vid_enc_EncodeFrame(omx_base_PortType *port, OMX_BUFFERHEAD
   views = vbuf-get_sampler_view_planes(vbuf);
   dst_surface = priv-scale_buffer-get_surfaces(priv-scale_buffer);
   vl_compositor_clear_layers(s);
+
   for (i = 0; i  VL_MAX_SURFACES; ++i) {
+ struct u_rect src_rect;
+
  if (!views[i] || !dst_surface[i])
 continue;
- vl_compositor_set_rgba_layer(s, compositor, 0, views[i], NULL, NULL, 
NULL);
+
+ src_rect.x0 = 0;
+ src_rect.y0 = 0;
+ src_rect.x1 = port-sPortParam.format.video.nFrameWidth;
+ src_rect.y1 = port-sPortParam.format.video.nFrameHeight;
+
+ if (i  0) {
+src_rect.x1 /= 2;
+src_rect.y1 /= 2;
+ }
+
+ vl_compositor_set_rgba_layer(s, compositor, 0, views[i], src_rect, 
NULL, NULL);
  vl_compositor_render(s, compositor, dst_surface[i], NULL, false);
   }
   
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nv50: make sure to clear _all_ layers of all attachments

2014-02-13 Thread Emil Velikov
On 13/02/14 16:14, Ilia Mirkin wrote:
 On Thu, Feb 13, 2014 at 9:57 AM, Emil Velikov emil.l.veli...@gmail.com 
 wrote:
 On 13/02/14 10:13, Ilia Mirkin wrote:
 Unfortunately there's only one RT_ARRAY_MODE setting for all
 attachments, so clears were previously truncated to the minimum number
 of layers any attachment had. Instead set the RT_ARRAY_MODE to 512 (the
 max number of layers) before doing the clear. This fixes
 gl-3.2-layered-rendering-clear-color-mismatched-layer-count.

 Pardon my ignorance but how did you gather the maximum number of layers
 ? The headers list values up-to 0x.

 Guessing that setting the maximum number of layers is a slight overkill
 but I'm definitely not opposed to it.
 
 The headers sure do...
 
 [369050.901062] nouveau E[  PGRAPH][:02:00.0] DATA_ERROR INVALID_VALUE
 [369050.901069] nouveau E[  PGRAPH][:02:00.0] ch 4 [0x003f92e000
 gl-3.2-layered-[13468]] subc 3 class 0x8297 mthd 0x1224 data
 0x
 [369178.121557] nouveau E[  PGRAPH][:02:00.0] DATA_ERROR INVALID_VALUE
 [369178.121567] nouveau E[  PGRAPH][:02:00.0] ch 4 [0x003f92e000
 gl-3.2-layered-[14400]] subc 3 class 0x8297 mthd 0x1224 data
 0x0201
 
 And also
 
case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
   return 512;
 
 So I'm pretty sure that 512 is max. I'll have to check whether the
 rnndb can support a max value like that.
 
 CLEAR_BUFFERS explicitly gets the layer id from the code, so we'll
 never try to clear a layer that we don't think is there. The whole
 problem originates from the issues around multiple attachments with
 different numbers of layers. Setting the max just avoids the card from
 checking whether the layer id is valid or not based on the
 RT_ARRAY_MODE.
 
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 index a22436b..68924c9 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
 @@ -366,7 +366,7 @@ nv50_clear_depth_stencil(struct pipe_context *pipe,
 PUSH_DATA (push, bo-offset + sf-offset);
 PUSH_DATA (push, nv50_format_table[dst-format].rt);
 PUSH_DATA (push, mt-level[sf-base.u.tex.level].tile_mode);
 -   PUSH_DATA (push, 0);
 +   PUSH_DATA (push, mt-layer_stride  2);
 I'm guessing that this hunk could be separated, as it does make sense to
 set the stride when doing the clears.
 
 I guess it could be. But it's related to clearing and layers and I
 noticed it when I was doing this exercise, so... seems reasonable to
 throw it in here.
 
Fair enough. Can you please add a couple of words in the commit msg.


 Does this make make any difference wrt the test in question ?
 
 Not in the least. The test goes down the nv50_clear path. No idea what
 hits this path, but it's part of the pipe interface.
 
Three users - st/vega, st/clover and the aux/postprocess(effectively
mlaa). mlaa gets initialized as it's detected in the dri-config,
regardless if it's settings :\

Not sure how that would cause any issues though.

FWIW the patch is Reviewed-by: Emil Velikov emil.l.veli...@gmail.com

-Emil
   -ilia
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] main: Avoid double-free of shader Label

2014-02-13 Thread Carl Worth
As documented, the _mesa_free_shader_program_data function:

Frees all the data that hangs off a shader program object, but not
the object itself.

This means that this function may be called multiple times on the same object,
(and has been observed to). Meanwhile, the shProg-Label field was not being
set to NULL after its free(). This led to a second call to free() of the same
address on the second call to this function.

Fix this by setting this field to NULL after free(), (just as with all other
calls to free() in this function).
---
 src/mesa/main/shaderobj.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 4f4bb69..d5c3d80 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -355,6 +355,7 @@ _mesa_free_shader_program_data(struct gl_context *ctx,
}
 
free(shProg-Label);
+   shProg-Label = NULL;
 }
 
 
-- 
1.9.rc1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74935] intel hd4600 missing features

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74935

--- Comment #2 from Martin Jørgensen m...@gotu.dk ---
does this require all developers of opengl applications to make a special
exception in their code if dealing with mesa? or is the context creation
behavior you mentioned only temporary?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] main: Avoid double-free of shader Label

2014-02-13 Thread Brian Paul

On 02/13/2014 10:55 AM, Carl Worth wrote:

As documented, the _mesa_free_shader_program_data function:

Frees all the data that hangs off a shader program object, but not
the object itself.

This means that this function may be called multiple times on the same object,
(and has been observed to). Meanwhile, the shProg-Label field was not being
set to NULL after its free(). This led to a second call to free() of the same
address on the second call to this function.

Fix this by setting this field to NULL after free(), (just as with all other
calls to free() in this function).
---
  src/mesa/main/shaderobj.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 4f4bb69..d5c3d80 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -355,6 +355,7 @@ _mesa_free_shader_program_data(struct gl_context *ctx,
 }

 free(shProg-Label);
+   shProg-Label = NULL;
  }





Reviewed-by: Brian Paul bri...@vmware.com

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] main: Avoid double-free of shader Label

2014-02-13 Thread Brian Paul

On 02/13/2014 10:59 AM, Brian Paul wrote:

On 02/13/2014 10:55 AM, Carl Worth wrote:

As documented, the _mesa_free_shader_program_data function:

Frees all the data that hangs off a shader program object, but not
the object itself.

This means that this function may be called multiple times on the same
object,
(and has been observed to). Meanwhile, the shProg-Label field was not
being
set to NULL after its free(). This led to a second call to free() of
the same
address on the second call to this function.

Fix this by setting this field to NULL after free(), (just as with all
other
calls to free() in this function).
---
  src/mesa/main/shaderobj.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 4f4bb69..d5c3d80 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -355,6 +355,7 @@ _mesa_free_shader_program_data(struct gl_context
*ctx,
 }

 free(shProg-Label);
+   shProg-Label = NULL;
  }





Reviewed-by: Brian Paul bri...@vmware.com


Probably a candidate for the stable branches too, right?

-Brian


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] main: Avoid double-free of shader Label

2014-02-13 Thread Carl Worth
Brian Paul bri...@vmware.com writes:
 Reviewed-by: Brian Paul bri...@vmware.com

 Probably a candidate for the stable branches too, right?

Sure. Good point.

I'll be sure to add the note to the commit message so that the stable
maintainer doesn't miss this, (I here that guy can need some hand
holding).

-Carl

-- 
carl.d.wo...@intel.com


pgpTtN9gAOpeq.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74944] New: libomx_r600 segfault on RadeonSI hardware

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74944

  Priority: medium
Bug ID: 74944
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: libomx_r600 segfault on RadeonSI hardware
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pontost...@gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

Radeon hd 7790, 
ls /usr/lib64/bellagio/
libomxaudio_effects.so.0  libomxclocksrc.so.0  libomx_r600.so   
libomx_r600.so.0.0.0  libomx_radeonsi.so.0  libomxvideosched.so.0
libomxaudio_effects.so.0.0.0  libomxclocksrc.so.0.0.0  libomx_r600.so.0 
libomx_radeonsi.solibomx_radeonsi.so.0.0.0  libomxvideosched.so.0.0.0

omxregister-bellagio 
EE r600_pipe.c:259 r600_create_context - Unsupported chip class 9.
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x770ff5da in r600_destroy_common_screen (rscreen=0x62b310) at
r600_pipe_common.c:641
641 r600_pipe_common.c: No such file or directory.
(gdb) bt
#0  0x770ff5da in r600_destroy_common_screen (rscreen=0x62b310) at
r600_pipe_common.c:641
#1  0x76f8a081 in vl_screen_destroy (vscreen=0x62a800) at
../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:414
#2  0x7710b4b5 in omx_put_screen () at entrypoint.c:101
#3  0x7711cd41 in vid_enc_LoaderComponent (comp=0x61ace0) at
vid_enc.c:116
#4  0x7710b3e9 in omx_component_library_Setup
(stComponents=stComponents@entry=0x61ac70) at entrypoint.c:64
#5  0x00401a25 in buildComponentsList
(omxregistryfp=omxregistryfp@entry=0x605080,
componentspath=componentspath@entry=0x402556 /usr/lib64/bellagio/,
verbose=verbose@entry=0)
at omxregister.c:249
#6  0x00401352 in main (argc=optimized out, argv=optimized out) at
omxregister.c:483


rm /usr/lib64/bellagio/libomx_r600.so*

omxregister-bellagio -v

 Scanning directory /usr/lib64/bellagio/

 Scanning library /usr/lib64/bellagio/libomx_radeonsi.so
Component OMX.radeonsi.video_decoder registered with 0 quality levels
  Specific role OMX.radeonsi.video_decoder.mpeg2 registered
  Specific role OMX.radeonsi.video_decoder.avc registered
Component OMX.radeonsi.video_encoder registered with 0 quality levels
  Specific role OMX.radeonsi.video_encoder.avc registered

 2 OpenMAX IL ST static components in 1 libraries succesfully scanned

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74944] libomx_r600 segfault on RadeonSI hardware

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74944

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Severity|normal  |enhancement

--- Comment #1 from Christian König deathsim...@vodafone.de ---
That is expected behaviour. The OMX state tracker currently doesn't chose the
correct driver for you, you need to do so manually.

So for SI hardware you need to compile only with radeonsi driver, for r600 only
with r600 driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74935] intel hd4600 missing features

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74935

--- Comment #3 from Emil Velikov emil.l.veli...@gmail.com ---
(In reply to comment #2)
 does this require all developers of opengl applications to make a special
 exception in their code if dealing with mesa? or is the context creation
 behavior you mentioned only temporary?

This is not an exception for mesa, but API compliance.

Only drivers implementing GL_ARB_compatibility can/should provide opengl 3.1
and later if the application does not request core profile on context creation.

AFAIK currently there is no plans to support GL_ARB_compatibility within mesa.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74935] intel hd4600 missing features

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74935

Martin Jørgensen m...@gotu.dk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Martin Jørgensen m...@gotu.dk ---
okay. guess I close this bug then.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 74935] intel hd4600 missing features

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=74935

--- Comment #5 from Kenneth Graunke kenn...@whitecape.org ---
The OpenGL API split into two profiles starting with 3.1/3.2:
- The compatibility / legacy profile, which is backwards compatible all the
way to GL 1.x.
- The core profile, which drops a lot of deprecated functionality, allowing
new features to implemented cleanly and more optimally.

Since the core profile is not backwards compatible, applications have to
specifically ask for it.  Otherwise, we give them the highest versioned
compatibility/legacy context we support, which is 3.0.

Note that Apple takes the same approach as Mesa: on OS X, you can ask for an
OpenGL 2.1 context, or an OpenGL 3.2+ core profile context.  So, authors of
OpenGL applications already have to cope with this.  In general, older engines
work with the legacy mode, and new engines being written are targeting the core
profile.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] vl: add motion adaptive deinterlacer

2014-02-13 Thread Grigori Goronzy
---
 src/gallium/auxiliary/Makefile.sources |   3 +-
 src/gallium/auxiliary/vl/vl_deint_filter.c | 491 +
 src/gallium/auxiliary/vl/vl_deint_filter.h |  78 +
 3 files changed, 571 insertions(+), 1 deletion(-)
 create mode 100644 src/gallium/auxiliary/vl/vl_deint_filter.c
 create mode 100644 src/gallium/auxiliary/vl/vl_deint_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index c89cbdd..19004e0 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -155,7 +155,8 @@ C_SOURCES := \
 vl/vl_idct.c \
vl/vl_mc.c \
 vl/vl_vertex_buffers.c \
-vl/vl_video_buffer.c
+vl/vl_video_buffer.c \
+   vl/vl_deint_filter.c
 
 GENERATED_SOURCES := \
indices/u_indices_gen.c \
diff --git a/src/gallium/auxiliary/vl/vl_deint_filter.c 
b/src/gallium/auxiliary/vl/vl_deint_filter.c
new file mode 100644
index 000..9b05154
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_deint_filter.c
@@ -0,0 +1,491 @@
+/**
+ *
+ * Copyright 2013 Grigori Goronzy g...@chown.ath.cx.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+/*
+ *  References:
+ *
+ *  Lin, S. F., Chang, Y. L.,  Chen, L. G. (2003).
+ *  Motion adaptive interpolation with horizontal motion detection for 
deinterlacing.
+ *  Consumer Electronics, IEEE Transactions on, 49(4), 1256-1265.
+ *
+ *  Pei-Yin, C. H. E. N.,  Yao-Hsien, L. A. I. (2007).
+ *  A low-complexity interpolation method for deinterlacing.
+ *  IEICE transactions on information and systems, 90(2), 606-608.
+ *
+ */
+
+#include stdio.h
+
+#include pipe/p_context.h
+
+#include tgsi/tgsi_ureg.h
+
+#include util/u_draw.h
+#include util/u_memory.h
+#include util/u_math.h
+
+#include vl_types.h
+#include vl_video_buffer.h
+#include vl_vertex_buffers.h
+#include vl_deint_filter.h
+
+enum VS_OUTPUT
+{
+   VS_O_VPOS = 0,
+   VS_O_VTEX = 0
+};
+
+static void *
+create_vert_shader(struct vl_deint_filter *filter)
+{
+   struct ureg_program *shader;
+   struct ureg_src i_vpos;
+   struct ureg_dst o_vpos, o_vtex;
+
+   shader = ureg_create(TGSI_PROCESSOR_VERTEX);
+   if (!shader)
+  return NULL;
+
+   i_vpos = ureg_DECL_vs_input(shader, 0);
+   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
+   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
+
+   ureg_MOV(shader, o_vpos, i_vpos);
+   ureg_MOV(shader, o_vtex, i_vpos);
+
+   ureg_END(shader);
+
+   return ureg_create_shader_and_destroy(shader, filter-pipe);
+}
+
+static void *
+create_copy_frag_shader(struct vl_deint_filter *filter, unsigned field)
+{
+   struct ureg_program *shader;
+   struct ureg_src i_vtex;
+   struct ureg_src sampler;
+   struct ureg_dst o_fragment;
+   struct ureg_dst t_tex;
+
+   shader = ureg_create(TGSI_PROCESSOR_FRAGMENT);
+   if (!shader) {
+  return NULL;
+   }
+   t_tex = ureg_DECL_temporary(shader);
+
+   i_vtex = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX, 
TGSI_INTERPOLATE_LINEAR);
+   sampler = ureg_DECL_sampler(shader, 2);
+   o_fragment = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, 0);
+
+   ureg_MOV(shader, t_tex, i_vtex);
+   if (field) {
+  ureg_MOV(shader, ureg_writemask(t_tex, TGSI_WRITEMASK_ZW),
+   ureg_imm4f(shader, 0, 0, 1.0f, 0));
+   } else {
+  ureg_MOV(shader, ureg_writemask(t_tex, TGSI_WRITEMASK_ZW),
+   ureg_imm1f(shader, 0));
+   }
+
+   ureg_TEX(shader, o_fragment, TGSI_TEXTURE_2D_ARRAY, ureg_src(t_tex), 
sampler);
+
+   ureg_release_temporary(shader, t_tex);
+   ureg_END(shader);
+
+   return ureg_create_shader_and_destroy(shader, filter-pipe);
+}
+
+static void *

[Mesa-dev] [PATCH 2/2] st/vdpau: add support for DEINTERLACE_TEMPORAL

2014-02-13 Thread Grigori Goronzy
---
 src/gallium/state_trackers/vdpau/mixer.c | 69 ++--
 src/gallium/state_trackers/vdpau/query.c |  1 +
 src/gallium/state_trackers/vdpau/vdpau_private.h |  7 +++
 3 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 0095828..996fd8e 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -80,7 +80,6 @@ vlVdpVideoMixerCreate(VdpDevice device,
for (i = 0; i  feature_count; ++i) {
   switch (features[i]) {
   /* they are valid, but we doesn't support them */
-  case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL:
   case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
@@ -95,6 +94,10 @@ vlVdpVideoMixerCreate(VdpDevice device,
   case VDP_VIDEO_MIXER_FEATURE_LUMA_KEY:
  break;
 
+  case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL:
+ vmixer-deint.supported = true;
+ break;
+
   case VDP_VIDEO_MIXER_FEATURE_SHARPNESS:
  vmixer-sharpness.supported = true;
  break;
@@ -181,6 +184,11 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
 
vl_compositor_cleanup_state(vmixer-cstate);
 
+   if (vmixer-deint.filter) {
+  vl_deint_filter_cleanup(vmixer-deint.filter);
+  FREE(vmixer-deint.filter);
+   }
+
if (vmixer-noise_reduction.filter) {
   vl_median_filter_cleanup(vmixer-noise_reduction.filter);
   FREE(vmixer-noise_reduction.filter);
@@ -219,6 +227,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
enum vl_compositor_deinterlace deinterlace;
struct u_rect rect, clip, *prect;
unsigned i, layer = 0;
+   struct pipe_video_buffer *video_buffer;
 
vlVdpVideoMixer *vmixer;
vlVdpSurface *surf;
@@ -233,6 +242,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
compositor = vmixer-device-compositor;
 
surf = vlGetDataHTAB(video_surface_current);
+   video_buffer = surf-video_buffer;
if (!surf)
   return VDP_STATUS_INVALID_HANDLE;
 
@@ -283,6 +293,24 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
   pipe_mutex_unlock(vmixer-device-mutex);
   return VDP_STATUS_INVALID_VIDEO_MIXER_PICTURE_STRUCTURE;
};
+
+   if (deinterlace != VL_COMPOSITOR_WEAVE  vmixer-deint.enabled 
+   video_surface_past_count  1  video_surface_future_count  0) {
+  vlVdpSurface *prevprev = vlGetDataHTAB(video_surface_past[1]);
+  vlVdpSurface *prev = vlGetDataHTAB(video_surface_past[0]);
+  vlVdpSurface *next = vlGetDataHTAB(video_surface_future[0]);
+  if (prevprev  prev  next 
+  vl_deint_filter_check_buffers(vmixer-deint.filter,
+  prevprev-video_buffer, prev-video_buffer, surf-video_buffer, 
next-video_buffer)) {
+ vl_deint_filter_render(vmixer-deint.filter, prevprev-video_buffer,
+prev-video_buffer, surf-video_buffer,
+next-video_buffer,
+deinterlace == VL_COMPOSITOR_BOB_BOTTOM);
+ deinterlace = VL_COMPOSITOR_WEAVE;
+ video_buffer = vmixer-deint.filter-video_buffer;
+  }
+   }
+
prect = RectToPipe(video_source_rect, rect);
if (!prect) {
   rect.x0 = 0;
@@ -291,7 +319,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
   rect.y1 = surf-templat.height;
   prect = rect;
}
-   vl_compositor_set_buffer_layer(vmixer-cstate, compositor, layer, 
surf-video_buffer, prect, NULL, deinterlace);
+   vl_compositor_set_buffer_layer(vmixer-cstate, compositor, layer, 
video_buffer, prect, NULL, deinterlace);
vl_compositor_set_layer_dst_area(vmixer-cstate, layer++, 
RectToPipe(destination_video_rect, rect));
 
for (i = 0; i  layer_count; ++i) {
@@ -332,6 +360,31 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
return VDP_STATUS_OK;
 }
 
+static void
+vlVdpVideoMixerUpdateDeinterlaceFilter(vlVdpVideoMixer *vmixer)
+{
+   struct pipe_context *pipe = vmixer-device-context;
+   assert(vmixer);
+
+   /* remove existing filter */
+   if (vmixer-deint.filter) {
+  vl_deint_filter_cleanup(vmixer-deint.filter);
+  FREE(vmixer-deint.filter);
+  vmixer-deint.filter = NULL;
+   }
+
+   /* create a new filter if requested */
+   if (vmixer-deint.enabled  vmixer-chroma_format == 
PIPE_VIDEO_CHROMA_FORMAT_420) {
+  vmixer-deint.filter = MALLOC(sizeof(struct vl_deint_filter));
+  vmixer-deint.enabled = vl_deint_filter_init(vmixer-deint.filter, pipe,
+vmixer-video_width, vmixer-video_height,
+vmixer-skip_chroma_deint, vmixer-deint.spatial);
+  if (!vmixer-deint.enabled) {
+ FREE(vmixer-deint.filter);
+  }
+   }
+}
+
 /**
  * Update the noise reduction setting
  */
@@ -424,7 +477,6 @@ vlVdpVideoMixerGetFeatureSupport(VdpVideoMixer mixer,
for (i = 0; i 

[Mesa-dev] FYI: broken s2tc libraries

2014-02-13 Thread Brian Paul


Just FYI to anyone using the s2tc library 
(https://github.com/divVerent/s2tc/).  The build of s2tc installed in 
some distros (like Ubuntu 12) is broken: using glTexImage2D to compress 
to GL_COMPRESSED_RGB_S3TC_DXT1_EXT generates bad data).  This causes 
some piglit failures and, evidently, some game crashes.


Luckily, the bug was fixed back in Dec 2012:

commit 86b61ca2e2906297d972e8a4c1e212e3deac99ef
Author: Laurent Carlier lordhea...@gmail.com
Date:   Mon Dec 17 09:59:52 2012 +0100

Fix crash with ETQW and Quake 4


Hopefully, newer distros are including newer builds of s2tc, but I 
wouldn't bet on it.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 69101] prime: black window

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=69101

--- Comment #22 from Christoph Haag haagch.christ...@googlemail.com ---
Can anyone test this patch?
https://bugzilla.kernel.org/show_bug.cgi?id=65761#c41

Beware, it currently breaks opencl and possibly other things, but if it helps,
then we at least know a little bit more about what causes the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 03/12] glsl/gsraytrace: Use __LINE__ macro to set line numbers in GLSL source strings.

2014-02-13 Thread Fabian Bieler
The hardcoded numbers are a few lines off at the moment.
Keeping track of the numbers through further modifications is inconvenient.
The __LINE__ constant takes care of this automatically.

v2: Don't set source-string-number to line number.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 62a584d..c21c667 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -37,6 +37,10 @@
 // TODO: use GL_EXT_transform_feedback or GL3 equivalent
 // TODO: port to piglit too
 
+#define STRINGIFY_(x) #x
+#define STRINGIFY(x) STRINGIFY_(x)
+#define S__LINE__ STRINGIFY(__LINE__)
+
 static const float INF=.9F;
 
 static int Win;
@@ -67,7 +71,7 @@ float rot[9] = {1,0,0,  0,1,0,   0,0,1};
 static const char* vsSource =
   \n
 #version 120  \n
-#line 63 63   \n
+#line  S__LINE__ \n
 #define SHADOWS   \n
 #define RECURSION \n
   \n
@@ -249,7 +253,7 @@ static const char* vsSource =
 
 static const char* gsSource = 
 #version 120 \n
-#line 245 245\n
+#line  S__LINE__ \n
 #extension GL_ARB_geometry_shader4: require  \n
  \n
 #define SHADOWS  \n
@@ -388,7 +392,7 @@ static const char* gsSource =
 
 static const char* fsSource = 
 #version 120 \n
-#line 384 384\n
+#line  S__LINE__ \n
  \n
 #define SHADOWS  \n
 #define RECURSION\n
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 07/12] glsl/gsraytrace: Use GLSL 1.5 instead of 1.2.

2014-02-13 Thread Fabian Bieler
This commit prepares the transition from extension to core geometry shaders.
(Core geometry shaders require GLSL version 1.5 or later.)
This includes using generic vertex attributes instead of built-ins.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 58 +++--
 1 file changed, 32 insertions(+), 26 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index ef67643..f9e708f 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -56,6 +56,7 @@ static GLuint pgQuery;
 static GLuint dst;
 static GLuint eyeRaysAsPoints;
 
+int posAttribLoc;
 int orig_tAttribLoc;
 int dir_idxAttribLoc;
 int uv_stateAttribLoc;
@@ -69,7 +70,7 @@ float rot[9] = {1,0,0,  0,1,0,   0,0,1};
 
 static const char* vsSource =
   \n
-#version 120  \n
+#version 150  \n
 #line  S__LINE__ \n
 #define SHADOWS   \n
 #define RECURSION \n
@@ -83,9 +84,10 @@ static const char* vsSource =
 uniform vec4 backgroundColor; \n
 uniform int emitNoMore;   \n
   \n
-attribute vec4 orig_t;\n
-attribute vec4 dir_idx;   \n
-attribute vec4 uv_state;  \n
+in vec4 pos;  \n
+in vec4 orig_t;   \n
+in vec4 dir_idx;  \n
+in vec4 uv_state; \n
 // uv_state.z = state \n
 // uv_state.w = type (ray generation) \n
   \n
@@ -98,9 +100,9 @@ static const char* vsSource =
 //0: not shadow ray, eye ray  \n
 //1: shadow ray   \n
   \n
-varying vec4 orig_t1; \n
-varying vec4 dir_idx1;\n
-varying vec4 uv_state1;   \n
+out vec4 orig_t1; \n
+out vec4 dir_idx1;\n
+out vec4 uv_state1;   \n
   \n
   \n
 //\n
@@ -224,7 +226,7 @@ static const char* vsSource =
   if (state == 0)
\n
   { 
\n
 // generate eye rays\n
-ray = Ray(cameraPos, normalize(vec3(gl_Vertex.x, gl_Vertex.y, -1.0) * 
rot3));\n
+ray = Ray(cameraPos, normalize(vec3(pos.x, pos.y, -1.0) * rot3));   \n
 isec.t = INF;\n
 isec.idx = -1;\n
 state = 1;\n
@@ -240,7 +242,7 @@ static const char* vsSource =
   //else state == 3 \n
 \n
   //outVS();\n
-  gl_Position  = gl_Vertex; \n
+  gl_Position  = pos;   \n
   orig_t1.xyz  = ray.orig;  \n
   orig_t1.w= isec.t;\n
   dir_idx1.xyz = ray.dir;   \n
@@ -251,7 +253,7 @@ static const char* vsSource =
 
 
 static const char* gsSource = 
-#version 120 \n
+#version 150 \n
 #line  S__LINE__ \n
 #extension GL_ARB_geometry_shader4: require  \n
  \n
@@ -310,13 +312,13 @@ static const char* gsSource =
   return isec;   \n
 }\n
  \n
-varying in vec4 orig_t1[1];  \n
-varying in vec4 dir_idx1[1];   

[Mesa-dev] [PATCH 06/12] glsl/gsraytrace: Use core GL3.0 transform feedback

2014-02-13 Thread Fabian Bieler
NV_transform_feedback is not supported by mesa.
Use transform feedback from core OpenGL 3.0.

This necessitates binding the transform feedback varyings before linking the
shader.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 72 +
 1 file changed, 31 insertions(+), 41 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 015bfcd..ef67643 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -34,7 +34,6 @@
 #include math.h
 #include stddef.h // offsetof
 
-// TODO: use GL_EXT_transform_feedback or GL3 equivalent
 // TODO: port to piglit too
 
 #define STRINGIFY_(x) #x
@@ -604,33 +603,12 @@ Draw(void)
dir_idxAttribLoc = glGetAttribLocation(program, dir_idx);
uv_stateAttribLoc = glGetAttribLocation(program, uv_state);
 
-   posVaryingLoc = glGetVaryingLocationNV(program, gl_Position);
-   orig_tVaryingLoc = glGetVaryingLocationNV(program, orig_t2);
-   dir_idxVaryingLoc = glGetVaryingLocationNV(program, dir_idx2);
-   uv_stateVaryingLoc = glGetVaryingLocationNV(program, uv_state2);
-   //gs.gs-getVaryingLocation(gl_Position, gs.posVaryingLoc);
-   //gs.gs-getVaryingLocation(orig_t2, gs.orig_tVaryingLoc);
-   //gs.gs-getVaryingLocation(dir_idx2, gs.dir_idxVaryingLoc);
-   //gs.gs-getVaryingLocation(uv_state2, gs.uv_stateVaryingLoc);
-
-
-   glBindBufferOffsetNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst, 0);
-   GLint varyings[4]= {
-  posVaryingLoc,
-  orig_tVaryingLoc,
-  dir_idxVaryingLoc,
-  uv_stateVaryingLoc
-   };
-   // I think it will be a performance win to use multiple buffer objects to 
write to
-   // instead of using the interleaved mode.
-   glTransformFeedbackVaryingsNV(program, 4, varyings, 
GL_INTERLEAVED_ATTRIBS_NV);
-
printf(%d\n, i);
//gs.fpwQuery-beginQuery();
//gs.pgQuery-beginQuery();
-   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst);
-   glBeginQuery(GL_PRIMITIVES_GENERATED_NV, pgQuery);
-   glBeginTransformFeedbackNV(GL_POINTS);
+   glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, dst);
+   glBeginQuery(GL_PRIMITIVES_GENERATED, pgQuery);
+   glBeginTransformFeedback(GL_POINTS);
//gs.eyeRaysAsPoints-bindAs(ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, eyeRaysAsPoints);
{
@@ -653,9 +631,9 @@ Draw(void)
   //gs.gs-set_uniform(emitNoMore, 1, 0);
   glUniform1i(glGetUniformLocation(program, emitNoMore), 0);
 
-  //glEnable(GL_RASTERIZER_DISCARD_NV);
+  //glEnable(GL_RASTERIZER_DISCARD);
   glDrawArrays(GL_POINTS, 0, WinWidth*WinHeight);
-  //glDisable(GL_RASTERIZER_DISCARD_NV);
+  //glDisable(GL_RASTERIZER_DISCARD);
 
   glDisableVertexAttribArray(uv_stateAttribLoc);
 
@@ -667,16 +645,16 @@ Draw(void)
}
//gs.eyeRaysAsPoints-unbindAs(ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, 0);
-   glEndTransformFeedbackNV();
+   glEndTransformFeedback();
//gs.pgQuery-endQuery();
-   glEndQuery(GL_PRIMITIVES_GENERATED_NV);
+   glEndQuery(GL_PRIMITIVES_GENERATED);
//gs.fpwQuery-endQuery();
 
psoLog(LOG_RAW)  1st:   gs.fpwQuery-getQueryResult()  ,   
gs.pgQuery-getQueryResult()  \n;
 
 
swap(src, dst);
-   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, 0);
+   glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, 0);
 
clear();
 
@@ -777,15 +755,15 @@ Reshape(int width, int height)
 
{
   size_t nElem = WinWidth*WinHeight*nRayGens;
-  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, dst);
-  glBufferData(GL_TRANSFORM_FEEDBACK_BUFFER_NV, nElem*sizeof(GSRay), 0, 
GL_STREAM_DRAW);
-  GSRay* d = (GSRay*)glMapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 
GL_READ_WRITE);
+  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER, dst);
+  glBufferData(GL_TRANSFORM_FEEDBACK_BUFFER, nElem*sizeof(GSRay), 0, 
GL_STREAM_DRAW);
+  GSRay* d = (GSRay*)glMapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER, 
GL_READ_WRITE);
   for (size_t i = 0; i  nElem; i++)
   {
  d[i].dir_idx = vec4(0.0F, 0.0F, 0.0F, -1.0F);
   }
-  glUnmapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV);
-  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0);
+  glUnmapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER);
+  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER, 0);
   //printf(Ping-pong VBO size 2x%d Kbytes.\n, 
(int)nElem*sizeof(GSRay)/1024);
}
 
@@ -866,12 +844,30 @@ Init(void)
   exit(-1);
}
 
+   if (!GLEW_VERSION_3_0)
+   {
+  fprintf(stderr, OpenGL 3.0 (needed for transform feedback) not 
+  supported!\n);
+  exit(-1);
+   }
+
vertShader = CompileShaderText(GL_VERTEX_SHADER, vsSource);
geomShader = CompileShaderText(GL_GEOMETRY_SHADER_ARB, gsSource);
fragShader = CompileShaderText(GL_FRAGMENT_SHADER, fsSource);
program = LinkShaders3WithGeometryInfo(vertShader, geomShader, fragShader,
   3, GL_POINTS, GL_POINTS);
 
+   const char *varyings[] = {
+  gl_Position,
+  orig_t2,
+

[Mesa-dev] [PATCH 08/12] glsl/gsraytrace: Use core geometry shaders.

2014-02-13 Thread Fabian Bieler
v2: Don't remove ShaderSupported() test. It sets up some function pointers for
the CompileShader framework.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index f9e708f..6df6543 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -255,7 +255,8 @@ static const char* vsSource =
 static const char* gsSource = 
 #version 150 \n
 #line  S__LINE__ \n
-#extension GL_ARB_geometry_shader4: require  \n
+layout(points) in;   \n
+layout(points, max_vertices = 3) out;\n
  \n
 #define SHADOWS  \n
 #define RECURSION\n
@@ -337,7 +338,7 @@ static const char* gsSource =
 return;  \n
  \n
   // emitPassThrough();  \n
-  gl_Position  = gl_PositionIn[0];   \n
+  gl_Position  = gl_in[0].gl_Position;   \n
   orig_t2  = orig_t1[0]; \n
   dir_idx2 = dir_idx1[0];\n
   uv_state2.xyw= uv_state1[0].xyw;   \n
@@ -362,7 +363,7 @@ static const char* gsSource =
   type = 1;\n
\n
   //emitShadowRay();   \n
-  gl_Position  = gl_PositionIn[0]; \n
+  gl_Position  = gl_in[0].gl_Position; \n
   orig_t2.xyz  = shadowRay.orig;   \n
   orig_t2.w= shadowHit.t;  \n
   dir_idx2.xyz = shadowRay.dir;\n
@@ -379,7 +380,7 @@ static const char* gsSource =
   type  = -1;   \n
 \n
   //emitReflRay();  \n
-  gl_Position  = gl_PositionIn[0];  \n
+  gl_Position  = gl_in[0].gl_Position;  \n
   orig_t2.xyz  = reflRay.orig;  \n
   orig_t2.w= reflHit.t; \n
   dir_idx2.xyz = reflRay.dir;   \n
@@ -844,24 +845,17 @@ Init(void)
   exit(-1);
}
 
-   if (!GLEW_ARB_geometry_shader4)
+   if (!GLEW_VERSION_3_2)
{
-  fprintf(stderr, GS Shaders are not supported!\n);
-  exit(-1);
-   }
-
-   if (!GLEW_VERSION_3_0)
-   {
-  fprintf(stderr, OpenGL 3.0 (needed for transform feedback) not 
-  supported!\n);
+  fprintf(stderr, OpenGL 3.2 (needed for transform feedback and 
+  gemoetry shaders) not supported!\n);
   exit(-1);
}
 
vertShader = CompileShaderText(GL_VERTEX_SHADER, vsSource);
geomShader = CompileShaderText(GL_GEOMETRY_SHADER_ARB, gsSource);
fragShader = CompileShaderText(GL_FRAGMENT_SHADER, fsSource);
-   program = LinkShaders3WithGeometryInfo(vertShader, geomShader, fragShader,
-  3, GL_POINTS, GL_POINTS);
+   program = LinkShaders3(vertShader, geomShader, fragShader);
 
const char *varyings[] = {
   gl_Position,
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 00/12] DEMOS Use core profile in two GS demos (v2).

2014-02-13 Thread Fabian Bieler
Hello!

As mesa only supports geometry shaders in core profile contexts this patchset
adjusts the gsraytrace and the geom-outlining-150 demos to use the core
profile.

This is v2 with the comment by Ian Romanick regarding incorrect usage of the
GLSL preprocessor #line directive adressed.

As I don't have git access, I'd appreciate it if someone could commit these
patches (assuming there are no further issues, of course).

Thanks,
Fabian

Fabian Bieler (12):
  configure.ac: Check for freeglut.
  glut_wrapper: Include freeglut.h if available.
  glsl/gsraytrace: Use __LINE__ macro to set line numbers in GLSL source
strings.
  glsl/gsraytrace: Don't create new Buffer objects everytime the window
is resized.
  glsl/gsraytrace: Bind transform feedback buffer.
  glsl/gsraytrace: Use core GL3.0 transform feedback
  glsl/gsraytrace: Use GLSL 1.5 instead of 1.2.
  glsl/gsraytrace: Use core geometry shaders.
  glsl/gsraytrace: Switch to core profile.
  geom-outlining-150: Use a vbo.
  geom-outlining-150: Use core geometry shaders.
  geom-outlining-150: Switch to core profile.

 configure.ac  |   6 ++
 src/glsl/geom-outlining-150.c |  64 +--
 src/glsl/gsraytrace.cpp   | 185 ++
 src/util/glut_wrap.h  |   4 +-
 4 files changed, 147 insertions(+), 112 deletions(-)

-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 02/12] glut_wrapper: Include freeglut.h if available.

2014-02-13 Thread Fabian Bieler
The freeglut header only defines the extensions to request an OpenGL core
profile context if freeglut.h (rather than glut.h) is included.

Note that the header is installed to include/GL/freeglut.h on OS X, too.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/util/glut_wrap.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/util/glut_wrap.h b/src/util/glut_wrap.h
index a48a9e8..fa1b8f9 100644
--- a/src/util/glut_wrap.h
+++ b/src/util/glut_wrap.h
@@ -1,7 +1,9 @@
 #ifndef GLUT_WRAP_H
 #define GLUT_WRAP_H
 
-#ifdef __APPLE__
+#ifdef HAVE_FREEGLUT
+#  include GL/freeglut.h
+#elif defined __APPLE__
 #  include GLUT/glut.h
 #else
 #  include GL/glut.h
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 12/12] geom-outlining-150: Switch to core profile.

2014-02-13 Thread Fabian Bieler
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/geom-outlining-150.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 3dffa16..2e2a54a 100644
--- a/src/glsl/geom-outlining-150.c
+++ b/src/glsl/geom-outlining-150.c
@@ -364,9 +364,22 @@ main(int argc, char *argv[])
 {
glutInit(argc, argv);
glutInitWindowSize(WinWidth, WinHeight);
+#ifdef HAVE_FREEGLUT
+   glutInitContextVersion(3, 2);
+   glutInitContextProfile(GLUT_CORE_PROFILE);
glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);
+#elif defined __APPLE__
+   glutInitDisplayMode(GLUT_3_2_CORE_PROFILE | GLUT_RGB | GLUT_DEPTH | 
GLUT_DOUBLE);
+#else
+   glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);
+#endif
Win = glutCreateWindow(argv[0]);
+   /* glewInit requires glewExperimentel set to true for core profiles.
+* Depending on the glew version it also generates a GL_INVALID_ENUM.
+*/
+   glewExperimental = GL_TRUE;
glewInit();
+   glGetError();
glutReshapeFunc(Reshape);
glutKeyboardFunc(Key);
glutDisplayFunc(Redisplay);
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 11/12] geom-outlining-150: Use core geometry shaders.

2014-02-13 Thread Fabian Bieler
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/geom-outlining-150.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 0bc20f0..3dffa16 100644
--- a/src/glsl/geom-outlining-150.c
+++ b/src/glsl/geom-outlining-150.c
@@ -256,7 +256,8 @@ Init(void)
   } \n;
static const char *geomShaderText =
   #version 150 \n
-  #extension GL_ARB_geometry_shader4: enable \n
+  layout(triangles) in; \n
+  layout(triangle_strip, max_vertices = 3) out; \n
   uniform vec2 ViewportSize; \n
   out vec2 Vert0, Vert1, Vert2; \n
   \n
@@ -271,11 +272,11 @@ Init(void)
  Vert0 = vpxform(gl_in[0].gl_Position); \n
  Vert1 = vpxform(gl_in[1].gl_Position); \n
  Vert2 = vpxform(gl_in[2].gl_Position); \n
- gl_Position = gl_PositionIn[0]; \n
+ gl_Position = gl_in[0].gl_Position; \n
  EmitVertex(); \n
- gl_Position = gl_PositionIn[1]; \n
+ gl_Position = gl_in[1].gl_Position; \n
  EmitVertex(); \n
- gl_Position = gl_PositionIn[2]; \n
+ gl_Position = gl_in[2].gl_Position; \n
  EmitVertex(); \n
   } \n;
static const char *fragShaderText =
@@ -309,15 +310,14 @@ Init(void)
if (!ShadersSupported())
   exit(1);
 
-   version = glGetString(GL_VERSION);
-   if (version[0] * 10 + version[2]  32) {
+   if (!GLEW_VERSION_3_2) {
   fprintf(stderr, Sorry, OpenGL 3.2 or later required.\n);
   exit(1);
}
 
VertShader = CompileShaderText(GL_VERTEX_SHADER, vertShaderText);
FragShader = CompileShaderText(GL_FRAGMENT_SHADER, fragShaderText);
-   GeomShader = CompileShaderText(GL_GEOMETRY_SHADER_ARB, geomShaderText);
+   GeomShader = CompileShaderText(GL_GEOMETRY_SHADER, geomShaderText);
 
Program = LinkShaders3(VertShader, GeomShader, FragShader);
assert(Program);
@@ -326,18 +326,8 @@ Init(void)
glBindAttribLocation(Program, 0, Vertex);
glBindFragDataLocation(Program, 0, FragColor);
 
-   /*
-* The geometry shader will receive and emit triangles.
-*/
-   glProgramParameteriARB(Program, GL_GEOMETRY_INPUT_TYPE_ARB,
-  GL_TRIANGLES);
-   glProgramParameteriARB(Program, GL_GEOMETRY_OUTPUT_TYPE_ARB,
-  GL_TRIANGLE_STRIP);
-   glProgramParameteriARB(Program,GL_GEOMETRY_VERTICES_OUT_ARB, 3);
-   CheckError(__LINE__);
-
/* relink */
-   glLinkProgramARB(Program);
+   glLinkProgram(Program);
 
assert(glIsProgram(Program));
assert(glIsShader(FragShader));
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 01/12] configure.ac: Check for freeglut.

2014-02-13 Thread Fabian Bieler
To get an OpenGL core profile context freeglut 2.6 or later is required.

Note that in spite of it's name HAVE_FREEGLUT is only defined if freeglut 2.6
(released in 2009) or later ist found.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 configure.ac | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configure.ac b/configure.ac
index 0c38f4d..cd523c1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,12 @@ AC_CHECK_LIB([glut],
[],
[glut_enabled=no])
 
+dnl Check for FreeGLUT 2.6 or later
+AC_EGREP_HEADER([glutInitContextProfile],
+   [GL/freeglut.h],
+   [AC_DEFINE(HAVE_FREEGLUT)],
+   [])
+
 dnl Check for GLEW
 PKG_CHECK_MODULES(GLEW, [glew = 1.5.4])
 DEMO_CFLAGS=$DEMO_CFLAGS $GLEW_CFLAGS
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 05/12] glsl/gsraytrace: Bind transform feedback buffer.

2014-02-13 Thread Fabian Bieler
Bind the transform feedback buffer before drawing into it und unbind it
afterwards.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index f156fdc..015bfcd 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -628,6 +628,7 @@ Draw(void)
printf(%d\n, i);
//gs.fpwQuery-beginQuery();
//gs.pgQuery-beginQuery();
+   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst);
glBeginQuery(GL_PRIMITIVES_GENERATED_NV, pgQuery);
glBeginTransformFeedbackNV(GL_POINTS);
//gs.eyeRaysAsPoints-bindAs(ARRAY);
@@ -675,7 +676,7 @@ Draw(void)
 
 
swap(src, dst);
-   glBindBufferOffsetNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst-getID(), 
0); pso_gl_check();
+   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, 0);
 
clear();
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 09/12] glsl/gsraytrace: Switch to core profile.

2014-02-13 Thread Fabian Bieler
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 6df6543..3eec835 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -70,7 +70,7 @@ float rot[9] = {1,0,0,  0,1,0,   0,0,1};
 
 static const char* vsSource =
   \n
-#version 150  \n
+#version 150 core \n
 #line  S__LINE__ \n
 #define SHADOWS   \n
 #define RECURSION \n
@@ -253,7 +253,7 @@ static const char* vsSource =
 
 
 static const char* gsSource = 
-#version 150 \n
+#version 150 core\n
 #line  S__LINE__ \n
 layout(points) in;   \n
 layout(points, max_vertices = 3) out;\n
@@ -393,7 +393,7 @@ static const char* gsSource =
 }\n;
 
 static const char* fsSource = 
-#version 150 \n
+#version 150 core\n
 #line  S__LINE__ \n
  \n
 #define SHADOWS  \n
@@ -408,6 +408,7 @@ static const char* fsSource =
 uniform vec4 backgroundColor;\n
 uniform int emitNoMore;  \n
  \n
+out vec4 frag_color; \n
  \n
 //---\n
  \n
@@ -493,7 +494,7 @@ static const char* fsSource =
 Isec eyeHit = isec;\n
 if (eyeHit.idx == -1)\n
 {\n
-  gl_FragColor = vec4(backgroundColor.rgb, 0.0);\n
+  frag_color = vec4(backgroundColor.rgb, 0.0);\n
   return;\n
 }\n
 vec3 eyeHitPosition = eyeRay.orig + eyeRay.dir * eyeHit.t;\n
@@ -503,7 +504,7 @@ static const char* fsSource =
 vec3  L  = normalize(lightVec);   
  \n
 float NdotL  = max(dot(N, L), 0.0);   
  \n
 vec3 diffuse = idx2color(eyeHit.idx); // material color of the visible 
point\n
-gl_FragColor = vec4(diffuse * NdotL, 1.0);
  \n
+frag_color = vec4(diffuse * NdotL, 1.0);  
\n
 return;\n
   }\n
 #ifdef SHADOWS \n
@@ -514,7 +515,7 @@ static const char* fsSource =
 { \n
   discard;\n
 } \n
-gl_FragColor = vec4(-1,-1,-1, 0.0);   \n
+frag_color = vec4(-1,-1,-1, 0.0);   \n
 return;   \n
   }   \n
 #endif\n
@@ -534,7 +535,7 @@ static const char* fsSource =
 vec3  L  = normalize(lightVec);   \n
 float NdotL  = max(dot(N, L), 0.0);   \n
 vec3 diffuse = idx2color(reflHit.idx);\n
-gl_FragColor = vec4(diffuse * NdotL * 0.25, 1.0); // material color of 
the visible point\n
+frag_color = vec4(diffuse * NdotL * 0.25, 1.0); // material color of the 
visible point\n
 return;   \n
   }   \n
 #endif\n
@@ -608,6 +609,8 @@ Draw(void)
dir_idxAttribLoc = glGetAttribLocation(program, dir_idx);
uv_stateAttribLoc = glGetAttribLocation(program, uv_state);
 
+   glBindFragDataLocation(program, 0, frag_color);
+
printf(%d\n, i);
//gs.fpwQuery-beginQuery();
//gs.pgQuery-beginQuery();
@@ -755,10 +758,6 @@ Reshape(int width, int height)
WinWidth = width;
WinHeight = height;
glViewport(0, 0, width, height);
-   glMatrixMode(GL_PROJECTION);
-   

[Mesa-dev] [PATCH 10/12] geom-outlining-150: Use a vbo.

2014-02-13 Thread Fabian Bieler
Use a vbo for vertex data instead of client-side arrays.
Also bind a vertex array object.

This is necessary for the switch to a core profile context.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/geom-outlining-150.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 5c2b3c9..0bc20f0 100644
--- a/src/glsl/geom-outlining-150.c
+++ b/src/glsl/geom-outlining-150.c
@@ -23,6 +23,7 @@
 static GLint WinWidth = 500, WinHeight = 500;
 static GLint Win = 0;
 static GLuint VertShader, GeomShader, FragShader, Program;
+static GLuint vao, vbo;
 static GLboolean Anim = GL_TRUE;
 static int uViewportSize = -1, uModelViewProj = -1, uColor = -1;
 
@@ -112,11 +113,6 @@ mat_multiply(GLfloat product[16], const GLfloat a[16], 
const GLfloat b[16])
 static void
 Redisplay(void)
 {
-   static const GLfloat verts[3][2] = {
-  { -1, -1 },
-  {  1, -1 },
-  {  0,  1 }
-   };
GLfloat rot[4][4];
GLfloat trans[16], mvp[16];
 
@@ -131,8 +127,6 @@ Redisplay(void)
glUniformMatrix4fv(uModelViewProj, 1, GL_FALSE, (float *) mvp);
 
/* Draw */
-   glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 0, verts);
-   glEnableVertexAttribArray(0);
glDrawArrays(GL_TRIANGLES, 0, 3);
 
glutSwapBuffers();
@@ -217,6 +211,8 @@ CleanUp(void)
glDeleteShader(VertShader);
glDeleteShader(GeomShader);
glDeleteProgram(Program);
+   glDeleteVertexArrays(1, vao);
+   glDeleteBuffers(1, vbo);
glutDestroyWindow(Win);
 }
 
@@ -304,6 +300,11 @@ Init(void)
  float m = min(d0, min(d1, d2)); \n
  FragColor = Color * smoothstep(0.0, LINE_WIDTH, m); \n
   } \n;
+   static const GLfloat verts[3][2] = {
+  { -1, -1 },
+  {  1, -1 },
+  {  0,  1 }
+   };
 
if (!ShadersSupported())
   exit(1);
@@ -351,6 +352,16 @@ Init(void)
 
glUniform4fv(uColor, 1, Orange);
 
+   glGenBuffers(1, vbo);
+   glBindBuffer(GL_ARRAY_BUFFER, vbo);
+   glBufferData(GL_ARRAY_BUFFER, sizeof(verts), verts, GL_STATIC_DRAW);
+
+   glGenVertexArrays(1, vao);
+   glBindVertexArray(vao);
+
+   glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 0, NULL);
+   glEnableVertexAttribArray(0);
+
glClearColor(0.3f, 0.3f, 0.3f, 0.0f);
glEnable(GL_DEPTH_TEST);
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 04/12] glsl/gsraytrace: Don't create new Buffer objects everytime the window is resized.

2014-02-13 Thread Fabian Bieler
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index c21c667..f156fdc 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -776,7 +776,6 @@ Reshape(int width, int height)
 
{
   size_t nElem = WinWidth*WinHeight*nRayGens;
-  glGenBuffers(1, dst);
   glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, dst);
   glBufferData(GL_TRANSFORM_FEEDBACK_BUFFER_NV, nElem*sizeof(GSRay), 0, 
GL_STREAM_DRAW);
   GSRay* d = (GSRay*)glMapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 
GL_READ_WRITE);
@@ -790,7 +789,6 @@ Reshape(int width, int height)
}
 
{
-  glGenBuffers(1, eyeRaysAsPoints);
   glBindBuffer(GL_ARRAY_BUFFER, eyeRaysAsPoints);
   glBufferData(GL_ARRAY_BUFFER, WinWidth*WinHeight*sizeof(GSRay), 0, 
GL_STATIC_DRAW);
   GSRay* d = (GSRay*)glMapBuffer(GL_ARRAY_BUFFER, GL_READ_WRITE);
@@ -919,6 +917,8 @@ Init(void)
}
 
glGenQueries(1, pgQuery);
+   glGenBuffers(1, dst);
+   glGenBuffers(1, eyeRaysAsPoints);
 
printf(\nESC = exit demo\nleft mouse + drag   = rotate 
camera\n\n);
 }
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] clover: Pass buffer offsets to the driver in set_global_binding()

2014-02-13 Thread Tom Stellard
From: Tom Stellard thomas.stell...@amd.com

The offsets will be stored in the handles parameter.  This makes
it possible to use sub-buffers.
---
 src/gallium/drivers/r600/evergreen_compute.c  |  2 +-
 src/gallium/drivers/radeonsi/si_compute.c |  1 +
 src/gallium/include/pipe/p_context.h  |  9 ++---
 src/gallium/state_trackers/clover/core/kernel.cpp | 11 +--
 4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
b/src/gallium/drivers/r600/evergreen_compute.c
index 70efe5c..ee00a24 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -665,7 +665,7 @@ static void evergreen_set_global_binding(
assert(resources[i]-target == PIPE_BUFFER);
assert(resources[i]-bind  PIPE_BIND_GLOBAL);
 
-   *(handles[i]) = buffers[i]-chunk-start_in_dw * 4;
+   *(handles[i]) += buffers[i]-chunk-start_in_dw * 4;
}
 
evergreen_set_rat(ctx-cs_shader_state.shader, 0, pool-bo, 0, 
pool-size_in_dw * 4);
diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index a7f49e7..e0e6bb4 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -109,6 +109,7 @@ static void si_set_global_binding(
uint64_t va;
program-global_buffers[i] = resources[i];
va = r600_resource_va(ctx-screen, resources[i]);
+   va += *handles[i];
memcpy(handles[i], va, sizeof(va));
}
 }
diff --git a/src/gallium/include/pipe/p_context.h 
b/src/gallium/include/pipe/p_context.h
index 8ef6e27..eef0a63 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -461,9 +461,12 @@ struct pipe_context {
 *   resources will be bound.
 * \param handlesarray of pointers to the memory locations that
 *   will be filled with the respective base
-*   addresses each buffer will be mapped to.  It
-*   should contain at least \a count elements,
-*   unless \a resources is NULL in which case \a
+*   addresses each buffer will be mapped to.  When
+*   this function is called, the value at these memory
+*   locations will be the offset in bytes from
+*   the start of the buffer that should be used to
+*   compute the handle.  It should contain at least \a 
count
+*   elements, unless \a resources is NULL in which case \a
 *   handles should be NULL as well.
 *
 * Note that the driver isn't required to make any guarantees about
diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp 
b/src/gallium/state_trackers/clover/core/kernel.cpp
index 6d894cd..06eff85 100644
--- a/src/gallium/state_trackers/clover/core/kernel.cpp
+++ b/src/gallium/state_trackers/clover/core/kernel.cpp
@@ -337,8 +337,15 @@ kernel::global_argument::bind(exec_context ctx,
align(ctx.input, marg.target_align);
 
if (buf) {
-  ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
-  ctx.g_buffers.push_back(buf-resource(*ctx.q).pipe);
+  resource r = buf-resource(*ctx.q);
+  ctx.g_handles.push_back(ctx.input.size());
+  ctx.g_buffers.push_back(r.pipe);
+
+  // XXX: How to handle multi-demensional offsets?
+  assert(!r.offset[1]  !r.offset[2]);
+  std::vectoruint8_t offset = bytes(r.offset[0]);
+  extend(offset, marg.ext_type, marg.target_size);
+  insert(ctx.input, offset);
} else {
   // Null pointer.
   allocate(ctx.input, marg.target_size);
-- 
1.8.1.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 69101] prime: black window

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=69101

--- Comment #23 from Mike Lothian m...@fireburn.co.uk ---
With the patch glxgears launches successfully around 50% of the time - which is
an improvement - this is on r600g from mesa master - opencl still works for me
though

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 69101] prime: black window

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=69101

--- Comment #24 from Jan Vesely jano.ves...@gmail.com ---
(In reply to comment #22)
 Can anyone test this patch?
 https://bugzilla.kernel.org/show_bug.cgi?id=65761#c41
 
 Beware, it currently breaks opencl and possibly other things, but if it
 helps, then we at least know a little bit more about what causes the problem.

the patch does not change anything for me.
glxgears and openarena works ok with or without the patch (modulo nvd9 crashes)
unigine heaven/valley show transparent window (and then crash)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 69101] prime: black window

2014-02-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=69101

--- Comment #25 from Christoph Haag haagch.christ...@googlemail.com ---
Okay then, sorry to bother you.

People are still talking about different issues here, aren't they?

Curiously for me with ivy bridge + radeonsi with this patch 64 bit glxgears
works every start now and 32 bit glxgears has a black screen every start until
it's resized etc.
It's a strange issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] R600/SI: Custom select 64-bit ADD

2014-02-13 Thread Matt Arsenault

On Feb 7, 2014, at 7:46 AM, Tom Stellard t...@stellard.net wrote:

 From: Tom Stellard thomas.stell...@amd.com
 
 ---
 lib/Target/R600/AMDGPUISelDAGToDAG.cpp | 48 ++
 lib/Target/R600/SIISelLowering.cpp | 29 
 lib/Target/R600/SIISelLowering.h   |  1 -
 test/CodeGen/R600/add.ll   | 10 +++
 test/CodeGen/R600/add_i64.ll   | 23 +++-
 5 files changed, 75 insertions(+), 36 deletions(-)
 
 diff --git a/lib/Target/R600/AMDGPUISelDAGToDAG.cpp 
 b/lib/Target/R600/AMDGPUISelDAGToDAG.cpp
 index a989135..fea875c 100644
 --- a/lib/Target/R600/AMDGPUISelDAGToDAG.cpp
 +++ b/lib/Target/R600/AMDGPUISelDAGToDAG.cpp
 @@ -200,6 +200,54 @@ SDNode *AMDGPUDAGToDAGISel::Select(SDNode *N) {
   }
   switch (Opc) {
   default: break;
 +  // We are selecting i64 ADD here instead of custom lower it during
 +  // DAG legalization, so we can fold some i64 ADDs used for address
 +  // calculation into the LOAD and STORE instructions.
 +  case ISD::ADD: {
 +const AMDGPUSubtarget ST = TM.getSubtargetAMDGPUSubtarget();
 +if (N-getValueType(0) != MVT::i64 ||
 +ST.getGeneration()  AMDGPUSubtarget::SOUTHERN_ISLANDS)
 +  break;
 +
 +SDLoc DL(N);
 +SDValue LHS = N-getOperand(0);
 +SDValue RHS = N-getOperand(1);
 +
 +SDValue Sub0 = CurDAG-getTargetConstant(AMDGPU::sub0, MVT::i32);
 +SDValue Sub1 = CurDAG-getTargetConstant(AMDGPU::sub1, MVT::i32);
 +
 +SDNode *Lo0 = CurDAG-getMachineNode(TargetOpcode::EXTRACT_SUBREG,
 + DL, MVT::i32, LHS, Sub0);
 +SDNode *Hi0 = CurDAG-getMachineNode(TargetOpcode::EXTRACT_SUBREG,
 + DL, MVT::i32, LHS, Sub1);
 +
 +SDNode *Lo1 = CurDAG-getMachineNode(TargetOpcode::EXTRACT_SUBREG,
 + DL, MVT::i32, RHS, Sub0);
 +SDNode *Hi1 = CurDAG-getMachineNode(TargetOpcode::EXTRACT_SUBREG,
 + DL, MVT::i32, RHS, Sub1);
 +
 +SDVTList VTList = CurDAG-getVTList(MVT::i32, MVT::Glue);
 +
 +SmallVectorSDValue, 8 AddLoArgs;
 +AddLoArgs.push_back(SDValue(Lo0, 0));
 +AddLoArgs.push_back(SDValue(Lo1, 0));
 +
 +SDNode *AddLo = CurDAG-getMachineNode(AMDGPU::S_ADD_I32, DL,
 +   VTList, AddLoArgs);
 +SDValue Carry = SDValue(AddLo, 1);
 +SDNode *AddHi = CurDAG-getMachineNode(AMDGPU::S_ADDC_U32, DL,
 +   MVT::i32, SDValue(Hi0, 0),
 +   SDValue(Hi1, 0), Carry);
 +
 +SDValue Args[5] = {
 +  CurDAG-getTargetConstant(AMDGPU::SReg_64RegClassID, MVT::i32),
 +  SDValue(AddLo,0),
 +  Sub0,
 +  SDValue(AddHi,0),
 +  Sub1,
 +};
 +return CurDAG-SelectNodeTo(N, AMDGPU::REG_SEQUENCE, MVT::i64, Args, 5);
 +  }
   case ISD::BUILD_VECTOR: {
 unsigned RegClassID;
 const AMDGPUSubtarget ST = TM.getSubtargetAMDGPUSubtarget();
 diff --git a/lib/Target/R600/SIISelLowering.cpp 
 b/lib/Target/R600/SIISelLowering.cpp
 index 0a22d16..4d2f370 100644
 --- a/lib/Target/R600/SIISelLowering.cpp
 +++ b/lib/Target/R600/SIISelLowering.cpp
 @@ -76,7 +76,6 @@ SITargetLowering::SITargetLowering(TargetMachine TM) :
   setOperationAction(ISD::VECTOR_SHUFFLE, MVT::v16i32, Expand);
   setOperationAction(ISD::VECTOR_SHUFFLE, MVT::v16f32, Expand);
 
 -  setOperationAction(ISD::ADD, MVT::i64, Legal);

Would it be better to mark this as custom lowered, and then just return 
SDValue() for it? That way it won’t be incorrectly reported as legal for 
anything that might be checking.

   setOperationAction(ISD::ADD, MVT::i32, Legal);
   setOperationAction(ISD::ADDC, MVT::i32, Legal);
   setOperationAction(ISD::ADDE, MVT::i32, Legal);
 @@ -475,7 +474,6 @@ SDValue SITargetLowering::LowerOperation(SDValue Op, 
 SelectionDAG DAG) const {
   SIMachineFunctionInfo *MFI = MF.getInfoSIMachineFunctionInfo();
   switch (Op.getOpcode()) {
   default: return AMDGPUTargetLowering::LowerOperation(Op, DAG);
 -  case ISD::ADD: return LowerADD(Op, DAG);
   case ISD::BRCOND: return LowerBRCOND(Op, DAG);
   case ISD::LOAD: {
 LoadSDNode *Load = dyn_castLoadSDNode(Op);
 @@ -613,33 +611,6 @@ SDValue SITargetLowering::LowerOperation(SDValue Op, 
 SelectionDAG DAG) const {
   return SDValue();
 }
 
 -SDValue SITargetLowering::LowerADD(SDValue Op,
 -   SelectionDAG DAG) const {
 -  if (Op.getValueType() != MVT::i64)
 -return SDValue();
 -
 -  SDLoc DL(Op);
 -  SDValue LHS = Op.getOperand(0);
 -  SDValue RHS = Op.getOperand(1);
 -
 -  SDValue Zero = DAG.getConstant(0, MVT::i32);
 -  SDValue One = DAG.getConstant(1, MVT::i32);
 -
 -  SDValue Lo0 = DAG.getNode(ISD::EXTRACT_ELEMENT, DL, MVT::i32, LHS, Zero);
 -  SDValue Hi0 = DAG.getNode(ISD::EXTRACT_ELEMENT, DL, MVT::i32, LHS, One);
 -
 -  SDValue Lo1 = DAG.getNode(ISD::EXTRACT_ELEMENT, DL, MVT::i32, RHS, Zero);
 -  SDValue Hi1 = 

[Mesa-dev] [PATCH 02/19] svga: update dumping code with new GBS commands, etc

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svgadump/svga_dump.c |  312 +
 1 file changed, 268 insertions(+), 44 deletions(-)

diff --git a/src/gallium/drivers/svga/svgadump/svga_dump.c 
b/src/gallium/drivers/svga/svgadump/svga_dump.c
index 67d86d2..0874d23 100644
--- a/src/gallium/drivers/svga/svgadump/svga_dump.c
+++ b/src/gallium/drivers/svga/svgadump/svga_dump.c
@@ -37,6 +37,22 @@
 #include util/u_debug.h
 #include svga_dump.h
 
+static const char *
+shader_name(unsigned type)
+{
+   switch (type) {
+   case SVGA3D_SHADERTYPE_VS:
+  return SVGA3D_SHADERTYPE_VS;
+   case SVGA3D_SHADERTYPE_PS:
+  return SVGA3D_SHADERTYPE_PS;
+   case SVGA3D_SHADERTYPE_GS:
+  return SVGA3D_SHADERTYPE_GS;
+   default:
+  return unknown shader type!;
+   }
+}
+
+
 static void
 dump_SVGA3dVertexDecl(const SVGA3dVertexDecl *cmd)
 {
@@ -509,20 +525,7 @@ static void
 dump_SVGA3dCmdSetShader(const SVGA3dCmdSetShader *cmd)
 {
_debug_printf(\t\t.cid = %u\n, (*cmd).cid);
-   switch((*cmd).type) {
-   case SVGA3D_SHADERTYPE_VS:
-  _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_VS\n);
-  break;
-   case SVGA3D_SHADERTYPE_PS:
-  _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_PS\n);
-  break;
-   case SVGA3D_SHADERTYPE_MAX:
-  _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_MAX\n);
-  break;
-   default:
-  _debug_printf(\t\t.type = %i\n, (*cmd).type);
-  break;
-   }
+   _debug_printf(\t\t.type = %s\n, shader_name(cmd-type));
_debug_printf(\t\t.shid = %u\n, (*cmd).shid);
 }
 
@@ -918,7 +921,7 @@ dump_SVGA3dCmdDefineShader(const SVGA3dCmdDefineShader *cmd)
case SVGA3D_SHADERTYPE_PS:
   _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_PS\n);
   break;
-   case SVGA3D_SHADERTYPE_MAX:
+   case SVGA3D_SHADERTYPE_PREDX_MAX:
   _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_MAX\n);
   break;
default:
@@ -928,34 +931,20 @@ dump_SVGA3dCmdDefineShader(const SVGA3dCmdDefineShader 
*cmd)
 }
 
 static void
-dump_SVGA3dCmdSetShaderConst(const SVGA3dCmdSetShaderConst *cmd, uint32 
numConsts)
+dump_constants(SVGA3dShaderConstType type, unsigned start,
+   unsigned numConsts, const void *buf)
 {
-   uint32 i;
+   unsigned i;
const float (*fvalues)[4];
const int32 (*ivalues)[4];
-   _debug_printf(\t\t.cid = %u\n, (*cmd).cid);
-   _debug_printf(\t\t.reg = %u\n, (*cmd).reg);
-   switch((*cmd).type) {
-   case SVGA3D_SHADERTYPE_VS:
-  _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_VS\n);
-  break;
-   case SVGA3D_SHADERTYPE_PS:
-  _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_PS\n);
-  break;
-   case SVGA3D_SHADERTYPE_MAX:
-  _debug_printf(\t\t.type = SVGA3D_SHADERTYPE_MAX\n);
-  break;
-   default:
-  _debug_printf(\t\t.type = %i\n, (*cmd).type);
-  break;
-   }
-   switch((*cmd).ctype) {
+
+   switch (type) {
case SVGA3D_CONST_TYPE_FLOAT:
   _debug_printf(\t\t.ctype = SVGA3D_CONST_TYPE_FLOAT\n);
-  fvalues = (const float (*)[4])cmd-values;
+  fvalues = (const float (*)[4]) buf;
   for (i = 0; i  numConsts; ++i) {
  _debug_printf(\t\t.values[%u] = {%f, %f, %f, %f}\n,
-   cmd-reg + i, 
+   start + i, 
fvalues[i][0],
fvalues[i][1],
fvalues[i][2],
@@ -964,10 +953,10 @@ dump_SVGA3dCmdSetShaderConst(const 
SVGA3dCmdSetShaderConst *cmd, uint32 numConst
   break;
case SVGA3D_CONST_TYPE_INT:
   _debug_printf(\t\t.ctype = SVGA3D_CONST_TYPE_INT\n);
-  ivalues = (const int32 (*)[4])cmd-values;
+  ivalues = (const int32 (*)[4]) buf;
   for (i = 0; i  numConsts; ++i) {
  _debug_printf(\t\t.values[%u] = {%i, %i, %i, %i}\n,
-   cmd-reg + i,
+   start + i,
ivalues[i][0],
ivalues[i][1],
ivalues[i][2],
@@ -976,10 +965,10 @@ dump_SVGA3dCmdSetShaderConst(const 
SVGA3dCmdSetShaderConst *cmd, uint32 numConst
   break;
case SVGA3D_CONST_TYPE_BOOL:
   _debug_printf(\t\t.ctype = SVGA3D_CONST_TYPE_BOOL\n);
-  ivalues = (const int32 (*)[4])cmd-values;
+  ivalues = (const int32 (*)[4]) buf;
   for (i = 0; i  numConsts; ++i) {
  _debug_printf(\t\t.values[%u] = {%i, %i, %i, %i}\n,
-   cmd-reg + i,
+   start + i,
ivalues[i][0],
ivalues[i][1],
ivalues[i][2],
@@ -987,11 +976,11 @@ dump_SVGA3dCmdSetShaderConst(const 
SVGA3dCmdSetShaderConst *cmd, uint32 numConst
   }
   break;
default:
-  _debug_printf(\t\t.ctype = %i\n, (*cmd).ctype);
-  ivalues = (const int32 (*)[4])cmd-values;
+  _debug_printf(\t\t.ctype = %i\n, type);
+  ivalues = (const int32 (*)[4]) buf;
   for (i = 0; i  numConsts; ++i) {
  

[Mesa-dev] [PATCH 00/19] VMware svga driver updates

2014-02-13 Thread Brian Paul


This patch series implements guest backed surfaces in the VMware svga 
gallium driver.  It's all VMware-specific, except for two patches which 
touch the pb_cache_manager_create() function from 
src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c  We've added two new 
parameters to that function.  The only other driver which uses it is the 
radeon driver.


If anyone cares about that that change, please review.  Otherwise, this 
is code we've been running in-house for a while and Thomas Hellstrom 
(and others) has reviewed it.  I'd like to push to master tomorrow.


Also, I'd like to get this into the pending 10.1 release.  Since the 
changes are pretty well isolated I don't expect that to be a problem.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 03/19] svga: update svga_winsys interface for GBS

2014-02-13 Thread Brian Paul
This adds new interface functions for guest-backed surfaces and
adds a mobid parameter to the surface_relocation() function.

Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_cmd.c|   14 ++-
 src/gallium/drivers/svga/svga_draw.c   |4 +-
 .../drivers/svga/svga_resource_buffer_upload.c |2 +-
 src/gallium/drivers/svga/svga_state_tss.c  |2 +
 src/gallium/drivers/svga/svga_winsys.h |  131 +++-
 src/gallium/winsys/svga/drm/vmw_context.c  |1 +
 6 files changed, 141 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_cmd.c 
b/src/gallium/drivers/svga/svga_cmd.c
index 542bd12..6155e85 100644
--- a/src/gallium/drivers/svga/svga_cmd.c
+++ b/src/gallium/drivers/svga/svga_cmd.c
@@ -62,12 +62,12 @@ surface_to_surfaceid(struct svga_winsys_context *swc, // IN
 {
if (surface) {
   struct svga_surface *s = svga_surface(surface);
-  swc-surface_relocation(swc, id-sid, s-handle, flags);
+  swc-surface_relocation(swc, id-sid, NULL, s-handle, flags);
   id-face = s-real_face; /* faces have the same order */
   id-mipmap = s-real_level;
}
else {
-  swc-surface_relocation(swc, id-sid, NULL, flags);
+  swc-surface_relocation(swc, id-sid, NULL, NULL, flags);
   id-face = 0;
   id-mipmap = 0;
}
@@ -280,7 +280,7 @@ SVGA3D_BeginDefineSurface(struct svga_winsys_context *swc,
if (!cmd)
   return PIPE_ERROR_OUT_OF_MEMORY;
 
-   swc-surface_relocation(swc, cmd-sid, sid, SVGA_RELOC_WRITE);
+   swc-surface_relocation(swc, cmd-sid, NULL, sid, SVGA_RELOC_WRITE);
cmd-surfaceFlags = flags;
cmd-format = format;
 
@@ -366,7 +366,7 @@ SVGA3D_DestroySurface(struct svga_winsys_context *swc,
if (!cmd)
   return PIPE_ERROR_OUT_OF_MEMORY;
 
-   swc-surface_relocation(swc, cmd-sid, sid, SVGA_RELOC_READ);
+   swc-surface_relocation(swc, cmd-sid, NULL, sid, SVGA_RELOC_READ);
swc-commit(swc);;
 
return PIPE_OK;
@@ -453,7 +453,8 @@ SVGA3D_SurfaceDMA(struct svga_winsys_context *swc,
swc-region_relocation(swc, cmd-guest.ptr, st-hwbuf, 0, region_flags);
cmd-guest.pitch = st-base.stride;
 
-   swc-surface_relocation(swc, cmd-host.sid, texture-handle, 
surface_flags);
+   swc-surface_relocation(swc, cmd-host.sid, NULL,
+   texture-handle, surface_flags);
cmd-host.face = st-face; /* PIPE_TEX_FACE_* and SVGA3D_CUBEFACE_* match */
cmd-host.mipmap = st-base.level;
 
@@ -511,7 +512,8 @@ SVGA3D_BufferDMA(struct svga_winsys_context *swc,
swc-region_relocation(swc, cmd-guest.ptr, guest, 0, region_flags);
cmd-guest.pitch = 0;
 
-   swc-surface_relocation(swc, cmd-host.sid, host, surface_flags);
+   swc-surface_relocation(swc, cmd-host.sid,
+   NULL, host, surface_flags);
cmd-host.face = 0;
cmd-host.mipmap = 0;
 
diff --git a/src/gallium/drivers/svga/svga_draw.c 
b/src/gallium/drivers/svga/svga_draw.c
index 5e46a2f..80dbc35 100644
--- a/src/gallium/drivers/svga/svga_draw.c
+++ b/src/gallium/drivers/svga/svga_draw.c
@@ -240,7 +240,7 @@ svga_hwtnl_flush(struct svga_hwtnl *hwtnl)
 vdecl[i].rangeHint.last = 0;
  }
 
- swc-surface_relocation(swc, vdecl[i].array.surfaceId,
+ swc-surface_relocation(swc, vdecl[i].array.surfaceId, NULL,
  vb_handle[i], SVGA_RELOC_READ);
   }
 
@@ -248,7 +248,7 @@ svga_hwtnl_flush(struct svga_hwtnl *hwtnl)
  hwtnl-cmd.prim_count * sizeof hwtnl-cmd.prim[0]);
 
   for (i = 0; i  hwtnl-cmd.prim_count; i++) {
- swc-surface_relocation(swc, prim[i].indexArray.surfaceId,
+ swc-surface_relocation(swc, prim[i].indexArray.surfaceId, NULL,
  ib_handle[i], SVGA_RELOC_READ);
  pipe_resource_reference(hwtnl-cmd.prim_ib[i], NULL);
   }
diff --git a/src/gallium/drivers/svga/svga_resource_buffer_upload.c 
b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
index e6bbc00..af39973 100644
--- a/src/gallium/drivers/svga/svga_resource_buffer_upload.c
+++ b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
@@ -213,7 +213,7 @@ svga_buffer_upload_command(struct svga_context *svga,
swc-region_relocation(swc, cmd-guest.ptr, guest, 0, region_flags);
cmd-guest.pitch = 0;
 
-   swc-surface_relocation(swc, cmd-host.sid, host, surface_flags);
+   swc-surface_relocation(swc, cmd-host.sid, NULL, host, surface_flags);
cmd-host.face = 0;
cmd-host.mipmap = 0;
 
diff --git a/src/gallium/drivers/svga/svga_state_tss.c 
b/src/gallium/drivers/svga/svga_state_tss.c
index 137e208..988372f 100644
--- a/src/gallium/drivers/svga/svga_state_tss.c
+++ b/src/gallium/drivers/svga/svga_state_tss.c
@@ -153,6 +153,7 @@ update_tss_binding(struct svga_context *svga,
  }
  svga-swc-surface_relocation(svga-swc,
ts[i].value,
+ 

[Mesa-dev] [PATCH 07/19] svga: update shader code for GBS

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_context.c  |4 +++
 src/gallium/drivers/svga/svga_context.h  |2 ++
 src/gallium/drivers/svga/svga_draw.c |   14 
 src/gallium/drivers/svga/svga_shader.c   |   21 ++-
 src/gallium/drivers/svga/svga_state.h|4 +++
 src/gallium/drivers/svga/svga_state_fs.c |   58 --
 src/gallium/drivers/svga/svga_state_vs.c |   56 -
 src/gallium/drivers/svga/svga_tgsi.h |3 ++
 8 files changed, 142 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index de769ca..4da9a65 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -197,6 +197,10 @@ void svga_context_flush( struct svga_context *svga,
 */
svga-rebind.rendertargets = TRUE;
svga-rebind.texture_samplers = TRUE;
+   if (svga_have_gb_objects(svga)) {
+  svga-rebind.vs = TRUE;
+  svga-rebind.fs = TRUE;
+   }
 
if (SVGA_DEBUG  DEBUG_SYNC) {
   if (fence)
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index 71a8eea..0daab0b 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -374,6 +374,8 @@ struct svga_context
struct {
   unsigned rendertargets:1;
   unsigned texture_samplers:1;
+  unsigned vs:1;
+  unsigned fs:1;
} rebind;
 
struct svga_hwtnl *hwtnl;
diff --git a/src/gallium/drivers/svga/svga_draw.c 
b/src/gallium/drivers/svga/svga_draw.c
index 80dbc35..fa0cac4 100644
--- a/src/gallium/drivers/svga/svga_draw.c
+++ b/src/gallium/drivers/svga/svga_draw.c
@@ -213,6 +213,20 @@ svga_hwtnl_flush(struct svga_hwtnl *hwtnl)
  }
   }
 
+  if (svga-rebind.vs) {
+ ret = svga_reemit_vs_bindings(svga);
+ if (ret != PIPE_OK) {
+return ret;
+ }
+  }
+
+  if (svga-rebind.fs) {
+ ret = svga_reemit_fs_bindings(svga);
+ if (ret != PIPE_OK) {
+return ret;
+ }
+  }
+
   SVGA_DBG(DEBUG_DMA, draw to sid %p, %d prims\n,
svga-curr.framebuffer.cbufs[0] ?
svga_surface(svga-curr.framebuffer.cbufs[0])-handle : NULL,
diff --git a/src/gallium/drivers/svga/svga_shader.c 
b/src/gallium/drivers/svga/svga_shader.c
index 88877b2..6b6b441 100644
--- a/src/gallium/drivers/svga/svga_shader.c
+++ b/src/gallium/drivers/svga/svga_shader.c
@@ -43,7 +43,17 @@ svga_define_shader(struct svga_context *svga,
 {
unsigned codeLen = variant-nr_tokens * sizeof(variant-tokens[0]);
 
-   {
+   if (svga_have_gb_objects(svga)) {
+  struct svga_winsys_screen *sws = svga_screen(svga-pipe.screen)-sws;
+
+  variant-gb_shader = sws-shader_create(sws, type,
+  variant-tokens, codeLen);
+  if (!variant-gb_shader)
+ return PIPE_ERROR_OUT_OF_MEMORY;
+
+  return PIPE_OK;
+   }
+   else {
   enum pipe_error ret;
 
   /* Allocate an integer ID for the shader */
@@ -79,6 +89,14 @@ svga_destroy_shader_variant(struct svga_context *svga,
 {
enum pipe_error ret = PIPE_OK;
 
+   if (svga_have_gb_objects(svga)) {
+  struct svga_winsys_screen *sws = svga_screen(svga-pipe.screen)-sws;
+
+  sws-shader_destroy(sws, variant-gb_shader);
+  variant-gb_shader = NULL;
+  goto end;
+   }
+
/* first try */
if (variant-id != UTIL_BITMASK_INVALID_INDEX) {
   ret = SVGA3D_DestroyShader(svga-swc, variant-id, type);
@@ -94,6 +112,7 @@ svga_destroy_shader_variant(struct svga_context *svga,
   util_bitmask_clear(svga-shader_id_bm, variant-id);
}
 
+end:
FREE((unsigned *)variant-tokens);
FREE(variant);
 
diff --git a/src/gallium/drivers/svga/svga_state.h 
b/src/gallium/drivers/svga/svga_state.h
index 7051263..3325626 100644
--- a/src/gallium/drivers/svga/svga_state.h
+++ b/src/gallium/drivers/svga/svga_state.h
@@ -95,4 +95,8 @@ enum pipe_error svga_reemit_framebuffer_bindings( struct 
svga_context *svga );
 
 enum pipe_error svga_reemit_tss_bindings( struct svga_context *svga );
 
+enum pipe_error svga_reemit_vs_bindings(struct svga_context *svga);
+
+enum pipe_error svga_reemit_fs_bindings(struct svga_context *svga);
+
 #endif
diff --git a/src/gallium/drivers/svga/svga_state_fs.c 
b/src/gallium/drivers/svga/svga_state_fs.c
index 7119a19..dde739c 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -321,13 +321,36 @@ make_fs_key(const struct svga_context *svga,
 }
 
 
+/**
+ * svga_reemit_fs_bindings - Reemit the fragment shader bindings
+ */
+enum pipe_error
+svga_reemit_fs_bindings(struct svga_context *svga)
+{
+   enum pipe_error ret;
+
+   assert(svga-rebind.fs);
+   assert(svga_have_gb_objects(svga));
+
+   if (!svga-state.hw_draw.fs)
+  return 

[Mesa-dev] [PATCH 05/19] svga: add svga_have_gb_objects/dma() functions

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_context.h |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index 71d4014..5b04bb4 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -36,8 +36,10 @@
 
 #include tgsi/tgsi_scan.h
 
+#include svga_screen.h
 #include svga_state.h
 #include svga_tgsi.h
+#include svga_winsys.h
 #include svga_hw_reg.h
 #include svga3d_shaderdefs.h
 
@@ -481,5 +483,17 @@ svga_context( struct pipe_context *pipe )
 }
 
 
+static INLINE boolean
+svga_have_gb_objects(const struct svga_context *svga)
+{
+   return svga_screen(svga-pipe.screen)-sws-have_gb_objects;
+}
+
+static INLINE boolean
+svga_have_gb_dma(const struct svga_context *svga)
+{
+   return svga_screen(svga-pipe.screen)-sws-have_gb_dma;
+}
+
 
 #endif
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 08/19] svga: add helpers for tracking rendering to textures

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_resource_texture.c |9 
 src/gallium/drivers/svga/svga_resource_texture.h |   59 ++
 2 files changed, 68 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_resource_texture.c 
b/src/gallium/drivers/svga/svga_resource_texture.c
index 05f56cb..6d5b4c5 100644
--- a/src/gallium/drivers/svga/svga_resource_texture.c
+++ b/src/gallium/drivers/svga/svga_resource_texture.c
@@ -232,6 +232,7 @@ svga_texture_destroy(struct pipe_screen *screen,
 
ss-total_resource_bytes -= tex-size;
 
+   FREE(tex-rendered_to);
FREE(tex);
 }
 
@@ -475,9 +476,15 @@ svga_texture_create(struct pipe_screen *screen,
tex-size = util_resource_size(template);
svgascreen-total_resource_bytes += tex-size;
 
+   tex-rendered_to = CALLOC(template-depth0 * template-array_size,
+ sizeof(tex-rendered_to[0]));
+   if (!tex-rendered_to)
+  goto error2;
+
return tex-b.b;
 
 error2:
+   FREE(tex-rendered_to);
FREE(tex);
 error1:
return NULL;
@@ -536,5 +543,7 @@ svga_texture_from_handle(struct pipe_screen *screen,
tex-key.cachable = 0;
tex-handle = srf;
 
+   tex-rendered_to = CALLOC(1, sizeof(tex-rendered_to[0]));
+
return tex-b.b;
 }
diff --git a/src/gallium/drivers/svga/svga_resource_texture.h 
b/src/gallium/drivers/svga/svga_resource_texture.h
index 7e2e613..0602fa0 100644
--- a/src/gallium/drivers/svga/svga_resource_texture.h
+++ b/src/gallium/drivers/svga/svga_resource_texture.h
@@ -78,6 +78,9 @@ struct svga_texture
struct svga_winsys_surface *handle;
 
unsigned size;  /** Approximate size in bytes */
+
+   /** array indexed by cube face or 3D/array slice, one bit per mipmap level 
*/
+   ushort *rendered_to;
 };
 
 
@@ -143,6 +146,62 @@ svga_define_texture_level(struct svga_texture *tex,
 }
 
 
+static INLINE bool
+svga_is_texture_level_defined(const struct svga_texture *tex,
+  unsigned face, unsigned level)
+{
+   assert(face  Elements(tex-defined));
+   assert(level  Elements(tex-defined[0]));
+   return tex-defined[face][level];
+}
+
+
+/** For debugging, check that face and level are legal */
+static inline void
+check_face_level(const struct svga_texture *tex,
+ unsigned face, unsigned level)
+{
+   if (tex-b.b.target == PIPE_TEXTURE_CUBE) {
+  assert(face  6);
+   }
+   else if (tex-b.b.target == PIPE_TEXTURE_3D) {
+  assert(face  tex-b.b.depth0);
+   }
+   else {
+  assert(face  tex-b.b.array_size);
+   }
+
+   assert(level  8 * sizeof(tex-rendered_to[0]));
+}
+
+
+static INLINE void
+svga_set_texture_rendered_to(struct svga_texture *tex,
+ unsigned face, unsigned level)
+{
+   check_face_level(tex, face, level);
+   tex-rendered_to[face] |= 1  level;
+}
+
+
+static INLINE void
+svga_clear_texture_rendered_to(struct svga_texture *tex,
+   unsigned face, unsigned level)
+{
+   check_face_level(tex, face, level);
+   tex-rendered_to[face] = ~(1  level);
+}
+
+
+static INLINE boolean
+svga_was_texture_rendered_to(const struct svga_texture *tex,
+ unsigned face, unsigned level)
+{
+   check_face_level(tex, face, level);
+   return !!(tex-rendered_to[face]  (1  level));
+}
+
+
 struct pipe_resource *
 svga_texture_create(struct pipe_screen *screen,
 const struct pipe_resource *template);
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 06/19] svga: update constant buffer code for GBS

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_context.c |8 +-
 src/gallium/drivers/svga/svga_context.h |7 +-
 src/gallium/drivers/svga/svga_pipe_constants.c  |6 +-
 src/gallium/drivers/svga/svga_state_constants.c |  215 ---
 src/gallium/drivers/svga/svga_swtnl_draw.c  |8 +-
 5 files changed, 175 insertions(+), 69 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index c32051a..de769ca 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -53,6 +53,7 @@ DEBUG_GET_ONCE_BOOL_OPTION(force_hw_line_stipple, 
SVGA_FORCE_HW_LINE_STIPPLE,
 static void svga_destroy( struct pipe_context *pipe )
 {
struct svga_context *svga = svga_context( pipe );
+   struct svga_winsys_screen *sws = svga_screen(pipe-screen)-sws;
unsigned shader;
 
util_blitter_destroy(svga-blitter);
@@ -70,8 +71,10 @@ static void svga_destroy( struct pipe_context *pipe )
 
util_bitmask_destroy( svga-shader_id_bm );
 
-   for(shader = 0; shader  PIPE_SHADER_TYPES; ++shader)
-  pipe_resource_reference( svga-curr.cb[shader], NULL );
+   for (shader = 0; shader  PIPE_SHADER_TYPES; ++shader) {
+  pipe_resource_reference( svga-curr.cbufs[shader].buffer, NULL );
+  sws-surface_reference(sws, svga-state.hw_draw.hw_cb[shader], NULL);
+   }
 
FREE( svga );
 }
@@ -147,6 +150,7 @@ struct pipe_context *svga_context_create( struct 
pipe_screen *screen,
memset(svga-state.hw_draw, 0xcd, sizeof(svga-state.hw_draw));
memset(svga-state.hw_draw.views, 0x0, sizeof(svga-state.hw_draw.views));
svga-state.hw_draw.num_views = 0;
+   memset(svga-state.hw_draw.hw_cb, 0x0, sizeof(svga-state.hw_draw.hw_cb));
 
svga-dirty = ~0;
 
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index 5b04bb4..71a8eea 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -219,7 +219,7 @@ struct svga_state
 
struct pipe_vertex_buffer vb[PIPE_MAX_ATTRIBS];
struct pipe_index_buffer ib;
-   struct pipe_resource *cb[PIPE_SHADER_TYPES];
+   struct pipe_constant_buffer cbufs[PIPE_SHADER_TYPES];
 
struct pipe_framebuffer_state framebuffer;
float depthscale;
@@ -287,6 +287,11 @@ struct svga_hw_draw_state
unsigned ts[SVGA3D_PIXEL_SAMPLERREG_MAX][SVGA3D_TS_MAX];
float cb[PIPE_SHADER_TYPES][SVGA3D_CONSTREG_MAX][4];
 
+   /**
+* For guest backed shader constants only.
+*/
+   struct svga_winsys_surface *hw_cb[PIPE_SHADER_TYPES];
+
struct svga_shader_variant *fs;
struct svga_shader_variant *vs;
struct svga_hw_view_state views[PIPE_MAX_SAMPLERS];
diff --git a/src/gallium/drivers/svga/svga_pipe_constants.c 
b/src/gallium/drivers/svga/svga_pipe_constants.c
index cfa823b..c32b66d 100644
--- a/src/gallium/drivers/svga/svga_pipe_constants.c
+++ b/src/gallium/drivers/svga/svga_pipe_constants.c
@@ -61,8 +61,10 @@ static void svga_set_constant_buffer(struct pipe_context 
*pipe,
assert(shader  PIPE_SHADER_TYPES);
assert(index == 0);
 
-   pipe_resource_reference( svga-curr.cb[shader],
-  buf );
+   pipe_resource_reference(svga-curr.cbufs[shader].buffer, buf);
+   svga-curr.cbufs[shader].buffer_size = cb ? cb-buffer_size : 0;
+   svga-curr.cbufs[shader].buffer_offset = cb ? cb-buffer_offset : 0;
+   svga-curr.cbufs[shader].user_buffer = NULL; /* not used */
 
if (shader == PIPE_SHADER_FRAGMENT)
   svga-dirty |= SVGA_NEW_FS_CONST_BUFFER;
diff --git a/src/gallium/drivers/svga/svga_state_constants.c 
b/src/gallium/drivers/svga/svga_state_constants.c
index d468298..1e1fbb0 100644
--- a/src/gallium/drivers/svga/svga_state_constants.c
+++ b/src/gallium/drivers/svga/svga_state_constants.c
@@ -24,6 +24,7 @@
  **/
 
 #include util/u_inlines.h
+#include util/u_memory.h
 #include pipe/p_defines.h
 
 #include svga_screen.h
@@ -32,6 +33,7 @@
 #include svga_cmd.h
 #include svga_tgsi.h
 #include svga_debug.h
+#include svga_resource_buffer.h
 
 #include svga_hw_reg.h
 
@@ -41,7 +43,14 @@
  */
 #define MAX_CONST_REG_COUNT 256  /** number of float[4] constants */
 
+/**
+ * Extra space for svga-specific VS/PS constants (such as texcoord
+ * scale factors, vertex transformation scale/translation).
+ */
+#define MAX_EXTRA_CONSTS 32
 
+/** Guest-backed surface constant buffers must be this size */
+#define GB_CONSTBUF_SIZE (SVGA3D_CONSTREG_MAX)
 
 /**
  * Convert from PIPE_SHADER_* to SVGA3D_SHADERTYPE_*
@@ -62,6 +71,81 @@ svga_shader_type(unsigned shader)
 
 
 /**
+ * Emit any extra fragment shader constants into the buffer pointed
+ * to by 'dest'.
+ * In particular, these would be the scaling factors needed for handling
+ * unnormalized texture coordinates for texture rectangles.
+ * \return number of float[4] 

[Mesa-dev] [PATCH 04/19] svga: add new GBS commands

2014-02-13 Thread Brian Paul
And update some existing commands.

Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_cmd.c |  556 ++-
 src/gallium/drivers/svga/svga_cmd.h |   86 ++
 2 files changed, 637 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_cmd.c 
b/src/gallium/drivers/svga/svga_cmd.c
index 6155e85..3bb93c7 100644
--- a/src/gallium/drivers/svga/svga_cmd.c
+++ b/src/gallium/drivers/svga/svga_cmd.c
@@ -45,6 +45,9 @@
  *  Can handle null surface. Does a surface_reallocation so you need
  *  to have allocated the fifo space before converting.
  *
+ *
+ * param flags  mask of SVGA_RELOC_READ / _WRITE
+ *
  * Results:
  *  id is filled out.
  *
@@ -280,7 +283,8 @@ SVGA3D_BeginDefineSurface(struct svga_winsys_context *swc,
if (!cmd)
   return PIPE_ERROR_OUT_OF_MEMORY;
 
-   swc-surface_relocation(swc, cmd-sid, NULL, sid, SVGA_RELOC_WRITE);
+   swc-surface_relocation(swc, cmd-sid, NULL, sid,
+   SVGA_RELOC_WRITE | SVGA_RELOC_INTERNAL);
cmd-surfaceFlags = flags;
cmd-format = format;
 
@@ -365,8 +369,9 @@ SVGA3D_DestroySurface(struct svga_winsys_context *swc,
 SVGA_3D_CMD_SURFACE_DESTROY, sizeof *cmd, 1);
if (!cmd)
   return PIPE_ERROR_OUT_OF_MEMORY;
-
-   swc-surface_relocation(swc, cmd-sid, NULL, sid, SVGA_RELOC_READ);
+   
+   swc-surface_relocation(swc, cmd-sid, NULL, sid,
+   SVGA_RELOC_WRITE | SVGA_RELOC_INTERNAL);
swc-commit(swc);;
 
return PIPE_OK;
@@ -488,6 +493,8 @@ SVGA3D_BufferDMA(struct svga_winsys_context *swc,
SVGA3dCmdSurfaceDMASuffix *pSuffix;
unsigned region_flags;
unsigned surface_flags;
+   
+   assert(!swc-have_gb_objects);
 
if (transfer == SVGA3D_WRITE_HOST_VRAM) {
   region_flags = SVGA_RELOC_READ;
@@ -1352,6 +1359,44 @@ SVGA3D_BeginSetRenderState(struct svga_winsys_context 
*swc,
 /*
  *--
  *
+ * SVGA3D_BeginGBQuery--
+ *
+ *  GB resource version of SVGA3D_BeginQuery.
+ *
+ * Results:
+ *  None.
+ *
+ * Side effects:
+ *  Commits space in the FIFO memory.
+ *
+ *--
+ */
+
+static enum pipe_error
+SVGA3D_BeginGBQuery(struct svga_winsys_context *swc,
+   SVGA3dQueryType type) // IN
+{
+   SVGA3dCmdBeginGBQuery *cmd;
+
+   cmd = SVGA3D_FIFOReserve(swc,
+SVGA_3D_CMD_BEGIN_GB_QUERY,
+sizeof *cmd,
+1);
+   if(!cmd)
+  return PIPE_ERROR_OUT_OF_MEMORY;
+
+   swc-context_relocation(swc, cmd-cid);
+   cmd-type = type;
+
+   swc-commit(swc);
+
+   return PIPE_OK;
+}
+
+
+/*
+ *--
+ *
  * SVGA3D_BeginQuery--
  *
  *  Issues a SVGA_3D_CMD_BEGIN_QUERY command.
@@ -1371,6 +1416,9 @@ SVGA3D_BeginQuery(struct svga_winsys_context *swc,
 {
SVGA3dCmdBeginQuery *cmd;
 
+   if (swc-have_gb_objects)
+  return SVGA3D_BeginGBQuery(swc, type);
+
cmd = SVGA3D_FIFOReserve(swc,
 SVGA_3D_CMD_BEGIN_QUERY,
 sizeof *cmd,
@@ -1390,6 +1438,48 @@ SVGA3D_BeginQuery(struct svga_winsys_context *swc,
 /*
  *--
  *
+ * SVGA3D_EndGBQuery--
+ *
+ *  GB resource version of SVGA3D_EndQuery.
+ *
+ * Results:
+ *  None.
+ *
+ * Side effects:
+ *  Commits space in the FIFO memory.
+ *
+ *--
+ */
+
+static enum pipe_error
+SVGA3D_EndGBQuery(struct svga_winsys_context *swc,
+ SVGA3dQueryType type,  // IN
+ struct svga_winsys_buffer *buffer) // IN/OUT
+{
+   SVGA3dCmdEndGBQuery *cmd;
+
+   cmd = SVGA3D_FIFOReserve(swc,
+SVGA_3D_CMD_END_GB_QUERY,
+sizeof *cmd,
+2);
+   if(!cmd)
+  return PIPE_ERROR_OUT_OF_MEMORY;
+
+   swc-context_relocation(swc, cmd-cid);
+   cmd-type = type;
+
+   swc-mob_relocation(swc, cmd-mobid, cmd-offset, buffer,
+  0, SVGA_RELOC_READ | SVGA_RELOC_WRITE);
+
+   swc-commit(swc);
+   
+   return PIPE_OK;
+}
+
+
+/*
+ *--
+ *
  * SVGA3D_EndQuery--
  *
  *  Issues a SVGA_3D_CMD_END_QUERY command.
@@ -1410,6 +1500,9 @@ SVGA3D_EndQuery(struct svga_winsys_context *swc,
 {
SVGA3dCmdEndQuery *cmd;
 
+   if (swc-have_gb_objects)
+  return SVGA3D_EndGBQuery(swc, type, buffer);
+
cmd = SVGA3D_FIFOReserve(swc,
 SVGA_3D_CMD_END_QUERY,
 sizeof *cmd,
@@ -1421,7 +1514,49 @@ SVGA3D_EndQuery(struct svga_winsys_context *swc,
cmd-type = type;
 

[Mesa-dev] [PATCH 09/19] svga: track which textures are rendered to

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_pipe_misc.c |   39 +
 src/gallium/drivers/svga/svga_surface.c   |   17 +++--
 2 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_pipe_misc.c 
b/src/gallium/drivers/svga/svga_pipe_misc.c
index 2c88e2a..1df32a1 100644
--- a/src/gallium/drivers/svga/svga_pipe_misc.c
+++ b/src/gallium/drivers/svga/svga_pipe_misc.c
@@ -25,11 +25,13 @@
 
 #include svga_cmd.h
 
+#include util/u_framebuffer.h
 #include util/u_inlines.h
 
 #include svga_context.h
 #include svga_screen.h
 #include svga_surface.h
+#include svga_resource_texture.h
 
 
 static void svga_set_scissor_states( struct pipe_context *pipe,
@@ -86,19 +88,25 @@ static void svga_set_framebuffer_state(struct pipe_context 
*pipe,
dst-nr_cbufs = fb-nr_cbufs;
 
/* check if we need to propagate any of the target surfaces */
-   for (i = 0; i  PIPE_MAX_COLOR_BUFS; i++) {
-  if (dst-cbufs[i]  dst-cbufs[i] != fb-cbufs[i])
- if (svga_surface_needs_propagation(dst-cbufs[i]))
+   for (i = 0; i  dst-nr_cbufs; i++) {
+  struct pipe_surface *s = i  fb-nr_cbufs ? fb-cbufs[i] : NULL;
+  if (dst-cbufs[i]  dst-cbufs[i] != s) {
+ if (svga_surface_needs_propagation(dst-cbufs[i])) {
 propagate = TRUE;
+break;
+ }
+  }
}
 
if (propagate) {
   /* make sure that drawing calls comes before propagation calls */
   svga_hwtnl_flush_retry( svga );

-  for (i = 0; i  PIPE_MAX_COLOR_BUFS; i++)
- if (dst-cbufs[i]  dst-cbufs[i] != fb-cbufs[i])
+  for (i = 0; i  dst-nr_cbufs; i++) {
+ struct pipe_surface *s = i  fb-nr_cbufs ? fb-cbufs[i] : NULL;
+ if (dst-cbufs[i]  dst-cbufs[i] != s)
 svga_propagate_surface(svga, dst-cbufs[i]);
+  }
}
 
/* XXX: Actually the virtual hardware may support rendertargets with
@@ -111,12 +119,16 @@ static void svga_set_framebuffer_state(struct 
pipe_context *pipe,
   }
}
 
-   for (i = 0; i  PIPE_MAX_COLOR_BUFS; i++) {
-  pipe_surface_reference(dst-cbufs[i],
- (i  fb-nr_cbufs) ? fb-cbufs[i] : NULL);
-   }
-   pipe_surface_reference(dst-zsbuf, fb-zsbuf);
+   util_copy_framebuffer_state(dst, fb);
 
+   /* Set the rendered-to flags */
+   for (i = 0; i  dst-nr_cbufs; i++) {
+  struct pipe_surface *s = dst-cbufs[i];
+  if (s) {
+ struct svga_texture *t = svga_texture(s-texture);
+ svga_set_texture_rendered_to(t, s-u.tex.first_layer, s-u.tex.level);
+  }
+   }
 
if (svga-curr.framebuffer.zsbuf)
{
@@ -140,6 +152,13 @@ static void svga_set_framebuffer_state(struct pipe_context 
*pipe,
  svga-curr.depthscale = 0.0f;
  break;
   }
+
+  /* Set rendered-to flag */
+  {
+ struct pipe_surface *s = dst-zsbuf;
+ struct svga_texture *t = svga_texture(s-texture);
+ svga_set_texture_rendered_to(t, s-u.tex.first_layer, s-u.tex.level);
+  }
}
else {
   svga-curr.depthscale = 0.0f;
diff --git a/src/gallium/drivers/svga/svga_surface.c 
b/src/gallium/drivers/svga/svga_surface.c
index 5fafadf..c538e36 100644
--- a/src/gallium/drivers/svga/svga_surface.c
+++ b/src/gallium/drivers/svga/svga_surface.c
@@ -158,7 +158,7 @@ svga_texture_view_surface(struct svga_context *svga,
 
for (i = 0; i  key-numMipLevels; i++) {
   for (j = 0; j  key-numFaces; j++) {
- if (tex-defined[j + face_pick][i + start_mip]) {
+ if (svga_is_texture_level_defined(tex, j + face_pick, i + start_mip)) 
{
 unsigned depth = (zslice_pick  0 ?
   u_minify(tex-b.b.depth0, i + start_mip) :
   1);
@@ -304,18 +304,19 @@ svga_mark_surface_dirty(struct pipe_surface *surf)
   if (s-handle == tex-handle) {
  /* hmm so 3d textures always have all their slices marked ? */
  if (surf-texture-target == PIPE_TEXTURE_CUBE)
-tex-defined[surf-u.tex.first_layer][surf-u.tex.level] = TRUE;
+svga_define_texture_level(tex, surf-u.tex.first_layer,
+  surf-u.tex.level);
  else
-tex-defined[0][surf-u.tex.level] = TRUE;
+svga_define_texture_level(tex, 0, surf-u.tex.level);
   }
   else {
  /* this will happen later in svga_propagate_surface */
   }
 
-  /* Increment the view_age and texture age for this surface's slice
-   * so that any sampler views into the texture are re-validated too.
+  /* Increment the view_age and texture age for this surface's mipmap
+   * level so that any sampler views into the texture are re-validated too.
*/
-  svga_age_texture_view(tex, surf-u.tex.first_layer);
+  svga_age_texture_view(tex, surf-u.tex.level);
}
 }
 
@@ -361,7 +362,7 @@ svga_propagate_surface(struct 

[Mesa-dev] [PATCH 14/19] svga: update texture code for GBS

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_resource_texture.c |  388 ++
 src/gallium/drivers/svga/svga_resource_texture.h |2 +
 2 files changed, 326 insertions(+), 64 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_resource_texture.c 
b/src/gallium/drivers/svga/svga_resource_texture.c
index 6d5b4c5..5c601f8 100644
--- a/src/gallium/drivers/svga/svga_resource_texture.c
+++ b/src/gallium/drivers/svga/svga_resource_texture.c
@@ -23,17 +23,19 @@
  *
  **/
 
-#include svga_cmd.h
+#include svga3d_reg.h
+#include svga3d_surfacedefs.h
 
 #include pipe/p_state.h
 #include pipe/p_defines.h
-#include util/u_inlines.h
 #include os/os_thread.h
 #include util/u_format.h
+#include util/u_inlines.h
 #include util/u_math.h
 #include util/u_memory.h
 #include util/u_resource.h
 
+#include svga_cmd.h
 #include svga_format.h
 #include svga_screen.h
 #include svga_context.h
@@ -61,6 +63,8 @@ svga_transfer_dma_band(struct svga_context *svga,
SVGA3dCopyBox box;
enum pipe_error ret;
  
+   assert(!st-use_direct_map);
+
box.x = st-base.box.x;
box.y = y;
box.z = st-base.box.z;
@@ -111,6 +115,8 @@ svga_transfer_dma(struct svga_context *svga,
struct svga_winsys_screen *sws = screen-sws;
struct pipe_fence_handle *fence = NULL;
 
+   assert(!st-use_direct_map);
+
if (transfer == SVGA3D_READ_HOST_VRAM) {
   SVGA_DBG(DEBUG_PERF, %s: readback transfer\n, __FUNCTION__);
}
@@ -237,6 +243,38 @@ svga_texture_destroy(struct pipe_screen *screen,
 }
 
 
+/**
+ * Determine if we need to read back a texture image before mapping it.
+ */
+static boolean
+need_tex_readback(struct pipe_transfer *transfer)
+{
+   struct svga_texture *t = svga_texture(transfer-resource);
+
+   if (transfer-usage  PIPE_TRANSFER_READ)
+  return TRUE;
+
+   if ((transfer-usage  PIPE_TRANSFER_WRITE) 
+   ((transfer-usage  PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE) == 0)) {
+  unsigned face;
+
+  if (transfer-resource-target == PIPE_TEXTURE_CUBE) {
+ assert(transfer-box.depth == 1);
+ face = transfer-box.z;
+  }
+  else {
+ face = 0;
+  }
+  if (svga_was_texture_rendered_to(t, face, transfer-level)) {
+ return TRUE;
+  }
+   }
+
+   return FALSE;
+}
+
+
+
 /* XXX: Still implementing this as if it was a screen function, but
  * can now modify it to queue transfers on the context.
  */
@@ -252,84 +290,254 @@ svga_texture_transfer_map(struct pipe_context *pipe,
struct svga_screen *ss = svga_screen(pipe-screen);
struct svga_winsys_screen *sws = ss-sws;
struct svga_transfer *st;
-   unsigned nblocksx = util_format_get_nblocksx(texture-format, box-width);
-   unsigned nblocksy = util_format_get_nblocksy(texture-format, box-height);
-
-   /* We can't map texture storage directly */
-   if (usage  PIPE_TRANSFER_MAP_DIRECTLY)
-  return NULL;
+   unsigned nblocksx, nblocksy;
+   boolean use_direct_map = svga_have_gb_objects(svga) 
+  !svga_have_gb_dma(svga);
+   unsigned d;
+
+   /* We can't map texture storage directly unless we have GB objects */
+   if (usage  PIPE_TRANSFER_MAP_DIRECTLY) {
+  if (svga_have_gb_objects(svga))
+ use_direct_map = TRUE;
+  else
+ return NULL;
+   }
 
st = CALLOC_STRUCT(svga_transfer);
if (!st)
   return NULL;
 
-   st-base.resource = texture;
+   {
+  unsigned w, h;
+  if (use_direct_map) {
+ /* we'll directly access the guest-backed surface */
+ w = u_minify(texture-width0, level);
+ h = u_minify(texture-height0, level);
+ d = u_minify(texture-depth0, level);
+  }
+  else {
+ /* we'll put the data into a tightly packed buffer */
+ w = box-width;
+ h = box-height;
+ d = box-depth;
+  }
+  nblocksx = util_format_get_nblocksx(texture-format, w);
+  nblocksy = util_format_get_nblocksy(texture-format, h);
+   }
+
+   pipe_resource_reference(st-base.resource, texture);
st-base.level = level;
st-base.usage = usage;
st-base.box = *box;
st-base.stride = nblocksx*util_format_get_blocksize(texture-format);
st-base.layer_stride = st-base.stride * nblocksy;
 
-   st-hw_nblocksy = nblocksy;
+   if (!use_direct_map) {
+  /* Use a DMA buffer */
+  st-hw_nblocksy = nblocksy;
 
-   st-hwbuf = svga_winsys_buffer_create(svga,
- 1, 
- 0,
- st-hw_nblocksy * st-base.stride * 
box-depth);
-   while(!st-hwbuf  (st-hw_nblocksy /= 2)) {
   st-hwbuf = svga_winsys_buffer_create(svga,
 1, 
 0,
-st-hw_nblocksy * st-base.stride 
* box-depth);
-   }
+

[Mesa-dev] [PATCH 11/19] svga: remove a couple unneeded assertions

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_sampler_view.c |1 -
 src/gallium/drivers/svga/svga_screen_cache.c |1 -
 2 files changed, 2 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_sampler_view.c 
b/src/gallium/drivers/svga/svga_sampler_view.c
index 2c846b2..55dc49f 100644
--- a/src/gallium/drivers/svga/svga_sampler_view.c
+++ b/src/gallium/drivers/svga/svga_sampler_view.c
@@ -150,7 +150,6 @@ svga_get_tex_sampler_view(struct pipe_context *pipe,
   sv-key);
 
if (!sv-handle) {
-  assert(0);
   sv-key.cachable = 0;
   sv-handle = tex-handle;
   debug_reference(sv-reference,
diff --git a/src/gallium/drivers/svga/svga_screen_cache.c 
b/src/gallium/drivers/svga/svga_screen_cache.c
index 09f4fe8..71dc72e 100644
--- a/src/gallium/drivers/svga/svga_screen_cache.c
+++ b/src/gallium/drivers/svga/svga_screen_cache.c
@@ -210,7 +210,6 @@ svga_screen_cache_add(struct svga_screen *svgascreen,

assert(key-cachable);
 
-   assert(handle);
if (!handle)
   return;

-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 13/19] svga: update buffer code for GBS

2014-02-13 Thread Brian Paul
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/svga/svga_resource_buffer.c|   32 ++-
 .../drivers/svga/svga_resource_buffer_upload.c |  234 +---
 2 files changed, 224 insertions(+), 42 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_resource_buffer.c 
b/src/gallium/drivers/svga/svga_resource_buffer.c
index 8ba2252..d2c7762 100644
--- a/src/gallium/drivers/svga/svga_resource_buffer.c
+++ b/src/gallium/drivers/svga/svga_resource_buffer.c
@@ -103,9 +103,13 @@ svga_buffer_transfer_map(struct pipe_context *pipe,
 /*
  * Instead of flushing the context command buffer, simply discard
  * the current hwbuf, and start a new one.
+ * With GB objects, the map operation takes care of this
+ * if passed the PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE flag,
+ * and the old backing store is busy.
  */
 
-svga_buffer_destroy_hw_storage(ss, sbuf);
+if (!svga_have_gb_objects(svga))
+   svga_buffer_destroy_hw_storage(ss, sbuf);
  }
 
  sbuf-map.num_ranges = 0;
@@ -132,7 +136,7 @@ svga_buffer_transfer_map(struct pipe_context *pipe,
  if (sbuf-dma.pending) {
 svga_buffer_upload_flush(svga, sbuf);
 
-if (sbuf-hwbuf) {
+if (svga_buffer_has_hw_storage(sbuf)) {
/*
 * We have a pending DMA upload from a hardware buffer, 
therefore
 * we need to ensure that the host finishes processing that DMA
@@ -168,7 +172,7 @@ svga_buffer_transfer_map(struct pipe_context *pipe,
   }
}
 
-   if (!sbuf-swbuf  !sbuf-hwbuf) {
+   if (!sbuf-swbuf  !svga_buffer_has_hw_storage(sbuf)) {
   if (svga_buffer_create_hw_storage(ss, sbuf) != PIPE_OK) {
  /*
   * We can't create a hardware buffer big enough, so create a malloc
@@ -193,11 +197,19 @@ svga_buffer_transfer_map(struct pipe_context *pipe,
   /* User/malloc buffer */
   map = sbuf-swbuf;
}
-   else if (sbuf-hwbuf) {
-  struct svga_screen *ss = svga_screen(pipe-screen);
-  struct svga_winsys_screen *sws = ss-sws;
+   else if (svga_buffer_has_hw_storage(sbuf)) {
+  boolean retry;
 
-  map = sws-buffer_map(sws, sbuf-hwbuf, transfer-usage);
+  map = svga_buffer_hw_storage_map(svga, sbuf, transfer-usage, retry);
+  if (map == NULL  retry) {
+ /*
+  * At this point, svga_buffer_get_transfer() has already
+  * hit the DISCARD_WHOLE_RESOURCE path and flushed HWTNL
+  * for this buffer.
+  */
+ svga_context_flush(svga, NULL);
+ map = svga_buffer_hw_storage_map(svga, sbuf, transfer-usage, retry);
+  }
}
else {
   map = NULL;
@@ -240,7 +252,7 @@ svga_buffer_transfer_unmap( struct pipe_context *pipe,
 struct pipe_transfer *transfer )
 {
struct svga_screen *ss = svga_screen(pipe-screen);
-   struct svga_winsys_screen *sws = ss-sws;
+   struct svga_context *svga = svga_context(pipe);
struct svga_buffer *sbuf = svga_buffer(transfer-resource);

pipe_mutex_lock(ss-swc_mutex);
@@ -250,8 +262,8 @@ svga_buffer_transfer_unmap( struct pipe_context *pipe,
   --sbuf-map.count;
}
 
-   if (sbuf-hwbuf) {
-  sws-buffer_unmap(sws, sbuf-hwbuf);
+   if (svga_buffer_has_hw_storage(sbuf)) {
+  svga_buffer_hw_storage_unmap(svga, sbuf);
}
 
if (transfer-usage  PIPE_TRANSFER_WRITE) {
diff --git a/src/gallium/drivers/svga/svga_resource_buffer_upload.c 
b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
index af39973..3fc14f8 100644
--- a/src/gallium/drivers/svga/svga_resource_buffer_upload.c
+++ b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
@@ -30,6 +30,7 @@
 #include util/u_inlines.h
 #include util/u_math.h
 #include util/u_memory.h
+#include util/u_double_list.h
 
 #include svga_cmd.h
 #include svga_context.h
@@ -39,6 +40,20 @@
 #include svga_screen.h
 #include svga_winsys.h
 
+/**
+ * Describes a complete SVGA_3D_CMD_UPDATE_GB_IMAGE command
+ *
+ */
+struct svga_3d_update_gb_image {
+   SVGA3dCmdHeader header;
+   SVGA3dCmdUpdateGBImage body;
+};
+
+struct svga_3d_invalidate_gb_image {
+   SVGA3dCmdHeader header;
+   SVGA3dCmdInvalidateGBImage body;
+};
+
 
 /**
  * Allocate a winsys_buffer (ie. DMA, aka GMR memory).
@@ -72,6 +87,11 @@ svga_winsys_buffer_create( struct svga_context *svga,
 }
 
 
+/**
+ * Destroy HW storage if separate from the host surface.
+ * In the GB case, the HW storage is associated with the host surface
+ * and is therefore a No-op.
+ */
 void
 svga_buffer_destroy_hw_storage(struct svga_screen *ss, struct svga_buffer 
*sbuf)
 {
@@ -88,7 +108,7 @@ svga_buffer_destroy_hw_storage(struct svga_screen *ss, 
struct svga_buffer *sbuf)
 
 
 /**
- * Allocate DMA'ble storage for the buffer.
+ * Allocate DMA'ble or Updatable storage for the buffer.
  *
  * Called before mapping a 

  1   2   >