Re: [Mesa3d-dev] st/dri: no need to request fake front buffer
On Thu, 2009-12-31 at 13:18 +1000, Ben Skeggs wrote: On Wed, 2009-12-30 at 18:45 +0100, Thomas Hellstrom wrote: Ben, Hey Thomas, Your commit 1336989ec breaks front buffer rendering on Xserver 1.7. Shouldn't the change that silently added a fake front attachment have been accompanied by a bump in SERVER_DRI2_MINOR_VERSION to signal a new capability? Then we could have inserted some conditional code... The way tfp is handled in the xorg state tracker is that when it detects a fake front request on a pixmap it actually hands it the real front, which makes the code work also on older servers. I can't recall the exact details at the moment, but from discussion with a couple of people the xorg state tracker is doing the wrong thing. The client should never get handed the real front buffer in DRI2, all requests for front should hand a fake front back. That's true for windows but not for pixmaps. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Revert st/dri: no need to request fake front buffer, only handle it being returned
On Wed, 2009-12-30 at 20:37 +0100, Thomas Hellstrom wrote: This reverts commit 1336989ec60fff7bd590fefd28945a0e5dc536e3. The commit breaks a) Front buffer rendering on X servers 1.7. b) The possibility to add conditional front buffer requests on older X servers. Since the commit uses a new feature of the DRI protocol, the code must be conditioned on a version bump on the server side. (For example a server side protocol bump to 1.2, and a corresponding client check). Unfortunately, that didn't happen though... So I don't think this can go in as is. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] st/dri: no need to request fake front buffer
Ben Skeggs wrote: On Wed, 2009-12-30 at 18:45 +0100, Thomas Hellstrom wrote: Ben, Hey Thomas, Your commit 1336989ec breaks front buffer rendering on Xserver 1.7. Shouldn't the change that silently added a fake front attachment have been accompanied by a bump in SERVER_DRI2_MINOR_VERSION to signal a new capability? Then we could have inserted some conditional code... The way tfp is handled in the xorg state tracker is that when it detects a fake front request on a pixmap it actually hands it the real front, which makes the code work also on older servers. I can't recall the exact details at the moment, but from discussion with a couple of people the xorg state tracker is doing the wrong thing. The client should never get handed the real front buffer in DRI2, all requests for front should hand a fake front back. If you don't look at it beforehand I'll try and remember to look at it again when I get back into the office on the 4th. The commit in question fixed gallium drivers for Nouveau (and r300 would have been effected too, but I don't have the hardware to test) and EXT_tfp. From the looks of it any DDX that wasn't the xorg state tracker would have been broken. Ben. Could you detail a bit how this broke EXT_tfp, since for tfp it seems the fake front that the dri state-tracker requests is never used? Since the implementation of dri2 seems to vary slightly I think, in the future we should have the xorg state tracker as a reference peer for the dri state tracker, and have that always functioning correctly. /Thomas /Thomas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Revert st/dri: no need to request fake front buffer, only handle it being returned
Michel Dänzer wrote: On Wed, 2009-12-30 at 20:37 +0100, Thomas Hellstrom wrote: This reverts commit 1336989ec60fff7bd590fefd28945a0e5dc536e3. The commit breaks a) Front buffer rendering on X servers 1.7. b) The possibility to add conditional front buffer requests on older X servers. Since the commit uses a new feature of the DRI protocol, the code must be conditioned on a version bump on the server side. (For example a server side protocol bump to 1.2, and a corresponding client check). Unfortunately, that didn't happen though... So I don't think this can go in as is. I strongly think we should revert now, and condition this code on a version bump. If it hasn't happened yet, we should bump now and accept any breakage that happens in-between. We can't just start using new features on other software packages without proper version checking, breaking anything that doesn't have that feature. /Thomas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Gallium API demos and supporting infrastructure
Luca, This is an impressive body of work. I want to give Jose a chance to review the EGL/GLX extensions before pushing, but in the meantime I hope it's ok if I make a couple of quick suggestions/requests: Firstly, we're going to be evolving the TGSI instruction set a fair bit over the coming months to catch up with newer GLSL versions, CL, etc. From that point of view, it would be preferable if the code you've added in uureg.h could be automatically regenerated after TGSI changes. I see you've got some python in the comments showing how you built the file in the first place -- would it be possible to extract that to an actual script that the build system can use to regenerate uureg.h on TGSI changes? I'm mainly thinking about automatically tracking new instructions, I guess. In terms of the gears demo, one of the nice things about gears is that it's as close as possible to the same demo everywhere. How different is this one to the original? Is there a chance of adding a mode that exactly replicates the tessellation of the original gears? As a bonus, it would be nice to see a couple of simpler demos, perhaps something like a port of trivial/tri.c and trivial/clear.c. These are some of the most useful apps for bringing up new drivers and having stripped down pure-gallium versions of them is likely to be a real help for people starting driver projects in the future. It's a bit of a pity you've used a new coding style in these directories. I don't want to be a pain about this and we already have eg. nouveau and other drivers that have gone their own way, but for the most part in Mesa we've tried to stick to the same 3-space layout. Would you be deeply offended if I asked you to reformat to vaguely match the rest of Mesa? I'm not going to make a big deal out of it, but it is a pain to deal with multiple different coding conventions within mesa and I'd prefer it not to get worse... Keith On Thu, 2009-12-31 at 01:37 -0800, Luca Barbieri wrote: This is a series of 4 patches that add the required infrastructure for writing Gallium demos and programs and include two such demos, galliumgears and galliumglobe. The first two patches have already been posted, but I am including them again in git format-patch format as part of the series (they were manually generated). The patches are all attached, and the commit message of the third and fourth is replicated in the message body for easier reading. From 04597af67fb6fa556e04ee5b293ad2b774178cbf Mon Sep 17 00:00:00 2001 From: Luca Barbieri l...@luca-barbieri.com Date: Thu, 31 Dec 2009 09:41:38 +0100 Subject: [PATCH 3/4] Add utility framework for Gallium programs This is an utility library called galliumut, designed to make writing Gallium applications (as opposed to state trackers) easier. It is put in gallium/programs since it doesn't follow the same coding standards and doesn't share the same goal of gallium/auxiliary. It requires my EGL_MESA_gallium extension patch to allow creation of a Gallium context capable of displaying surfaces to the user. For X11 usage, it also requires my MESA_screen_surface patch to make egl_glx automatically create a maximized window for EGL programs. * galliumut.h contains miscellaneous utility functions, easy framebuffer setup functions, mesh (vertex+index buffer) utilities and creation of common state objects * egl_gallium.c uses the MESA_screen_surface and EGL_MESA_gallium to set up a pipe_context and pipe_framebuffer_state suitable for drawing to the screen and implements a render loop * image.c/image.h uses the gdk-pixbuf library to create a pipe_texture from an image in the filesystem * ureg_lib.h adds utility functions, asin/acos, normalize and vector transform functions to ureg * uureg.h is a wrapper around ureg which allows to write much terser shaders. It features, for instance, a short macro for each possible swizzle and writemask, macros that don't include the ureg word, and automatic conversion of ureg_dst and scalars to ureg_src. * math_lib.h is a 3/4-sized vector/matrix library with SSE/SSE2 optimization math_lib_fp.h and math_lib_fp_transform.h are internally used headers * test_math tests math_lib.h * normal_gen.c/normal_gen.h include vertex and fragment shaders for normal map generation From 5a855511dfc524e298696f4356cf56595fc584e1 Mon Sep 17 00:00:00 2001 From: Luca Barbieri l...@luca-barbieri.com Date: Thu, 31 Dec 2009 10:24:09 +0100 Subject: [PATCH 4/4] Add galliumgears and galliumglobe Gallium API demos This patch includes two demos which don't use OpenGL, but directly draw using the Gallium3D API, with context setup done using EGL through the galliumut framework. They require my MESA_screen_surface, EGL_MESA_gallium and galliumut patches This provides a direct demonstration of the Gallium API. In addition to having fun writing Gallium demos, test suites for Gallium drivers can be written in this fashion.
[Mesa3d-dev] Evolving the TGSI instruction set
On 31.12.2009 12:05, Keith Whitwell wrote: Luca, This is an impressive body of work. I want to give Jose a chance to review the EGL/GLX extensions before pushing, but in the meantime I hope it's ok if I make a couple of quick suggestions/requests: Firstly, we're going to be evolving the TGSI instruction set a fair bit over the coming months to catch up with newer GLSL versions, CL, etc. At that point I'd like to ask if, when all the nice memory spaces are introduced to TGSI, these nasty indirect accesses to TEMP will go away. They are really painful to implement because you cannot index registers on nv50+ and thus we'd have to regard TEMP as memory. And since there is no information in the TGSI tokens about what TEMPs constitute an array, we'd have to store and load all of them, which would be quite costly. So I was hoping that, optionally (older cards without actual memory won't like it I suppose), the compiler can just generate the appropriate stores and loads. Thanks in case of replies, Christoph -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Evolving the TGSI instruction set
On Thu, 2009-12-31 at 05:28 -0800, Christoph Bumiller wrote: On 31.12.2009 12:05, Keith Whitwell wrote: Luca, This is an impressive body of work. I want to give Jose a chance to review the EGL/GLX extensions before pushing, but in the meantime I hope it's ok if I make a couple of quick suggestions/requests: Firstly, we're going to be evolving the TGSI instruction set a fair bit over the coming months to catch up with newer GLSL versions, CL, etc. At that point I'd like to ask if, when all the nice memory spaces are introduced to TGSI, these nasty indirect accesses to TEMP will go away. They are really painful to implement because you cannot index registers on nv50+ and thus we'd have to regard TEMP as memory. And since there is no information in the TGSI tokens about what TEMPs constitute an array, we'd have to store and load all of them, which would be quite costly. Yes, I think there will end up being some way in which we mark indexable ranges of temporaries. So I was hoping that, optionally (older cards without actual memory won't like it I suppose), the compiler can just generate the appropriate stores and loads. I'm not sure about that. Can you be more explicit about what you're having trouble with? Keith -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Evolving the TGSI instruction set
On 31.12.2009 15:55, Keith Whitwell wrote: On Thu, 2009-12-31 at 05:28 -0800, Christoph Bumiller wrote: On 31.12.2009 12:05, Keith Whitwell wrote: Luca, This is an impressive body of work. I want to give Jose a chance to review the EGL/GLX extensions before pushing, but in the meantime I hope it's ok if I make a couple of quick suggestions/requests: Firstly, we're going to be evolving the TGSI instruction set a fair bit over the coming months to catch up with newer GLSL versions, CL, etc. At that point I'd like to ask if, when all the nice memory spaces are introduced to TGSI, these nasty indirect accesses to TEMP will go away. They are really painful to implement because you cannot index registers on nv50+ and thus we'd have to regard TEMP as memory. And since there is no information in the TGSI tokens about what TEMPs constitute an array, we'd have to store and load all of them, which would be quite costly. Yes, I think there will end up being some way in which we mark indexable ranges of temporaries. So I was hoping that, optionally (older cards without actual memory won't like it I suppose), the compiler can just generate the appropriate stores and loads. I'm not sure about that. Can you be more explicit about what you're having trouble with? Keith The trouble is mostly that we'd need a proper optimizing compiler to get something performant out of TGSI (I'm still hoping to have time for that nv50+ llvm backend at some point). If addressable ranges of TEMPs are marked, we can just store the whole range to local memory, emit the indirect store or load, and bring them back to registers (maybe on demand), do some flow analysis to get something better etc. It would be doable. I just thought if these loads/stores were generated by the top level compiler itself there might be more potential for optimization and the pipe driver's compiler could be simpler. Thanks, Christoph. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 1/2] Autogenerate uureg opcode macros
Also some missing _src()s and cosmetic changes.
---
src/gallium/programs/galliumut/Makefile|5 +
.../programs/galliumut/gen_uureg_opcodes.sh| 29 +++
src/gallium/programs/galliumut/uureg.h | 196
3 files changed, 71 insertions(+), 159 deletions(-)
create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh
diff --git a/src/gallium/programs/galliumut/Makefile
b/src/gallium/programs/galliumut/Makefile
index ab0d684..4cb9d7c 100644
--- a/src/gallium/programs/galliumut/Makefile
+++ b/src/gallium/programs/galliumut/Makefile
@@ -9,3 +9,8 @@ LIBRARY_DEFINES = --std=gnu99
C_SOURCES = egl_gallium.c image.c normal_gen.c
include ../../Makefile.template
+
+default: uureg_opcodes.h
+
+uureg_opcodes.h: gen_uureg_opcodes.sh
+ bash $^ $@
diff --git a/src/gallium/programs/galliumut/gen_uureg_opcodes.sh
b/src/gallium/programs/galliumut/gen_uureg_opcodes.sh
new file mode 100644
index 000..3a56fcb
--- /dev/null
+++ b/src/gallium/programs/galliumut/gen_uureg_opcodes.sh
@@ -0,0 +1,29 @@
+#!/bin/bash
+cat - EOF
+#ifndef UUREG_OPCODES_H
+#define UUREG_OPCODES_H
+
+/* Autogenerated file, do not edit manually! Use make to regenerate. */
+
+EOF
+
+cat - EOF|cpp -P -E - -I../../auxiliary|sed -re 's/^define /#define _/; s/
CAT /##/g;'
+#define OP00(op) define op() ureg_##op(ureg)
+#define OP01(op) define op(src) ureg_##op(ureg, _src(src))
+#define OP00_LBL(op) define op(label) ureg_##op(ureg, label)
+#define OP01_LBL(op) define op(src, label) ureg_##op(ureg, _src(src), label)
+#define OP10(op) define op(dst) ureg_##op(ureg, dst)
+#define OP11(op) define op(dst, src) ureg_##op(ureg, dst, _src(src))
+#define OP12(op) define op(dst, src0, src1) ureg_##op(ureg, dst, _src(src0),
_src(src1))
+#define OP12_TEX(op) define op(dst, target, src0, src1) ureg_##op(ureg, dst,
TGSI_TEXTURE_ CAT target, _src(src0), _src(src1))
+#define OP13(op) define op(dst, src0, src1, src2) ureg_##op(ureg, dst,
_src(src0), _src(src1), _src(src2))
+#define OP14_TEX(op) define op(dst, target, src0, src1, src2, src3)
ureg_##op(ureg, dst, TGSI_TEXTURE_ CAT target, _src(src0), _src(src1),
_src(src2), _src(src3))
+
+#include tgsi/tgsi_opcode_tmp.h
+EOF
+
+cat - EOF
+
+#endif
+EOF
+
diff --git a/src/gallium/programs/galliumut/uureg.h
b/src/gallium/programs/galliumut/uureg.h
index a2d07a7..d30e188 100644
--- a/src/gallium/programs/galliumut/uureg.h
+++ b/src/gallium/programs/galliumut/uureg.h
@@ -60,7 +60,7 @@ static inline struct ureg_src _src(const struct ureg_src
src) {return src;}
#define _OUTPUT(v, n, i) struct ureg_dst v = ureg_DECL_output(ureg,
TGSI_SEMANTIC_##n, i)
#define _CONST_(v, i) struct ureg_src v = ureg_DECL_constant(ureg, i)
#define _CONST(v, s) UREG_CONST(v, ureg, s)
- #define _CONST_MAT3(v, s) UREG_CONST_MAT3(v, ureg, s)
+#define _CONST_MAT3(v, s) UREG_CONST_MAT3(v, ureg, s)
#define _CONST_MAT4(v, s) UREG_CONST_MAT4(v, ureg, s)
#define _ADDRESS(v) struct ureg_src v = ureg_DECL_address(ureg)
#define _LOOP(v) struct ureg_src v = ureg_DECL_loop(ureg)
@@ -88,6 +88,41 @@ static inline struct ureg_src _src(const struct ureg_src
src) {return src;}
#define _zy(v) _swz(v, Z, Y, Z, Y)
#define _zw(v) _swz(v, Z, W, Z, W)
+#define _ind(r, a) ureg_src_indirect(_src(r), _src(a))
+#define _abs(x) ureg_abs(_src(x))
+#define _neg(x) ureg_negate(_src(x))
+#define _undef ureg_src_undef()
+#define _is_undef(v) ureg_src_is_undef(_src(v))
+
+#define _X(v) ureg_writemask((v), TGSI_WRITEMASK_X)
+#define _Y(v) ureg_writemask((v), TGSI_WRITEMASK_Y)
+#define _Z(v) ureg_writemask((v), TGSI_WRITEMASK_Z)
+#define _W(v) ureg_writemask((v), TGSI_WRITEMASK_W)
+#define _XY(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y)
+#define _XZ(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Z)
+#define _XW(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_W)
+#define _YZ(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_Z)
+#define _YW(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_W)
+#define _ZW(v) ureg_writemask((v), TGSI_WRITEMASK_Z | TGSI_WRITEMASK_W)
+#define _XYZ(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y |
TGSI_WRITEMASK_Z)
+#define _XYW(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y |
TGSI_WRITEMASK_W)
+#define _XZW(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_Z |
TGSI_WRITEMASK_W)
+#define _YZW(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_Z |
TGSI_WRITEMASK_W)
+#define _XYZW(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y |
TGSI_WRITEMASK_Z | TGSI_WRITEMASK_W)
+
+#define _SAT(v) ureg_saturate(v)
+#define _PRED(v, n, x, y, z, w) ureg_predicate(v, n, x, y, z, w)
+#define _IND(r, a) ureg_dst_indirect(r, _src(a))
+#define _UNDEF ureg_dst_undef()
+#define _IS_UNDEF(v) ureg_dst_is_undef(v)
+
+#define _VERT struct ureg_program* ureg = ureg_create(TGSI_PROCESSOR_VERTEX)
+#define _FRAG struct ureg_program* ureg = ureg_create(TGSI_PROCESSOR_FRAGMENT)
+
+#define
[Mesa3d-dev] [PATCH 2/2] Add galliumtri demo
The galliumtri demo is a significantly enhanced Gallium version of tri.
By default it works like the tri, but the triangle size oscillates and the
fragment shader from sge2.txt.
It can also be configured to behave exactly like tri, like clear or it can load
arbitrary vertex, fragment and geometry shaders (totally untested).
---
src/gallium/programs/demos/Makefile|8 +-
src/gallium/programs/demos/galliumtri.c| 250
src/gallium/programs/galliumut/galliumut.h | 65 +++
3 files changed, 320 insertions(+), 3 deletions(-)
create mode 100644 src/gallium/programs/demos/galliumtri.c
diff --git a/src/gallium/programs/demos/Makefile
b/src/gallium/programs/demos/Makefile
index 1623815..e1fba0e 100644
--- a/src/gallium/programs/demos/Makefile
+++ b/src/gallium/programs/demos/Makefile
@@ -2,7 +2,6 @@ TOP = ../../../..
include $(TOP)/configs/current
LIBRARY_INCLUDES = -I../galliumut
-#$(shell pkg-config gdk-pixbuf-2.0 --cflags)
LIBRARY_DEFINES = --std=gnu99
default: programs
@@ -16,9 +15,9 @@ lib.a:
GALLIUM_LIBS = ../galliumut/libgalliumut.a
$(TOP)/src/gallium/auxiliary/util/libutil.a
$(TOP)/src/gallium/auxiliary/tgsi/libtgsi.a
$(TOP)/src/gallium/auxiliary/cso_cache/libcso_cache.a
LIBS = -L$(TOP)/$(LIB_DIR) -lEGL -lGL
-C_SOURCES = galliumgears.c galliumglobe.c galliumsync.c
+C_SOURCES = galliumgears.c galliumglobe.c galliumtri.c
-PROGRAMS = galliumgears galliumglobe
+PROGRAMS = galliumgears galliumglobe galliumtri
programs: $(PROGRAMS)
@@ -27,3 +26,6 @@ galliumgears: galliumgears.o $(HEADERS) $(LIB_DEP)
$(GALLIUM_LIBS)
galliumglobe: galliumglobe.o $(HEADERS) $(LIB_DEP) $(GALLIUM_LIBS)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $ $(LIBS) $(GALLIUM_LIBS) $(shell
pkg-config gdk-pixbuf-2.0 --libs)
+
+galliumtri: galliumtri.o $(HEADERS) $(LIB_DEP) $(GALLIUM_LIBS)
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $ $(LIBS) $(GALLIUM_LIBS)
diff --git a/src/gallium/programs/demos/galliumtri.c
b/src/gallium/programs/demos/galliumtri.c
new file mode 100644
index 000..c85ca4a
--- /dev/null
+++ b/src/gallium/programs/demos/galliumtri.c
@@ -0,0 +1,250 @@
+/*
+ * Copyright (C) 2009 Luca Barbieri 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, sublicense,
+ * 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 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 NONINFRINGEMENT. IN NO EVENT SHALL
+ * LUCA BARBIERI 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.
+ */
+
+#include galliumut.h
+#include math_lib.h
+#include uureg.h
+
+int draw_tri = 1;
+int bypass = 0;
+int gpu = 1;
+float speed = 1.0f;
+float clear_color[4] = {0.3, 0.1, 0.3, 1.0};
+struct mesh* tri;
+const char* vs_file;
+const char* gs_file;
+const char* fs_file;
+int use_sge2_fs = 1;
+
+struct tri_vs
+{
+ vecf scale;
+ vecf translate;
+};
+
+static void* create_tri_vs(struct pipe_context* ctx)
+{
+ _VERT;
+
+ _VS_INPUT(in_coord, 0);
+ _VS_INPUT(in_color, 1);
+ _OUTPUT(out_position, POSITION, 0);
+ _OUTPUT(out_color, COLOR, 0);
+
+ _CONST(scale, struct tri_vs);
+ _CONST(translate, struct tri_vs);
+
+ _MOV(out_color, in_color);
+ _MAD(out_position, in_coord, scale, translate);
+
+ return _END_SHADER(ctx);
+}
+
+static void* create_sge2_fs(struct pipe_context* ctx)
+{
+ _FRAG;
+
+ _FS_INPUT(in_color, COLOR, 0, LINEAR);
+ _OUTPUT(out_color, COLOR, 0);
+
+ _TEMP(r0);
+ _TEMP(r1);
+
+ _SGE(r0, in_color, _yzxw(in_color));
+ _SGE(r1, in_color, _zxyw(in_color));
+ _MUL(r0, r0, r1);
+ _MUL(out_color, r0, in_color);
+
+ return _END_SHADER(ctx);
+}
+
+static struct mesh* build_tri(struct pipe_screen* screen, int gpu, float x,
float y, float w, float h)
+{
+ float* p;
+ struct mesh* mesh = mesh_new(screen, gpu, 2, 3 * sizeof(float), -1, 3,
0, p, 0);
+ mesh-mode = PIPE_PRIM_TRIANGLES;
+ mesh-elem[0].vertex_buffer_index = 0;
+ mesh-elem[0].nr_components = 2;
+ mesh-elem[0].src_format = PIPE_FORMAT_R32G32_FLOAT;
+ mesh-elem[0].src_offset = 0;
+ mesh-elem[1].vertex_buffer_index = 0;
+ mesh-elem[1].nr_components =
Re: [Mesa3d-dev] [PATCH 1/2] Autogenerate uureg opcode macros
On Thu, Dec 31, 2009 at 11:50 AM, Luca Barbieri l...@luca-barbieri.com wrote:
Also some missing _src()s and cosmetic changes.
---
src/gallium/programs/galliumut/Makefile | 5 +
.../programs/galliumut/gen_uureg_opcodes.sh | 29 +++
src/gallium/programs/galliumut/uureg.h | 196
3 files changed, 71 insertions(+), 159 deletions(-)
create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh
diff --git a/src/gallium/programs/galliumut/Makefile
b/src/gallium/programs/galliumut/Makefile
index ab0d684..4cb9d7c 100644
--- a/src/gallium/programs/galliumut/Makefile
+++ b/src/gallium/programs/galliumut/Makefile
@@ -9,3 +9,8 @@ LIBRARY_DEFINES = --std=gnu99
C_SOURCES = egl_gallium.c image.c normal_gen.c
include ../../Makefile.template
+
+default: uureg_opcodes.h
+
+uureg_opcodes.h: gen_uureg_opcodes.sh
+ bash $^ $@
Please just us sh here. There's nothing bash specific about this script.
diff --git a/src/gallium/programs/galliumut/gen_uureg_opcodes.sh
b/src/gallium/programs/galliumut/gen_uureg_opcodes.sh
new file mode 100644
index 000..3a56fcb
--- /dev/null
+++ b/src/gallium/programs/galliumut/gen_uureg_opcodes.sh
@@ -0,0 +1,29 @@
+#!/bin/bash
+cat - EOF
+#ifndef UUREG_OPCODES_H
+#define UUREG_OPCODES_H
+
+/* Autogenerated file, do not edit manually! Use make to regenerate. */
+
+EOF
+
+cat - EOF|cpp -P -E - -I../../auxiliary|sed -re 's/^define /#define _/;
s/ CAT /##/g;'
+#define OP00(op) define op() ureg_##op(ureg)
+#define OP01(op) define op(src) ureg_##op(ureg, _src(src))
+#define OP00_LBL(op) define op(label) ureg_##op(ureg, label)
+#define OP01_LBL(op) define op(src, label) ureg_##op(ureg, _src(src), label)
+#define OP10(op) define op(dst) ureg_##op(ureg, dst)
+#define OP11(op) define op(dst, src) ureg_##op(ureg, dst, _src(src))
+#define OP12(op) define op(dst, src0, src1) ureg_##op(ureg, dst, _src(src0),
_src(src1))
+#define OP12_TEX(op) define op(dst, target, src0, src1) ureg_##op(ureg, dst,
TGSI_TEXTURE_ CAT target, _src(src0), _src(src1))
+#define OP13(op) define op(dst, src0, src1, src2) ureg_##op(ureg, dst,
_src(src0), _src(src1), _src(src2))
+#define OP14_TEX(op) define op(dst, target, src0, src1, src2, src3)
ureg_##op(ureg, dst, TGSI_TEXTURE_ CAT target, _src(src0), _src(src1),
_src(src2), _src(src3))
+
+#include tgsi/tgsi_opcode_tmp.h
+EOF
+
+cat - EOF
+
+#endif
+EOF
+
diff --git a/src/gallium/programs/galliumut/uureg.h
b/src/gallium/programs/galliumut/uureg.h
index a2d07a7..d30e188 100644
--- a/src/gallium/programs/galliumut/uureg.h
+++ b/src/gallium/programs/galliumut/uureg.h
@@ -60,7 +60,7 @@ static inline struct ureg_src _src(const struct ureg_src
src) {return src;}
#define _OUTPUT(v, n, i) struct ureg_dst v = ureg_DECL_output(ureg,
TGSI_SEMANTIC_##n, i)
#define _CONST_(v, i) struct ureg_src v = ureg_DECL_constant(ureg, i)
#define _CONST(v, s) UREG_CONST(v, ureg, s)
- #define _CONST_MAT3(v, s) UREG_CONST_MAT3(v, ureg, s)
+#define _CONST_MAT3(v, s) UREG_CONST_MAT3(v, ureg, s)
#define _CONST_MAT4(v, s) UREG_CONST_MAT4(v, ureg, s)
#define _ADDRESS(v) struct ureg_src v = ureg_DECL_address(ureg)
#define _LOOP(v) struct ureg_src v = ureg_DECL_loop(ureg)
@@ -88,6 +88,41 @@ static inline struct ureg_src _src(const struct ureg_src
src) {return src;}
#define _zy(v) _swz(v, Z, Y, Z, Y)
#define _zw(v) _swz(v, Z, W, Z, W)
+#define _ind(r, a) ureg_src_indirect(_src(r), _src(a))
+#define _abs(x) ureg_abs(_src(x))
+#define _neg(x) ureg_negate(_src(x))
+#define _undef ureg_src_undef()
+#define _is_undef(v) ureg_src_is_undef(_src(v))
+
+#define _X(v) ureg_writemask((v), TGSI_WRITEMASK_X)
+#define _Y(v) ureg_writemask((v), TGSI_WRITEMASK_Y)
+#define _Z(v) ureg_writemask((v), TGSI_WRITEMASK_Z)
+#define _W(v) ureg_writemask((v), TGSI_WRITEMASK_W)
+#define _XY(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y)
+#define _XZ(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Z)
+#define _XW(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_W)
+#define _YZ(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_Z)
+#define _YW(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_W)
+#define _ZW(v) ureg_writemask((v), TGSI_WRITEMASK_Z | TGSI_WRITEMASK_W)
+#define _XYZ(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y |
TGSI_WRITEMASK_Z)
+#define _XYW(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y |
TGSI_WRITEMASK_W)
+#define _XZW(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_Z |
TGSI_WRITEMASK_W)
+#define _YZW(v) ureg_writemask((v), TGSI_WRITEMASK_Y | TGSI_WRITEMASK_Z |
TGSI_WRITEMASK_W)
+#define _XYZW(v) ureg_writemask((v), TGSI_WRITEMASK_X | TGSI_WRITEMASK_Y |
TGSI_WRITEMASK_Z | TGSI_WRITEMASK_W)
+
+#define _SAT(v) ureg_saturate(v)
+#define _PRED(v, n, x, y, z, w) ureg_predicate(v, n, x, y, z, w)
+#define _IND(r, a) ureg_dst_indirect(r,
[Mesa3d-dev] RFC: gallium changes for conditional rendering
Here's my first stab at adding conditional rendering to gallium (and softpipe and the Mesa state tracker). It's pretty simple. There's one new pipe_context function: render_condition(). It specifies the pipe_query object to check before rendering. If the query parameter is NULL it means render normally. This is for implementing GL_NV_conditional_render and the corresponding feature in OpenGL 3.0. Comments? -Brian 0001-gallium-pipe_context-render_condition-and-mode-f.patch Description: Binary data 0002-softpipe-implement-conditional-rendering.patch Description: Binary data 0003-st-mesa-move-st_query_object-type-to-header-to-make.patch Description: Binary data 0004-st-mesa-implement-conditional-rendering.patch Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium changes for conditional rendering
Brian, What's the meaning of the BY_REGION modes added to p_defines.h? I haven't looked at the NV extension too closely, but it's not obvious what these mean... Keith From: Brian Paul [brian.e.p...@gmail.com] Sent: Thursday, December 31, 2009 1:55 PM To: mesa3d-dev Subject: [Mesa3d-dev] RFC: gallium changes for conditional rendering Here's my first stab at adding conditional rendering to gallium (and softpipe and the Mesa state tracker). It's pretty simple. There's one new pipe_context function: render_condition(). It specifies the pipe_query object to check before rendering. If the query parameter is NULL it means render normally. This is for implementing GL_NV_conditional_render and the corresponding feature in OpenGL 3.0. Comments? -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium changes for conditional rendering
How many HW drivers have a conditional render switch? I think all of them, but I'm not sure. At any rate, should be fine for r300. Posting from a mobile, pardon my terseness. ~ C. On Dec 31, 2009 1:57 PM, Brian Paul brian.e.p...@gmail.com wrote: Here's my first stab at adding conditional rendering to gallium (and softpipe and the Mesa state tracker). It's pretty simple. There's one new pipe_context function: render_condition(). It specifies the pipe_query object to check before rendering. If the query parameter is NULL it means render normally. This is for implementing GL_NV_conditional_render and the corresponding feature in OpenGL 3.0. Comments? -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium changes for conditional rendering
The BY_REGION modes indicate that it's OK for the GPU to discard the fragments in the region(s) which failed the occlusion test (perhaps skipping other per-fragment ops that would have otherwise occurred). See the spec at http://www.opengl.org/registry/specs/NV/conditional_render.txt for details. I'd be happy to omit those modes for now. But since they're in the NV spec, I suspect NVIDIA hardware (at least) can make use of them. -Brian On Thu, Dec 31, 2009 at 3:12 PM, Keith Whitwell kei...@vmware.com wrote: Brian, What's the meaning of the BY_REGION modes added to p_defines.h? I haven't looked at the NV extension too closely, but it's not obvious what these mean... Keith From: Brian Paul [brian.e.p...@gmail.com] Sent: Thursday, December 31, 2009 1:55 PM To: mesa3d-dev Subject: [Mesa3d-dev] RFC: gallium changes for conditional rendering Here's my first stab at adding conditional rendering to gallium (and softpipe and the Mesa state tracker). It's pretty simple. There's one new pipe_context function: render_condition(). It specifies the pipe_query object to check before rendering. If the query parameter is NULL it means render normally. This is for implementing GL_NV_conditional_render and the corresponding feature in OpenGL 3.0. Comments? -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
