Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.
On Wed, Feb 22, 2012 at 2:22 PM, Ian Romanick i...@freedesktop.org wrote: 3. Several of the scripts take a really, really long time to run. I'm not eager to add a few minutes to my clean-build times. Someday, when I have time, I'll fix this. Maybe during PyCon. I really regret having been too busy with work to keep hacking Mesa. But yeah, in an ideal world, those scripts really should only take a few seconds, not a few minutes. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: don't clamp or do logical operations on floating-point buffers.
Oh, okay. And we want to do this for Gallium as well, not GL?
If somebody else acks this, I'll merge it, but I am not super-up-to-date on
FP buffer trickery.
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 6:21 AM, Morgan Armand morgan.de...@gmail.com wrote:
Unless I'm missing something, no there is no ROPs defined for floating
points operands.
The ARB_color_buffer_float specification says:
36. Should logical operations be disabled for floating-point color buffers?
RESOLVED: Yes. This matches the behavior in the ATI specification.
Besides that, the result of the blending equation is no longer clamped
when dealing
with FP buffers.
On 11/6/2011 3:08 PM, Corbin Simpson wrote:
It's entirely possible that I'm still asleep, but what problem does this
solve? Are ROPs not defined for FP operands?
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 4:31 AM, Morgan Armand morgan.de...@gmail.com mailto:
morgan.de...@gmail.com wrote:
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 78
++---
1 files changed, 56 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
b/src/gallium/drivers/softpipe/sp_quad_blend.c
index 598df26..4813ada 100644
--- a/src/gallium/drivers/softpipe/sp_quad_blend.c
+++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
@@ -702,19 +702,19 @@ blend_quad(struct quad_stage *qs,
*/
switch (softpipe-blend-rt[blend_index].rgb_func) {
case PIPE_BLEND_ADD:
- VEC4_ADD_SAT(quadColor[0], source[0], blend_dest[0]); /* R */
- VEC4_ADD_SAT(quadColor[1], source[1], blend_dest[1]); /* G */
- VEC4_ADD_SAT(quadColor[2], source[2], blend_dest[2]); /* B */
+ VEC4_ADD(quadColor[0], source[0], blend_dest[0]); /* R */
+ VEC4_ADD(quadColor[1], source[1], blend_dest[1]); /* G */
+ VEC4_ADD(quadColor[2], source[2], blend_dest[2]); /* B */
break;
case PIPE_BLEND_SUBTRACT:
- VEC4_SUB_SAT(quadColor[0], source[0], blend_dest[0]); /* R */
- VEC4_SUB_SAT(quadColor[1], source[1], blend_dest[1]); /* G */
- VEC4_SUB_SAT(quadColor[2], source[2], blend_dest[2]); /* B */
+ VEC4_SUB(quadColor[0], source[0], blend_dest[0]); /* R */
+ VEC4_SUB(quadColor[1], source[1], blend_dest[1]); /* G */
+ VEC4_SUB(quadColor[2], source[2], blend_dest[2]); /* B */
break;
case PIPE_BLEND_REVERSE_SUBTRACT:
- VEC4_SUB_SAT(quadColor[0], blend_dest[0], source[0]); /* R */
- VEC4_SUB_SAT(quadColor[1], blend_dest[1], source[1]); /* G */
- VEC4_SUB_SAT(quadColor[2], blend_dest[2], source[2]); /* B */
+ VEC4_SUB(quadColor[0], blend_dest[0], source[0]); /* R */
+ VEC4_SUB(quadColor[1], blend_dest[1], source[1]); /* G */
+ VEC4_SUB(quadColor[2], blend_dest[2], source[2]); /* B */
break;
case PIPE_BLEND_MIN:
VEC4_MIN(quadColor[0], source[0], blend_dest[0]); /* R */
@@ -735,13 +735,13 @@ blend_quad(struct quad_stage *qs,
*/
switch (softpipe-blend-rt[blend_index].alpha_func) {
case PIPE_BLEND_ADD:
- VEC4_ADD_SAT(quadColor[3], source[3], blend_dest[3]); /* A */
+ VEC4_ADD(quadColor[3], source[3], blend_dest[3]); /* A */
break;
case PIPE_BLEND_SUBTRACT:
- VEC4_SUB_SAT(quadColor[3], source[3], blend_dest[3]); /* A */
+ VEC4_SUB(quadColor[3], source[3], blend_dest[3]); /* A */
break;
case PIPE_BLEND_REVERSE_SUBTRACT:
- VEC4_SUB_SAT(quadColor[3], blend_dest[3], source[3]); /* A */
+ VEC4_SUB(quadColor[3], blend_dest[3], source[3]); /* A */
break;
case PIPE_BLEND_MIN:
VEC4_MIN(quadColor[3], source[3], blend_dest[3]); /* A */
@@ -856,6 +856,10 @@ blend_fallback(struct quad_stage *qs,
for (cbuf = 0; cbuf softpipe-framebuffer.nr_cbufs; cbuf++)
{
+ const enum pipe_format format =
+ softpipe-framebuffer.cbufs[cbuf]-format;
+ const struct util_format_description *desc =
+ util_format_description(format);
/* which blend/mask state index to use: */
const uint blend_buf = blend-independent_blend_enable ? cbuf
: 0;
float dest[4][QUAD_SIZE];
@@ -909,10 +913,19 @@ blend_fallback(struct quad_stage *qs,
if (blend-logicop_enable) {
-logicop_quad( qs, quadColor, dest );
+if (desc-channel[0].type != UTIL_FORMAT_TYPE_FLOAT) {
+ logicop_quad( qs, quadColor, dest );
+}
}
else if (blend-rt[blend_buf].blend_enable) {
blend_quad(qs, quadColor, dest, blend_color, blend_buf
Re: [Mesa-dev] [PATCH 2/2] r300g: Fix queries on big endian hosts.
2011/11/2 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/r300/r300_query.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_query.c
b/src/gallium/drivers/r300/r300_query.c
index 9e784b5..b92410f 100644
--- a/src/gallium/drivers/r300/r300_query.c
+++ b/src/gallium/drivers/r300/r300_query.c
@@ -132,7 +132,7 @@ static boolean r300_get_query_result(struct pipe_context*
pipe,
/* Sum up the results. */
temp = 0;
for (i = 0; i q-num_results; i++) {
- temp += *map;
+ temp += util_le32_to_cpu(*map);
map++;
}
--
1.7.7.1
Nice catch! Only one thing: comment might help future maintainers
understand this. Feel free to push as-is.
I can't test this, as I have no big-endian hardware, but it looks very correct.
Reviewed-by: Corbin Simpson mostawesomed...@gmail.com
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Radeon DRI1 removal
On Thu, Oct 20, 2011 at 9:10 AM, Dave Airlie airl...@gmail.com wrote: So, Radeon maintainers, what do you think? And, does anyone else want to test it on the other drivers? I caught two bugs in my r300 testing (one too many lines cut in one r300 commit, and I had also removed the texsubimage code in an unrelated-to-the-series commit, but it regressed s3tc-texsubimage so I backed it out). I don't see AMD doing any more work on DRI1. The cleanup would be nice, but it would also mean dropping support for *BSD. OTOH, these drivers aren't likely to see any more changes feature-wise so sticking with mesa 7.11 would work. Also, are there are any Linux distros that care about DRI1 anymore? If so, speak now. Also, as Michel said, if we drop DRI1 support, we might as well drop r300c and r600c altogether in favor of the gallium variants. Hell yes, drop r300c and r600c as well. FWIW (which I know isn't a lot these days) I'm also in favor of this; the only thing r300c can do that r300g can't/doesn't is HW fog in the fog block, and that is not something I'm gonna cry about. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Implement NV_fog_distance for Gallium hardware
On Mon, Sep 19, 2011 at 5:48 PM, Nicholas Miell nmi...@gmail.com wrote: The NV_fog_distance extension allows you to specify how the fog distance of a fragment is calculated. The usual method approximates the distance of the fragment from the eye as the absolute value of the distance of the fragment from the eye's Z plane. (Or, rather, the distance of each vertex and then interpolated for each fragment.) NV_fog_distance introduces the eye radial fog distance mode, which calculates the actual distance from the eye to the vertex. Using the actual distance avoids weird peripheral vision artifacts where the rotation of eye causes previously invisible portions of the scene to suddenly fade into visibility in a strange and unnatural fashion. Direct3D 9 calls the eye radial fog distance mode range-based fog and Wine's D3D9 implementation will use NV_fog_distance to implement it. Several other open source game engines in Google Code Search use the eye radial fog mode if it is available. This has been tested with the R600 Gallium driver in Minecraft (with the OptiFine mod). Extensively. I also threw in an untested implementation for NV10 and NV20 GPUs. It looked rather obvious based on the register and constant names and the assumption that since NVIDIA wrote the extesion, their hardware does the right thing. However, I have no way to test this so it is best left unapplied until somebody who can test it does test it. In theory this should be easy to add to the non-Gallium drivers for the i965 and r600 and perhaps more difficult to add to the non-Gallium r300 driver (r300 appears to still implement fog in hardware), but I personally don't care. We're not caring so much about r300c and r600c these days. This all looks good. I can't really ack the Mesa parts, but the logic seems sound enough. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Cleaning up Python scripts
Hi, I've talked about it a bit before, but I feel that it's getting out of hand, so it's time to talk about cleaning up some of the Python that's used to generate/build Mesa. First, the biggest problem is that our Python's completely untested and unstructured. It's very ad-hoc. This might be alright for some of the codegen, but the rather extensive total weight of all of these scripts is over 20 KLOCs, and this is just too much code to be scattered about with very little organization. There are zero Python packages (folders with __init__.py) in Mesa. Here are a handful of problems exposed by pyflakes, a minimal static analysis tool which only catches syntax errors, unused names, and undefined names. This is really only tip-of-the-iceberg stuff, but I don't feel comfortable sending patches for this stuff without talking to the people that wrote this code originally. * /src/gallium/drivers/llvmpipe/lp_tile_shuffle_mask.py has a syntax error in global scope; it can't possibly run. * /scons/wcesdk.py has an undefined name in what appears to be dead code. This probably isn't a problem because I don't think any of us care about WinCE. (Which leads to the question: Why is this in the tree?) * /src/mapi/glapi/gen/*.py have undefined calls to show_usage(), which I anticipate should show a usage message and exit. However, since these are generally only called from Makefiles, they shouldn't be a problem. Of course, people might have trouble running them manually... * /src/mapi/mapi/mapi_abi.py has a couple more undefined names in error paths. What are people's opinions on this? Is it worth spending some time to clean up some of this code? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fixup: Use C++ style constant member functions for is_one and is_zero.
I haven't read the surrounding code, but I'm relatively sure this
patch covers whether or not the given register can be filled with a
constant zero or one, which would be represented in the shader as a
special swizzle or selector. In that case, you'd only want to match
exact 0.0 and 1.0, but that's okay, because both 0.0 and 1.0 are
relatively common constants.
~ C.
On Sun, Sep 11, 2011 at 4:05 AM, Tolga Dalman
tolga.dal...@googlemail.com wrote:
Hi Kenneth,
On Fri, 9 Sep 2011 14:41:45 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
- if (reg-type == BRW_REGISTER_TYPE_F) {
- return reg-imm.f == 0.0;
+ if (type == BRW_REGISTER_TYPE_F) {
+ return imm.f == 0.0;
[...]
- if (reg-type == BRW_REGISTER_TYPE_F) {
- return reg-imm.f == 1.0;
+ if (type == BRW_REGISTER_TYPE_F) {
+ return imm.f == 1.0;
Shouldn't this rather be something like
fabs(imm.f - 1.0) std::numeric_limitsfloat::eps() ?
Nevertheless, I like your patch.
Best regards
Tolga Dalman
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/9] r300: Enable extensions by just setting the flags
) -- 1.7.4.4 FWIW, Reviewed-by: Corbin Simpson mostawesomed...@gmail.com Thanks for this! I'm so happy! ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL to DirectX with Mesa3D
Use ANGLE. It's there, it works well enough that Fx and Chromium are both using it, and it'll do what you want. ...I kinda wish you didn't need it, but sadly, OGL on Win32 sucks a lot. ~ C. On Fri, Aug 26, 2011 at 10:13 AM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2011 10:55 AM, Anonimo Veneziano wrote: Hi all I am a programmer but not very skilled in 3D graphics (so pardon me if I write something wrong). I need to build my own opengl32.dll to redirect my OpenGL application calls to DirectX (better if 10 or 11, but 9 could be ok too) TitaniumGL and 3DAnalyzer dont work for my case (already tested, application crashes). 1. Do you know if some other OpenGL-DirectX converter exist that I could use? I am trying to use Mesa3D v7.10.3, and in particular I found GLDirect very interesting, but I am not able to get it compiled with dx9. I see it has been changed since GLDirect 5.0.2 old released version (that is of no use for me, it's opengl 1.1). So in Mesa v7.10.3 I tried to compile GLDirect and fixed some errors but at the moment I had some errors I cannot fix compiling gld_primitive_dx9.c and gld_texture_dx9.c: for example in the first file the structures SWvertex (from swrast.h) and gl_context (from mtypes.h) seems different from those defined in Mesa, 2. Did someone compile GLDirect in Mesa 7.10.3? Can you help me to do it? 3. Could Gallium help me in some way? I am not sure to have understood well it... Many thanks in advance and sorry to have bothered you but I am in a hurry on a project and hope to get some solution! The GLDirect stuff is really, really dead. It hasn't been maintained in years, and it probably hasn't been able to compile in just about as long. Moreover, as per discussions in another thread (http://marc.info/?l=mesa3d-devm=131421311903781w=2), this code is literally minutes from being deleted. Since the internal Gallium interface is essentially a clone of the DX10 interface, it should be trivial to make a Gallium DX10 driver. Note that this is different from a DX10 state tracker (this is the top-half layer that makes a particular API available to applications). One of the Gallium guys should know more... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk5X1FIACgkQX1gOwKyEAw9CkwCbB5kmJPe56nolsuQFDwVV2YNX uiAAnR2HrythvfujHT1cSiVstanQICRD =TKdd -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEATH to old drivers!
+1. If anybody needs them, they're in git. Sending from a mobile, pardon my terseness. ~ C. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEATH to old drivers!
On Wed, Aug 24, 2011 at 3:14 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Aug 24, 2011 at 01:50:25PM -0700, Corbin Simpson wrote: +1. If anybody needs them, they're in git. Sending from a mobile, pardon my terseness. ~ C. *sigh* Software populism... But seriously. How would such a thing work? Drivers will be thrown out because none of those currently chiming care about doing the extra bit of work needed to maintain at least some highly standard interfaces. It seems that these less popular drivers are gone for good. Because what would one have to do to get them back in? What are the criteria for that? And how will such criteria evolve? Because stating you don't have features that some cards already implemented 12 years ago is a pretty shaky path to venture out on. What's next? because i do not like the people who develop?* Now that would be very free and open indeed. The way the mesa monolith exists today, also leaves nothing to the imagination. Once a driver is dropped there is also no way of maintaining it externally. To further that: an attempt at proposing some rudimentary SDK, which would shift the compatibility burden to the driver developers (to some extent, this SDK will also not be allowed to move as shortsightedly as before -- which in itself does not exclude evolution at all), wasn't exactly hailed positively. Such infrastructure would've made such brash development possible. Ian's list of DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx, and unichrome. I have mga, r128, savage, sis, tdfx hardware, but not the time to maintain it, let alone get it into DRI2-land, at this time. If I suddenly get the time to do it, I'll gladly bring them back up to speed, but as it stands, they've been getting cargo-cult interface updates without any testing, and at some point it's actively harmful to keep shipping them without testing, isn't it? -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEATH to old drivers!
On Wed, Aug 24, 2011 at 3:37 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Aug 24, 2011 at 03:28:14PM -0700, Corbin Simpson wrote: Ian's list of DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx, and unichrome. I have mga, r128, savage, sis, tdfx hardware, but not the time to maintain it, let alone get it into DRI2-land, at this time. If I suddenly get the time to do it, I'll gladly bring them back up to speed, but as it stands, they've been getting cargo-cult interface updates without any testing, and at some point it's actively harmful to keep shipping them without testing, isn't it? Weren't you taking some time off from development? If so, why chime in on such a topic, and then especially use your own lack of time as an argument? That sounds pretty broken. You're entirely right. My current full-time employer doesn't pay me to work on Mesa, and I only am involved in Mesa development to the extent required to support my GSoC student. I'm retracting my opinion on whether these drivers should be removed from the tree. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r300/compiler: Implement ROUND
Sending from a mobile, pardon my terseness. ~ C.
On Aug 23, 2011 2:42 PM, Tom Stellard tstel...@gmail.com wrote:
According to the GLSL spec, the implementor can decide which way to round
when the fraction is .5. The r300 compiler will round down, so we can use
CND and save an instruction.
---
MLAA should work on r300g (r500 only) with this patch. I've tested
with the kasanen-post-process-v2 branch and it looks OK to me, but it
would be nice to have a second opinion.
I was testing with: pp_jimenezmlaa=8 glxgears
src/gallium/drivers/r300/compiler/radeon_opcodes.c | 7 +++
src/gallium/drivers/r300/compiler/radeon_opcodes.h | 3 +
.../drivers/r300/compiler/radeon_program_alu.c | 54
src/gallium/drivers/r300/r300_tgsi_to_rc.c | 2 +-
4 files changed, 65 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r300/compiler/radeon_opcodes.c
b/src/gallium/drivers/r300/compiler/radeon_opcodes.c
index afd78ad..527db9a 100644
--- a/src/gallium/drivers/r300/compiler/radeon_opcodes.c
+++ b/src/gallium/drivers/r300/compiler/radeon_opcodes.c
@@ -246,6 +246,13 @@ struct rc_opcode_info rc_opcodes[MAX_RC_OPCODE] = {
.IsStandardScalar = 1
},
{
+ .Opcode = RC_OPCODE_ROUND,
+ .Name = ROUND,
+ .NumSrcRegs = 1,
+ .HasDstReg = 1,
+ .IsComponentwise = 1
+ },
+ {
.Opcode = RC_OPCODE_RSQ,
.Name = RSQ,
.NumSrcRegs = 1,
diff --git a/src/gallium/drivers/r300/compiler/radeon_opcodes.h
b/src/gallium/drivers/r300/compiler/radeon_opcodes.h
index b586882..968dc7b 100644
--- a/src/gallium/drivers/r300/compiler/radeon_opcodes.h
+++ b/src/gallium/drivers/r300/compiler/radeon_opcodes.h
@@ -133,6 +133,9 @@ typedef enum {
/** scalar instruction: dst = 1 / src0.x */
RC_OPCODE_RCP,
+ /** vec4 instruction: dst.c = frc(src0.c) 0.5 ? ceil(src0.c) :
floor(src0.c) */
+ RC_OPCODE_ROUND,
+
/** scalar instruction: dst = 1 / sqrt(src0.x) */
RC_OPCODE_RSQ,
diff --git a/src/gallium/drivers/r300/compiler/radeon_program_alu.c
b/src/gallium/drivers/r300/compiler/radeon_program_alu.c
index e273bc4..0bfd2dc 100644
--- a/src/gallium/drivers/r300/compiler/radeon_program_alu.c
+++ b/src/gallium/drivers/r300/compiler/radeon_program_alu.c
@@ -104,6 +104,13 @@ static const struct rc_src_register builtin_one = {
.Index = 0,
.Swizzle = RC_SWIZZLE_
};
+
+static const struct rc_src_register builtin_half = {
+ .File = RC_FILE_NONE,
+ .Index = 0,
+ .Swizzle = RC_SWIZZLE_
+};
+
static const struct rc_src_register srcreg_undefined = {
.File = RC_FILE_NONE,
.Index = 0,
@@ -416,6 +423,52 @@ static void transform_POW(struct radeon_compiler* c,
rc_remove_instruction(inst);
}
+/* dst = ROUND(src) :
+ * frac = FRC(src)
+ * low = src - frac
+ * high = low + 1
+ * dst = CND high, low, frac
+ *
+ * According to the GLSL spec, the implementor can decide which way to
round
+ * when the fraction is .5. In this case we round down, so we can use
+ * CND and save an instruction.
+ *
+ * The optimizer should reduce this sequence to 3 instructions using
+ * presubtract.
+ */
+static void transform_ROUND(struct radeon_compiler* c,
+ struct rc_instruction* inst)
+{
+ unsigned int mask = inst-U.I.DstReg.WriteMask;
+ unsigned int frac_index, low_index, high_index;
+ struct rc_dst_register frac_dst, low_dst, high_dst;
+ struct rc_src_register frac_src, low_src, high_src;
+
+ /* frac = FRC(src) */
+ frac_index = rc_find_free_temporary(c);
+ frac_dst = dstregtmpmask(frac_index, mask);
+ emit1(c, inst-Prev, RC_OPCODE_FRC, 0, frac_dst, inst-U.I.SrcReg[0]);
+ frac_src = srcreg(RC_FILE_TEMPORARY, frac_dst.Index);
+
+ /* low = src - frc */
+ low_index = rc_find_free_temporary(c);
+ low_dst = dstregtmpmask(low_index, mask);
+ emit2(c, inst-Prev, RC_OPCODE_ADD, 0, low_dst,
+ negate(inst-U.I.SrcReg[0]), frac_src);
+ low_src = srcreg(RC_FILE_TEMPORARY, low_dst.Index);
+
+ /* high = low + 1 */
+ high_index = rc_find_free_temporary(c);
+ high_dst = dstregtmpmask(high_index, mask);
+ emit2(c, inst-Prev, RC_OPCODE_ADD, 0, high_dst, low_src, builtin_one);
+ high_src = srcreg(RC_FILE_TEMPORARY, high_dst.Index);
+
+ /* dst = CND high, low, frac */
+ emit3(c, inst-Prev, RC_OPCODE_CND, 0, inst-U.I.DstReg,
+ high_src, low_src, frac_src);
+ rc_remove_instruction(inst);
+}
+
static void transform_RSQ(struct radeon_compiler* c,
struct rc_instruction* inst)
{
@@ -599,6 +652,7 @@ int radeonTransformALU(
case RC_OPCODE_LIT: transform_LIT(c, inst); return 1;
case RC_OPCODE_LRP: transform_LRP(c, inst); return 1;
case RC_OPCODE_POW: transform_POW(c, inst); return 1;
+ case RC_OPCODE_ROUND: transform_ROUND(c, inst); return 1;
case RC_OPCODE_RSQ: transform_RSQ(c, inst); return 1;
case RC_OPCODE_SEQ: transform_SEQ(c, inst); return 1;
case RC_OPCODE_SFL: transform_SFL(c, inst); return 1;
diff --git a/src/gallium/drivers/r300/r300_tgsi_to_rc.c
b/src/gallium/drivers/r300/r300_tgsi_to_rc.c
index 07a3f3c..4cb08b5 100644
--- a/src/gallium/drivers/r300/r300_tgsi_to_rc.c
+++
Re: [Mesa-dev] [PATCH] r300/compiler: Implement ROUND
Have not tested this, but it looks good. I'll apply after testing if Marek doesn't get there first. Thanks! Sending from a mobile, pardon my terseness. ~ C. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/11] Post-processing infrastructure / gsoc work
On Wed, Aug 17, 2011 at 9:56 AM, Lauri Kasanen c...@gmx.com wrote: My understanding is that Mesa is c99 (with such includes for some systems included in the tree). Are there really c99 compilers that would choke on that? Sadly, no. We do C89 in the non-compiler-specific areas of Gallium. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
I should point out something not immediately obvious about S3TC: It's believed that the patents cover any complete pipeline which decompresses S3TC textures according to the S3TC algorithm. It's stupidly broad that way. On Tue, Aug 9, 2011 at 8:12 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 08/09/11 02:29, Rudolf Polzer wrote: Is US patent law really that retarded? US patent law shares a common feature with most other patent systems: No matter how carefully you word the patent or read the patent, the only way to really find out whether something is a patent violation is to go to court and see if a judge or jury, all made up of non-engineers who don't understand the details, decide you're guilty of patent infringement. All attempts to apply carefully reasoned logic to patents fail when they hit this one illogical and unpredictable step, with potentially expensive results. The US patent system has a bonus feature though - if you knew about that patent in advance, then they can triple the amount of money you lose in the lawsuit, which is why most companies advise their engineers to avoid knowing anything about another companies patents, much less how to engineer around them. Sadly, the much needed patent reform doesn't seem to be coming, while the patent trolls and lawsuits keep rising. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 6:12 AM, Rudolf Polzer divver...@xonotic.org wrote: On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ 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] S2TC - yet another attempt to solve the S3TC issue
It is not transparent if applications must opt into using it. Please go ask distributions to pick this up; we aren't going to do it without the legal issues being cleared up. Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 6:12 AM, Rudolf Polzer divver...@xonotic.org wrote: On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ 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] S2TC - yet another attempt to solve the S3TC issue
Unless I missed something, we (the Mesa developers) do not endorse using S3TC at all, anywhere in the stack, as long as it is patented. Have you actually talked to any distros? This is my last post; we aren't getting anywhere. Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 1:02 PM, Rudolf Polzer divver...@xonotic.org wrote: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
The classic nouveau driver supports nv04, nv1x, nv2x IIRC. I'm definitely not the right person for the job, but I'll look at it if nobody else can. ~ C. On Mon, Jul 18, 2011 at 7:09 AM, Brian Paul bri...@vmware.com wrote: On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paulbri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging glsl-to-tgsi to master
I'd like to see it merged eventually for my GSoC student's work, which will probably depend on it, but waiting until August will probably be alright. ~ C. On Wed, Jul 13, 2011 at 1:00 AM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2011 09:53 AM, Egon Ashrafinia wrote: Hello guys. 1 month ago, we talked about merging glsl-to-tgsi to master but it still not happend. What about now? I could compile and test it a bit. It works. Anyone who could do it? What does Bryan Cain say about it? One thing to consider is whether or not this will make it more difficult to cherry pick fixes to the 7.11 release branch. Bryan has been doing some really cool work, and I'd like to see it get merged. However, I also want 7.11 to ship on time and with as few bugs as possible. Anything that will make that more difficult should wait until August. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cfcIACgkQX1gOwKyEAw9/+QCffZMyD45ChgwvAm5B2NJPE+G3 9aEAnA4eC8eipdDJ2vGJMVFRHfSg6X5v =zdUh -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mga: enable GL_ARB_vertex_array_object extension
I have the HW as well, but I see no reason this wouldn't work. Sending from a mobile, pardon the brevity. ~ C. On Jun 7, 2011 3:36 PM, Brian Paul brian.e.p...@gmail.com wrote: On Tue, Jun 7, 2011 at 3:56 PM, Nicolas Kaiser ni...@nikai.net wrote: Tested on a Matrox G550 AGP. I noticed that the two piglit VAO tests as well as the vao_demo only test APPLE_vertex_array_object, which is already enabled on mga. Signed-off-by: Brian Paul bri...@vmware.com You might very well be the only mga user/tester! -Brian ___ 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] [PATCH 0/6] Per driver pci id lists
On Mon, Jun 6, 2011 at 9:33 AM, Benjamin Franzke benjaminfran...@googlemail.com wrote: Well radeon_drm_public.h declares radeon_drm_winsys_create(), but yea is_r3xx should be replaced. Patch attached. I remember writing is_r3xx() way back when and feeling like it was a horrible horrible hack. This is a great idea for a replacement. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Design of the post-processing queue
On Mon, May 2, 2011 at 4:01 AM, Lauri Kasanen c...@gmx.com wrote: Hi everyone I'm the student working on integrating MLAA for this summer. I'm mostly on irc, but to get wider feedback on this, posting to the list. What are your opinions on the post-prosessing queue? I thought of two ways: 1) It's expected to be simple enough, in that there's only one sane order (MLAA should near always be the last filter, etc). Simpler configuration, one config option per filter. One filter may only be used once. 2) It's expected to be complex enough that the user needs to specify order as well (see mplayer's pp queue for this type). One config option, more complex than above. One filter may be used as many times as desired. Right now I can't think of anything requiring 2), how do you guys feel? - Lauri [ shameless ad: candgsoc.host56.com ] I think that perhaps a good question to consider would be: What other filters might go into the PP queue? Is there anything besides anti-aliasing and color correction? (I'm trying to get a discussion started...) ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libxml2 (python) dependency
On Mon, Apr 18, 2011 at 4:48 PM, tom fogal tfo...@sci.utah.edu wrote: Hey all, We recently became more aware of a dependency on python's libxml2 for building Mesa. We're not as proactive as we should be, but tend to upgrade Mesa every few releases; I think this was a jump from 7.8 to 7.10. Anyway, libxml2 is a bit arduous for us because it's not installed by default on Linux or Mac. On Linux, it's easy to grab via a package manager, but still does not exist by default on some distros. In general, non-standard dependencies are difficult because they make our (already very large) software stack more complex. Is the package truly needed? I think it's used to parse spec files and autogenerate trampolines or callbacks or something like that. Didn't we used to have plain text files for that? Any reason we can't go back to something simpler? Does code speak loud than words, here? :) Python comes with three or four different XML parsers, and of those, etree is both relatively speedy and sane. Certainly easier to handle than libxml2 directly. If people want it to be even speedier, there's a libxml2 library for Python, lxml, which has the etree API and is quite nice. This has been on my TODO list for a year or so, but no real useful work has been made. Knowing that people actually care about it gives me some incentive, but I can't promise anything. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Big pile of fog clean up
Acked-by: Corbin Simpson mostawesomed...@gmail.com Sending from a mobile, pardon the brevity. ~ C. On Apr 19, 2011 4:13 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2011 09:45 AM, Corbin Simpson wrote: On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick i...@freedesktop.org wrote: This patch series cleans out the last vestiges of fixed-function fog support with ARB_fragment_program. We talked about doing this quite some time ago, but we decided to hold off. The thinking at the time was that there was still a chance that someone might add support for the fixed-function fog on either i915 or r300. Reality check: there is no chance because nobody cares. :) Patch 1/9 cleans up a couple minor bugs in the fixed-function fragment program code. Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to be non-GL_NONE. Thanks to the first patch, this can *never* happen. Patch 5/9 removes gl_fragment_program::FogOption. The remaining four patches remove all the dangling bits of support for fixed-function fog on i915. Since fog is (and always has been) handled by fragment programs on i915, this code is completely useless. I have tested this whole series on Ironlake (i965 driver) and G33 (i915 driver). There were no piglit or GTF regressions in either case. I believe that, at the very least, the first four patches are suitable for the stable branches (after a suitable settling period on master, of course). The remaining five patches may also be suitable. src/mesa/drivers/dri/i915/i915_context.c | 8 +- src/mesa/drivers/dri/i915/i915_context.h | 15 -- src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +-- src/mesa/drivers/dri/i915/i915_state.c | 164 +--- src/mesa/drivers/dri/i915/i915_vtbl.c | 9 - src/mesa/drivers/dri/i965/brw_program.c | 5 - .../drivers/dri/r300/compiler/r300_fragprog_emit.c | 2 - src/mesa/main/ff_fragment_shader.cpp | 44 +++--- src/mesa/main/mtypes.h | 1 - src/mesa/program/arbprogparse.c | 18 +-- src/mesa/program/program.c | 1 - src/mesa/program/programopt.c | 33 +++-- src/mesa/program/programopt.h | 4 +- src/mesa/swrast/s_context.c | 15 +-- src/mesa/tnl/t_context.c | 12 +- 15 files changed, 70 insertions(+), 272 deletions(-) r300 *did* support FF fog at one point, but it got tossed out because we couldn't get it to work with fog coordinates. (Well, *I* couldn't get it to work; I think osiris got it mostly-working-sort-of at one point.) This code will not be missed. Right. I believe people eventually figured out that fglrx didn't use the fixed-function fog either. It seems likely that it was for the same reason. :) Looking at the i915 docs, there a bunch of restrictions and weird quirks that look like they'd make it more trouble that it's worth. Plus, I don't think a lot of applications use part shader / part fixed-function anyway. Can I call this an Acked-by? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2uFxIACgkQX1gOwKyEAw9zuACfWUW9RLRqeauVKPK103E//BNb /swAnixkaFG6jKh0FrgPk3hoi6wFu+uY =p6R3 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How do I get start about gallium?
When you write a Gallium driver, it can be used by any frontend, including GL, VG, GLES, etc. The only real hardware requirement is that the hardware is *shaderful*; it needs to support vertex and fragment shaders. Sending from a mobile, pardon the brevity. ~ C. On Apr 18, 2011 7:11 AM, Awin awin0...@gmail.com wrote: 於 2011/4/11 下午 11:23, Corbin Simpson 提到: On Fri, Apr 8, 2011 at 4:17 AM, Awinawin0...@gmail.com wrote: Hi all, I need to write a OpenGL driver for my company's IC, and base on gallium, how do I get start? Is there any document or sample code to reference? This is a remarkably candid question. In the Mesa tree, the Gallium headers (src/gallium/include/**/*.h) describe the objects Gallium passes around. There are also Sphinx docs (src/gallium/docs/) which probably haven't really been maintained in a bit, but it's nice to think that they are somewhat accurate. Gallium is laid out like this: There is a struct called Winsys which handles talking to your hardware backend (DRM, Windows kernel, etc.), a struct called Screen which helps to manage your GPU's information and resources, and a struct called Context which is, well, a rendering context. Which SoC is this? Do you have docs? Are you going to open-source any of your driver code? It's going to be a lot easier to answer your questions in realtime; there's an IRC channel on Freenode, #dri-devel, which is the general Gallium channel (among other things), and is a great place to ask questions. Hope this helps somewhat, ~ C. Thanks for your reply, The SoC is still on design, that's a DTV chip with OpenVG engine, and some functions of OpenGL ES, that the reason I want to use gallium, I just need to implement driver interface(which can accelerate by HW) for OpenVG and OpenGL ES state tracker, and others use softpipe to draw. So I can use full function of SoC on VG or GL ES, am I right? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Big pile of fog clean up
On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick i...@freedesktop.org wrote: This patch series cleans out the last vestiges of fixed-function fog support with ARB_fragment_program. We talked about doing this quite some time ago, but we decided to hold off. The thinking at the time was that there was still a chance that someone might add support for the fixed-function fog on either i915 or r300. Reality check: there is no chance because nobody cares. :) Patch 1/9 cleans up a couple minor bugs in the fixed-function fragment program code. Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to be non-GL_NONE. Thanks to the first patch, this can *never* happen. Patch 5/9 removes gl_fragment_program::FogOption. The remaining four patches remove all the dangling bits of support for fixed-function fog on i915. Since fog is (and always has been) handled by fragment programs on i915, this code is completely useless. I have tested this whole series on Ironlake (i965 driver) and G33 (i915 driver). There were no piglit or GTF regressions in either case. I believe that, at the very least, the first four patches are suitable for the stable branches (after a suitable settling period on master, of course). The remaining five patches may also be suitable. src/mesa/drivers/dri/i915/i915_context.c | 8 +- src/mesa/drivers/dri/i915/i915_context.h | 15 -- src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +-- src/mesa/drivers/dri/i915/i915_state.c | 164 +--- src/mesa/drivers/dri/i915/i915_vtbl.c | 9 - src/mesa/drivers/dri/i965/brw_program.c | 5 - .../drivers/dri/r300/compiler/r300_fragprog_emit.c | 2 - src/mesa/main/ff_fragment_shader.cpp | 44 +++--- src/mesa/main/mtypes.h | 1 - src/mesa/program/arbprogparse.c | 18 +-- src/mesa/program/program.c | 1 - src/mesa/program/programopt.c | 33 +++-- src/mesa/program/programopt.h | 4 +- src/mesa/swrast/s_context.c | 15 +-- src/mesa/tnl/t_context.c | 12 +- 15 files changed, 70 insertions(+), 272 deletions(-) r300 *did* support FF fog at one point, but it got tossed out because we couldn't get it to work with fog coordinates. (Well, *I* couldn't get it to work; I think osiris got it mostly-working-sort-of at one point.) This code will not be missed. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How do I get start about gallium?
On Fri, Apr 8, 2011 at 4:17 AM, Awin awin0...@gmail.com wrote: Hi all, I need to write a OpenGL driver for my company's IC, and base on gallium, how do I get start? Is there any document or sample code to reference? This is a remarkably candid question. In the Mesa tree, the Gallium headers (src/gallium/include/**/*.h) describe the objects Gallium passes around. There are also Sphinx docs (src/gallium/docs/) which probably haven't really been maintained in a bit, but it's nice to think that they are somewhat accurate. Gallium is laid out like this: There is a struct called Winsys which handles talking to your hardware backend (DRM, Windows kernel, etc.), a struct called Screen which helps to manage your GPU's information and resources, and a struct called Context which is, well, a rendering context. Which SoC is this? Do you have docs? Are you going to open-source any of your driver code? It's going to be a lot easier to answer your questions in realtime; there's an IRC channel on Freenode, #dri-devel, which is the general Gallium channel (among other things), and is a great place to ask questions. Hope this helps somewhat, ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] dri: Remove driver date from renderer string
(radeon-radeonScreen)) {
sprintf(buffer[offset], TCL);
diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c
b/src/mesa/drivers/dri/radeon/radeon_context.c
index 154a881..4d41e99 100644
--- a/src/mesa/drivers/dri/radeon/radeon_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_context.c
@@ -70,8 +70,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
#define need_GL_OES_EGL_image
#include main/remap_helper.h
-#define DRIVER_DATE 20061018
-
#include utils.h
#include xmlpool.h /* for symbolic values of enum-type options */
diff --git a/src/mesa/drivers/dri/savage/savagedd.c
b/src/mesa/drivers/dri/savage/savagedd.c
index 3f8d7aa..c7f58835 100644
--- a/src/mesa/drivers/dri/savage/savagedd.c
+++ b/src/mesa/drivers/dri/savage/savagedd.c
@@ -38,8 +38,6 @@
#include utils.h
-#define DRIVER_DATE 20061110
-
/***
* Mesa's Driver Functions
***/
@@ -71,7 +69,7 @@ static const GLubyte *savageDDGetString( struct gl_context
*ctx, GLenum name )
case GL_VENDOR:
return (GLubyte *)S3 Graphics Inc.;
case GL_RENDERER:
- offset = driGetRendererString( buffer, cardNames[chipset], DRIVER_DATE,
+ offset = driGetRendererString( buffer, cardNames[chipset],
screen-agpMode );
return (GLubyte *)buffer;
default:
diff --git a/src/mesa/drivers/dri/sis/sis_dd.c
b/src/mesa/drivers/dri/sis/sis_dd.c
index 90e894b..bba516f 100644
--- a/src/mesa/drivers/dri/sis/sis_dd.c
+++ b/src/mesa/drivers/dri/sis/sis_dd.c
@@ -45,8 +45,6 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include utils.h
-#define DRIVER_DATE 20060710
-
/* Return the width and height of the given buffer.
*/
static void
@@ -78,7 +76,7 @@ sisGetString( struct gl_context *ctx, GLenum name )
return (GLubyte *)Eric Anholt;
case GL_RENDERER:
- offset = driGetRendererString( buffer, SiS, DRIVER_DATE, agp_mode );
+ offset = driGetRendererString( buffer, SiS, agp_mode );
return (GLubyte *)buffer;
diff --git a/src/mesa/drivers/dri/tdfx/tdfx_dd.c
b/src/mesa/drivers/dri/tdfx/tdfx_dd.c
index d60931a..e981f9a 100644
--- a/src/mesa/drivers/dri/tdfx/tdfx_dd.c
+++ b/src/mesa/drivers/dri/tdfx/tdfx_dd.c
@@ -41,9 +41,6 @@
#include main/context.h
-#define DRIVER_DATE 20061113
-
-
/* These are used in calls to FX_grColorMaskv() */
const GLboolean false4[4] = { GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE };
const GLboolean true4[4] = { GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE };
@@ -91,7 +88,7 @@ static const GLubyte *tdfxDDGetString( struct gl_context
*ctx, GLenum name )
}
}
- (void) driGetRendererString(buffer, hardware, DRIVER_DATE, 0);
+ (void) driGetRendererString(buffer, hardware, 0);
return (const GLubyte *) buffer;
}
case GL_VENDOR:
diff --git a/src/mesa/drivers/dri/unichrome/via_context.c
b/src/mesa/drivers/dri/unichrome/via_context.c
index 77d7116..89c2a12 100644
--- a/src/mesa/drivers/dri/unichrome/via_context.c
+++ b/src/mesa/drivers/dri/unichrome/via_context.c
@@ -65,8 +65,6 @@
#define need_GL_EXT_secondary_color
#include main/remap_helper.h
-#define DRIVER_DATE 20060710
-
#include vblank.h
#include utils.h
@@ -100,7 +98,7 @@ static const GLubyte *viaGetString(struct gl_context *ctx,
GLenum name)
offset = driGetRendererString( buffer,
chipset_names[(id VIA_PM800) ? 0 : id],
- DRIVER_DATE, 0 );
+ 0 );
return (GLubyte *)buffer;
}
--
1.7.4
I can get behind this.
Reviewed-by: Corbin Simpson mostawesomed...@gmail.com
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: Include GIT SHA1 in GL version string
Ah, yeah, I can see how that might be a problem.
Sending from a mobile, pardon the brevity. ~ C.
On Mar 31, 2011 3:41 PM, Eric Anholt e...@anholt.net wrote:
On Thu, 31 Mar 2011 13:56:56 -0700, Corbin Simpson
mostawesomed...@gmail.com wrote:
On Thu, Mar 31, 2011 at 1:30 PM, Ian Romanick i...@freedesktop.org
wrote:
From: Ian Romanick ian.d.roman...@intel.com
---
Makefile|8
src/mesa/main/version.c |7 ++-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index a1ab65e..c85b903 100644
--- a/Makefile
+++ b/Makefile
@@ -5,7 +5,15 @@ TOP = .
SUBDIRS = src
+# The git command below generates an empty string when we're not
+# building in a GIT tree (i.e., building from a release tarball).
default: $(TOP)/configs/current
+ @touch src/mesa/main/git_sha1.h
+ @if which git /dev/null; then \
+ git log -n 1 --oneline |\
+ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 \1/' \
+src/mesa/main/git_sha1.h; \
+ fi
@for dir in $(SUBDIRS) ; do \
if [ -d $$dir ] ; then \
(cd $$dir $(MAKE)) || exit 1 ; \
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index c7a0d69..80fa0c2 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -25,6 +25,7 @@
#include imports.h
#include mtypes.h
#include version.h
+#include git_sha1.h
@@ -185,7 +186,11 @@ compute_version(struct gl_context *ctx)
ctx-VersionString = (char *) malloc(max);
if (ctx-VersionString) {
_mesa_snprintf(ctx-VersionString, max,
-%u.%u Mesa MESA_VERSION_STRING,
+%u.%u Mesa MESA_VERSION_STRING
+#ifdef MESA_GIT_SHA1
+ ( MESA_GIT_SHA1 )
+#endif
+,
ctx-VersionMajor, ctx-VersionMinor);
}
}
--
1.7.4
Hmm, wouldn't the output of git describe be more useful?
That's what we talked about initially, but since we tag releases of the
stable branches, git describe of master says:
snb-magic-2692-gb3d1c77
which is some tag off master that we pushed last year.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : Video decoding state tracker for Gallium3d
2011/3/25 Stéphane Marchesin stephane.marche...@gmail.com: On Fri, Mar 25, 2011 at 14:44, Matt Turner matts...@gmail.com wrote: On Wed, Mar 23, 2011 at 4:28 PM, ★ Emeric emeric.gra...@gmail.com wrote: Hi everyone, My name is Emeric, I am a 22 years old french student, and I am currently looking to apply to the google summer of code 2011. I saw the Gallium H.264 decoding idea on the X.Org GSoC page, and I am particularly interested by this project. A couple days ago, a few developer talked in passing about this idea on IRC. One point made was that shader-based video is kind of, well, not ideal, for cards that have dedicated hardware since it's going to utilize most of the cards resources and also use quite a bit of power in the process. Now, shaders may be the best we can do in practice, given the difficulties in releasing documentation for AMD's UVD, for instance, but still. Since Google (and most of the free software community) is pushing WebM over H264, it might be a good idea to focus instead of WebM. Clearly there are no cards today that support WebM video decoding, so this would be neat. I don't know, but I'd guess a lot of the code needed for WebM decoding is also useful for H264 decoding. I agree that WebM would be awesome. But what APIs are available that do WebM right now? It would be nice to use an existing API there. If I recall correctly, one of the fun parts of VDPAU was being able to advertise the different supported formats and pick and choose what's decodeable and what isn't. If there isn't a VP8 codec for VDPAU at the moment, we can always get that added to the libvdpau headers. Also, from a conversation last year with ajax, I do remember that Theora could definitely be an alternative first target, since it shares much of its decoding pipeline with h.264 and VP8, and there are lots of players out there that grok Theora. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : Thoughts about an OpenGL 4.1 state tracker
3). * It could be useful to be able to use the OpenVG state tracker in my EGL implementation. * Maybe Clover can be used to add OpenCL support to this state tracker. What not to implement = In short : all the old stuff. * OpenGL 1.x, OpenGL 2.x and the Compatibility profile. * Support for DRM drivers. * The indirect mode of GLX, wich isn't used anymore by the majority of applications. The questions = The first one is : are you interested by this ? Do you think it is possible to start this state tracker and to have it in a testable shape in three months (by testable I mean that we can run some example programs that use only a subset of the OpenGL Core profile, for example KWin, compatible with OpenGL ES 2, OpenGL 3 Core and which can use EGL). I've also a question regarding the GLSL compiler and TGSI : I will not implement an ir_to_mesa converter, but instead an ir_to_tgsi if needed. I don't know what is going on in the work of replacing TGSI with GLSL IR or even with LLVM IR. Fortunately, i think that converting the GLSL compiler's output to what can be used in the pipe driver will not be the more difficult part of the state tracker. Lastly, I have still to completely understand mapi and all the code handling the creation of a context given an API and extensions. Maybe this code is only needed for indirect GLX. Thanks for reading. I understand that this task is very big, but I hope that I will be able to make interesting things during this summer and that it will help Mesa to catch up on OpenGL. I will now continue to read the Gallium interfaces code and the OpenGL spec. I'm open to any question or remark. Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Coding or Table based approach for r600g? (was RFC: 0001-r600g-R700-can-do-more-than-8-tex-and-vtx-clauses.patch)
Whee, this is quite the Reply-to list. :3 My approach in r300_chipset.c (http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_chipset.c for those of you without a current checkout) is still there, and is largely the way that I considered best for handling this kind of thing. It's not exactly a table, but it's got a lot of the same properties and I felt it was a pretty good way to approach the problem of doc'ing and handling errata. For your example of an erratum that plagues only one specific chipset, I'd just set the default to be No, I don't have that problem, and then in the switch statement, set it to Yes, I do have that problem, for that chipset. Hope this helps. ~ C. 2011/3/9 Christian König deathsim...@vodafone.de: Am Mittwoch, den 09.03.2011, 07:00 +0100 schrieb Ferry Huberts: Hi, Disclaimer: I'm just a list reader. I've been wondering about this for a while: is there a structure in which information is stored that is tied to the card with which the code is dealing, and if not, isn't it a good idea to introduce one? This patch triggered this again for me because it seems that such a structure would be benefical both for performance and for code readability. The structure would get filled with information only once: when the card is detected. For the case of the patch this would mean that the function 'r600_bc_num_tex_and_vtx_clauses' would get replaced by retrieving a field from the structure, since the function only returns a constant (dependent on the type of the card). Hi, indeed a lookup table based approach has it's advantages, you could have a table for chipset features, chipset family informations and maybe also for alu opcodes. It's more readable and getting a specific information is faster (at least most of the time), and we already use this approach for the tgsi-alu opcode mapping, The major downside of such an approach is it's inflexibility, for example if a specific information depends in 99% of the cases on the chipset family you would normally put it into the table for the chipset family, but just imaging that only one chipset has a bug and can't do the specific feature. This would place you in the need to move this information into the chipset table. Remember this is just an (probably unrealistic example), but it should show the general problem. I don't want to make such a design decision on my own so I cc'ed everybody who committed patches into r600g in the last couple of weeks. So hey guys what do you think about it? And to make my own opinion clear: I also really prefer tables, but didn't used them in the past because I wasn't 100% sure which feature depends on what and which approach we really want. Regards, Christian. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] import the txc_dxtn code from libtxc_dxtn into mesa (Was: Merge floating to master)
--enable-float-formats should be fine. Stop messing with S3TC. I think things like my previous attempt to language-lawyer S3TC compatibility in without any patented code are a better use of time than silly patches to shoehorn it in to the detriment of the rest of us. On Mon, Mar 7, 2011 at 3:49 AM, Jon Severinsson j...@severinsson.net wrote: At Mon Mar 7, 2011 at 09:59:08, Jose Fonseca wrote: First, I don't agree with a one-size-fits-all enable-patented flag at all. Would something like --enable-patented=floating,s3tc (with plain --enable- patented enabling all of it for those of us in jurisdictions without swpat) work for you? At Mon Mar 7, 2011 at 09:59:08, Jose Fonseca wrote: And I agree with Dave -- the current dynamic library approach is much better. Well, except that floating can't be (easily) implemented using it, and if you are going to recompile mesa anyway... At Mon Mar 7, 2011 at 09:59:08, Jose Fonseca wrote: So let's not put everything in the same basket, and focus on the issue at hand, the floating point feature. Of course, this was intended for action after floating was merged. At Mon Mar 7, 2011 at 11:04:08, Dave Airlie wrote: Not sure what country you are in (I'm guessing France) that doesn't but the float patent texture is for hw/sw and isn't a swpat, so I'm guessing EU law applies just as much. If the float patent isn't a swpat, why hide it behind --enable-patented at all? If it a hwpat only the hw can infringe, and a licence for the hw is presumably taken care of by the hw vendor. If Mesa (a pure sw product) is able to infringe on it, it is (at least partly) a swpat, and as such not valid/enforceable in most of the world (standard IANAL disclaimer applies). If the floating2 branch can be merged into master without an --enabled-patented switch the entire rationale for this patch series disappears (at least for now). Regards Jon Severinsson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] pipe-video
Does anybody have any serious objections to merging pipe-video to master? (Aside from the merge conflicts which I'll try my best to handle...) ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glXMakeCurrent crashes (was: Re: How to obtain OpenGL implementation/driver information?)
to make Firefox 4 releasable without blacklisting many Windows drivers. Zhenyao Mo, in CC, is working on similar features in Chromium. Cheers, Benoit -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How to obtain OpenGL implementation/driver information?
God, I hate flying while sick. A bigger problem is that there is no good way to divine this info without actually loading the DRI driver, unless we want to reduce Linux compatibility to the same level as Win32 by only supporting the system graphics. OTOH, there are a lot of coincidental circumstances which might help pin down exactly which chipset and driver is in use. I guess knowing *which* versions of drivers have bugs, and what the bugs are, is part of the equation. Sending from a mobile, pardon the brevity. ~ C. On Feb 4, 2011 4:04 PM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Feb 4, 2011 at 6:50 PM, Benoit Jacob bja...@mozilla.com wrote: - Original Message - On Fri, 4 Feb 2011 08:58:31 -0800 (PST), Benoit Jacob bja...@mozilla.com wrote: - Original Message - On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob bja...@mozilla.com wrote: Hi, I'm trying to see how to implement selective whitelisting/blacklisting of driver versions on X11 (my use case is to whitelist drivers for Firefox). The naive approach consists in creating an OpenGL context and calling glGetString(), however that is not optimal for me, for these reasons: * This has been enough to trigger crashes in the past. * This can take long (this affects the startup time of the browser). * This doesn't always give driver version information (at least the ATI blob doesn't seem to). Ideally I want to be able to know the driver name, driver version, Mesa version, and any other thing that you think may be relevant. I need to get that information in a fast and safe way. Is there a good solution to this problem? It might even be acceptable to assume that the X server is local, although of course I would prefer a solution that works with remote X. I've been told to check xdriinfo, but this seems to only give the driver name and not a driver version. I've also been told that checking for GLX = 1.4 would already ensure Mesa = 7.9, is that correct? Cheers, Benoit There is no other way than glGetString if you ever experienced crash with it, it would be because you are doing something terribly wrong like using it without current context. glGetString is one of the most tested gl functions with the open source stack as it's the foundation of one of the most used gl program on linux aka glxinfo. I never did see glxinfo trigger a crash on any released mesa. It's not glGetString that's crashing, it's glXMakeCurrent. I forwarded a bug report from a user, though he's not been able to reproduce since: https://bugs.freedesktop.org/show_bug.cgi?id=32238 A search in Mesa's bugzilla confirms that I'm not alone: https://bugs.freedesktop.org/show_bug.cgi?id=30557 It seems that such crashes happen only after a X error in glxCreateNewContext. So it may be possible to avoid them by doing XSync and checking for errors. But that makes the process even slower. It's not surprising that we'd be hitting crashes that glxinfo doesn't, since we may have done lots of X and GL calls already earlier in our application. One could say that we should check driver information once and for all upon creation of the first GL context; but I've had users experiencing these crashes already upon creation of the first GL context (mozilla bug 616416) It would be good to get some testcases to produce these failures. I've spent the last 2 hours trying to come up with any way I could execute a valid series of GLX calls that would result in a segfault in MakeCurrent This user comment, https://bugzilla.mozilla.org/show_bug.cgi?id=616416#c27 suggests that it's related to rotating the screen. Also, this comment, https://bugzilla.mozilla.org/show_bug.cgi?id=616416#c1 gives precise version information (it may well have been fixed since, but we'd still want to blacklist the old version). on my non-gallium driver, focusing on getting an error from glXCreateNewContext(). I've got a couple of new piglit cases for GLX stuff out of it, but no evidence that there's a problem. If the gallium drivers are failing, they should just be fixed instead of blacklisting them so they never get fixed. We have no choice but to blacklist drivers that are known to be crashy; these days mainstream newspaper web pages are creating WebGL contexts just to 'test html5 features' (whatever that means). That bug 616416 was on economist.com. If we don't blacklist drivers for WebGL, then people with crashy drivers may no longer be able to access many web pages. Benoit The bottom line here is that there is no way around creating making current a GLX context. And i am pretty sure no one in mesa or Xorg is willing to through some nuts new API just for one app. mesa+Xorg glx have been around for long enough time that we can safely assume that
Re: [Mesa-dev] WebGL test suite, and whitelisting drivers / OpenGL implementations in Firefox
On Mon, Jan 17, 2011 at 1:11 AM, Dave Airlie airl...@gmail.com wrote: Results: (5231 of 5344 passed, 3 timed out) This was with the latest Intel mesa driver on an Ironlake laptop. However I got a random crash on a previous run, I'm guessing if we can figure out the misc crasher we'd be in a lot better place. I already started working on this. (A friend just got hired by Moz and I owe him one.) Basic analysis: The crash is in the Mesa-side DRI2 handler for flushing the frontbuffer. There's a segfault of very weird composition. The BT (which I can get if needed) goes back to glXMakeCurrent, and it looks like glXMakeCurrent is unbinding the current context, which is calling the DRI2 unbind callbacks, which calls frontbuffer flush, but part of the DRI2 context is screwy and we get a segfault. There's a couple problems though. The frontbuffer flush usually isn't fatal; it only kills us about one in five times. Sometimes it dies on the very first test, sometimes it dies halfway through the suite. There's no rhyme or reason to it. If you've got any ideas, I'm open to them. I bugged Kristian and he had no idea. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Autogenerate builtin_functions.cpp as part of the build process.
Argfl. Sending to list as well. On Wed, Jan 12, 2011 at 11:36 AM, Corbin Simpson mostawesomed...@gmail.com wrote: You're using Python 2.5 and this script needs Python 2.6. Do we want to keep Python 2.5 compat? ~ C. On Wed, Jan 12, 2011 at 4:09 AM, Andy Furniss andy...@ukfsn.org wrote: Kenneth Graunke wrote: Now that this works with both make and SCons, builtin_function.cpp no longer needs to live in the repository. After updating talloc to avoid a build error I am now getting - Regenerating builtin_function.cpp... python -t -O -O builtins/tools/generate_builtins.py /home/andy/Src/Mesa-git/mesa/src/glsl/builtin_compiler builtin_function.cpp builtins/tools/generate_builtins.py:25: Warning: 'with' will become a reserved keyword in Python 2.6 File builtins/tools/generate_builtins.py, line 25 with open(filename) as f: ^ SyntaxError: invalid syntax make[2]: *** [builtin_function.cpp] Error 1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] LLVM_CFLAGS
Isn't there a --cflags-only-I or something along those lines? Sending from a mobile, pardon the brevity. ~ C. On Dec 6, 2010 9:42 AM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Dec 6, 2010 at 9:15 AM, Brian Paul bri...@vmware.com wrote: On 12/05/2010 02:06 AM, Bob Gleitsmann wrote: Hello, Can someone explain the value of including this in mesa/src/gallium/Makefile.template: ifeq ($(MESA_LLVM),1) LIBRARY_DEFINES += $(LLVM_CFLAGS) endif ? This effectively adds the LLVM cflags to gcc compiles if LLVM is enabled. One side-effect of this is to include -O3 optimization no matter what, making debugging very difficult. Removing it seems to have no catastrophic effects (or even detectable ones). But maybe I am missing something. We need some of the LLVM C flags to get the -I path for headers, for example. I think we should use llvm-config --cppflags instead of --cflags. If you're using autoconf, try changing this line: LLVM_CFLAGS=`$LLVM_CONFIG --cflags` in configure.ac to use --cppflags instead. Does that help? I think the question is, what else is in llvm-config --cflags? If all that's needed is the include paths, then --cppflags would be sufficient. However, if there are macro definitions or compiler flags (e.g. -fomit-frame-pointer) in --cflags that are needed to properly use llvm, then I guess you need --cflags. This is really a bug in llvm, but the last time someone here tried to bring it up to the llvm people, it was dismissed. Here's that bug: http://llvm.org/bugs/show_bug.cgi?id=8220 There's some more in the mesa archives, but I can't find the thread now. Sadly, that bug became a discussion about pkg-config which was not what was intended. -- Dan ___ 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] Path to optimize (moving from create/bind/delete paradgim to set only ?)
On Tue, Nov 16, 2010 at 9:17 PM, Jerome Glisse j.gli...@gmail.com wrote: On Tue, Nov 16, 2010 at 3:51 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse j.gli...@gmail.com wrote: Hi, So i looked a bit more at what path we should try to optimize in the mesa/gallium/pipe infrastructure. Here are some number gathers from games : drawcall / ps constant vs constant ps sampler vs sampler doom3 1.45 1.39 9.24 9.86 nexuiz 6.27 5.98 6.84 7.30 openarena 2805.64 1.38 1.51 1.54 (value of 1 mean there is a call of this function for every draw call, while value of 10 means there is a call to this function every 10 draw call, average) Note that openarena ps constant number is understable as it's fixed GL pipeline which is in use here and the pixel shader constant doesn't need much change in those case. So i think clear trend is that there is a lot of constant upload and sampler changing (allmost at each draw call for some games) Can you look into what actually changes between the sampler states? Also that vs sampler state change number for OpenArena looks a bit fishy to me. Cheers Jakob. I haven't looked at what change yet, i assume something small, i think bugle trace of the engine is maybe easier to use than looking at quake3 source code. For the vs sampler i was surprised too but it's just the fact that q3 changes the vertex buffer a lot and this trigger the vs sampler. Could we get some problematic Bugle traces posted that we could all examine, rather than guessing at this? It'd be very nice to know whether or not the problems are in the GL state tracker layer before we move on to optimizing Gallium's interface, mostly because Dx appears to not suffer these same problems. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status update of XvMC on R600
This. I thought that, to trigger uploads, we just had to change the domain on the buffer. Sending from a mobile, pardon the brevity. ~ C. On Nov 11, 2010 3:00 PM, Jerome Glisse j.gli...@gmail.com wrote: 2010/11/11 Keith Whitwell kei...@vmware.com: There is still more to do there. Currently r600g treats buffer and texture uploads separately, and I've only attempted to improve texture uploads. Buffer is just as important however. The change needed is likely to be one of two: a) Allow newly created vertex buffers to be in the GTT domain, where they can be mapped cached. b) Provide a staging resource upload path (with the staging buffer in GTT domain). The latter will catch more cases and doesn't suffer from waits for the engine to go idle when accessing an in-use buffer. The former is probably fastest for the cases where it works. Right now staged texture uploads use a 3d blit to copy from the staging resource to the final destination. That probably won't work (directly at least) for buffer uploads as buffer dimensions (eg 64k by 1) mean they usually can't be bound as render targets. So we need to jump through some hoops to get a hardware upload path in the absence of a DMA engine or 1d-blit. Keith I am not sure on how gallium texture upload was ever supposed to be or done, but from memory management point of view the idea i had was to create all bo in GTT and let migrate them to VRAM once they are use, eliminating any need for staging buffer. So it would be allocate bo, memcpy to bo the content of the texture, use bo and set it as vram bo so kernel migrate it to vram, that way you take advantage of kernel bo move which should be faster than any blit helped move. Anyway this was my initial thinking when doing the code. Cheers, Jerome Glisse ___ 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] Getting Hw Acceleration without X-Window
On Wed, Nov 3, 2010 at 12:53 PM, Clurado cl clurado1...@gmail.com wrote: Can wayland be ported for use of gles1 ?! i saw compositor-drm.c , but for me , its a little hard to know whats kristian does . it does compositing and idont need that. can u explain more !? it uses dri2 , but from here : http://www.mesa3d.org/egl.html . DRI2 have x surface unlinke dri1 it doesnt have framebuffer surface . so how it used in wayland ?! On Wed, Nov 3, 2010 at 11:07 PM, Chia-I Wu olva...@gmail.com wrote: On Thu, Nov 4, 2010 at 1:53 AM, Clurado cl clurado1...@gmail.com wrote: Hi all , its interesting topic , Q: simply i want to know is there any way to get Hw Accl 3d with DRI and draw it on the screen without x ( also glx ) ?! my first approach is wayland but my device doesnt support pixel and vector shaders , so i cant use gles2 ( wayland requires ) second is egl/dri ( one ) but this egl driver was deprecated from mesa . third is miniglx , its dead ( is it functional ?! ) there are some other approches but non of them can power the intel hardwares . so i want to disscuss with u about the topic . Q: can we use egl and egl_dri2 ?! Which device is this? Which drivers are you using? -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal for a long-term shader compiler (and IR) architecture
On Mon, Oct 18, 2010 at 12:27 PM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-10-18 at 10:52 -0700, Keith Whitwell wrote: On Mon, Oct 18, 2010 at 9:18 AM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Oct 15, 2010 at 7:44 PM, John Kessenich jo...@lunarg.com wrote: Hi, LunarG has decided to work on an open source, long-term, highly-functional, and modular shader and kernel compiler stack. Attached is our high-level proposal for this compiler architecture (LunarGLASS). We would like to solicit feedback from the open source community on doing this. I have read several posts here where it seems the time has come for something like this, and in that spirit, I hope this is consistent with the desire and direction many contributors to this list have already alluded to. Perhaps the biggest point of the proposal is to standardize on LLVM as an intermediate representation. This is actually done at two levels within the proposal; one at a high-level IR close to the source language and one at a low-level IR close to the target architecture. The full picture is in the attached document. Based on feedback to this proposal, our next step is to more precisely define the two forms of LLVM IR. Please let me know if you have any trouble reading the attached, or any questions, or any feedback regarding the proposal. Thanks, JohnK Just a quick reply (i won't have carefully read through this proposition before couple weeks) last time i check LLVM didn't seemed to fit the bill for GPU, newer GPU can be seen as close to scalar but not completely, there are restriction on instruction packing and the amount of data computation unit of gpu can access per cycle, also register allocation is different from normal CPU, you don't wan to do register peeling on GPU. So from my POV instruction scheduling packing and register allocation are interlace process (where you store variable impact instruction packing). Also on newer gpu it makes sense to use a mixed scalar/vector representation to preserve things like dot product. LLVM has always been able represent both scalar and vectors. Although the dot product is not natively represented in IR, one can perfectly define an dot product intrinsic which takes two vectors and returns a scalar. I haven't look at the backends, but I believe the same applies. Last loop, jump, function have kind of unsual restriction unlike any CPU (thought i haven't broad CPU knowledge) Bottom line is i don't think LLVM is anywhere near what would help us. I think this is the big question mark with this proposal -- basically can it be done? I also think there are indeed challenges translating LLVM IR to something like TGSI, Mesa IR; and I was skeptical about standardizing on LLVM IR for quite some time, but lately I've been reaching the conclusion that there's so much momentum behind LLVM that the benefits/synergy one gets by leveraging it will most likely exceed the pitfalls. But I never felt much skepticism for GPU code generation. There is e.g., a LLVM PTX backend already out there. And if it's not easy to make a LLVM backend for a particular GPU, then it should be at very least possible to implement a LLVM backend that generates a code in a representation very close to the GPU code, and do the final steps (e.g., register allocation, scheduling, etc) in a custom pass. Therefore benefiting from all high level optimizations that happened before. If it can't be done, we'll find out quickly, if it can then we can stop debating whether or not it's possible. The biggest problems I had when trying to write an r300 backend for LLVM were largely because of the massively specialized nature of pre-Dx10 GPUs, which are closer to DSPs than anything LLVM normally targets. In particular, v4f32 is the only kind of register available, there's not really any way to spill registers, etc. I suspect nvfx and i915 have similar issues although I'll readily admit to not knowing the hardware that well. If we transparently LLVMize all shaders before handing them to pipe drivers, and use a low-level IR that retains LLVM's optimizations, then I am okay with that. If LLVM can understand enough of the various scheduling problems to be worthwhile for the entire shader path, then I'm okay with that too. I just don't want yet another intermediate layer that doesn't actually improve anything. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] depth writing and missing something
Just realized that the texture format table in question is in the TGSI doc page, at the bottom. It really should have its own page. ~ C. On Wed, Sep 29, 2010 at 11:36 PM, Jose Fonseca jfons...@vmware.com wrote: Sorry, I've should have drunk my morning coffee before replying. You're refferring to writing and not reading... Anyway, my comment for u_format still stands. But back to your example, it works because out[0] has position semantic. When writing to depth textures, their are bound as depth stencil buffer. Not in the color buffer. And whatever gets written to the z channel of the output position register will be used as the depth value. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Jose Fonseca [jfons...@vmware.com] Sent: Thursday, September 30, 2010 7:28 To: Dave Airlie; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] depth writing and missing something There are two things to consider: u_format.csv description for depth stencils is a bit special for practical reasons, and pipe_sampler_view swizzles. Several functions in u_format_xxx.c need to be able to read/write stencil, and this is why u_format.csv describes depth stencil's swizzles as producing Z S x x. But the stencil channel will never be present when the texture is read as RGBA tuple. Sampling from a depthstencil texture should always produce Z Z Z 1 or Z 0 0 1, even before any sampler swizzles are applied. I think Brian documented this somewhere in gallium/docs/ but I can't find it now. At any rate, provided the first channel has z, then the state tracker will specify how he wants the other channels to be filled in the pipe_sampler_view' swizzles. Effectively, the gallium spec could say that sampling from depth textures should match (Z x x x). This is my understanding of the current state. We could polish this more a little. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Dave Airlie [airl...@gmail.com] Sent: Thursday, September 30, 2010 2:34 To: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] depth writing and missing something So I've been playing with stencil writing on r600, and it lead me to examine the depth writing. So at the moment in gallium if we are writing to depth via DrawPixels, we construct a fragment program that samples from a texture. TEX OUT[0].z, IN[1], SAMP[0], 2D Now from what I can see the format we pick to sample from is Z24_UNORM_S8_USCALED, which from the u_format.csv file seems to say it will put the results into X and Y components. Now if we sample from the X and Y components and the texture dest writemask is Z, I can't see how any value arrives in the right place. It seems to work but I'm a bit lost where the magic is. I'd have expected there to be swizzles in the sampler but I can't see them being set to anything special either. Dave. ___ 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] classic driver cleanup: ChooseTexFormat
On Sat, Sep 25, 2010 at 6:31 AM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Sep 24, 2010 at 8:08 PM, Eric Anholt e...@anholt.net wrote: One of the uglier bits of the classic drivers, in my opinion, is the ChooseTexFormat hook. Most drivers are trying to get to a similar set of formats, and using similar fallbacks for unavailable formats. Worse, they need to cleverly choose formats based on the incoming type/format to avoid having to munge the data on the way in if possible, and everyone needs to work those out. So, rather than having each driver have these smarts, move it to the core. There are still some rough edges. There are not enough fallbacks yet to cover everything (see i810 for example), so drivers with a more restricted set of supported formats may need to add more lines to _mesa_choose_tex_format. Also, the endianness-dependent choice of formats in texmem.c and radeon's texturing isn't merged -- I knew I'd mess it up somehow if I did it on my own, so I'm leaving radeon for someone with big-endian to finish off. Any complaints, or should I go ahead and merge this? Do we care about all those old GPU ? r128, sis .. ? To me it seems like we pretend they work but my feeling is that no one use them. I think only radeon, nouveau intel classic driver are still in use. For the others i wouldn't mind stop pretending supporting them and removing them from the tree. I'll support tdfx, mga, and (when I can get the damn thing POSTing) r128. I have an sis VGA-USB thingy as well, but that'll take some hacking and probably can't do 3D, so whatever. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] D3D1x Revert
Can I revert this merge out of master? The Wine developers that contribute to Mesa are feeling very alienated by this code, and I think that it could stand to have some more discussion, especially about its legality. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Removing ARB_imaging subset extensions
On Sun, Sep 19, 2010 at 5:59 PM, Eric Anholt e...@anholt.net wrote: On our way to OpenGL 3.0, it would be nice to clean out some of the optional deprecated features that Mesa supports. The ARB_imaging subset is the highest on my list -- it significantly clutters up the pixel path, and has always been optional even though the specification text got rolled into OpenGL 1.2. ATI's proprietary driver never supported the imaging subset, and what I've read of NVIDIA's implementation online, its presence is a user trap. Keeping an implementation of it is not helping our users from a performance or portability perspective. I've pushed a branch to my repo removing most of SGI_color_matrix, SGI_color_table, EXT_histogram, and EXT_convolution. Here's the diffstat: drivers/common/driverfuncs.c | 2 drivers/common/meta.c | 82 -- drivers/dri/i965/brw_state_upload.c | 1 drivers/dri/intel/intel_extensions.c | 2 drivers/dri/intel/intel_tex_image.c | 20 drivers/dri/radeon/radeon_texture.c | 16 drivers/dri/savage/savagetex.c | 3 drivers/dri/unichrome/via_tex.c | 22 main/attrib.c | 29 main/blend.c | 6 main/colortab.c | 204 - main/colortab.h | 7 main/context.c | 8 main/convolve.c | 1307 -- main/convolve.h | 70 - main/dd.h | 9 main/debug.c | 3 main/dlist.c | 2 main/enable.c | 89 -- main/extensions.c | 17 main/get.c | 76 - main/histogram.c | 971 - main/histogram.h | 2 main/image.c | 141 --- main/image.h | 5 main/matrix.c | 6 main/mfeatures.h | 1 main/mtypes.h | 125 --- main/pixel.c | 170 main/querymatrix.c | 4 main/texcompress_fxt1.c | 3 main/texcompress_s3tc.c | 5 main/teximage.c | 62 - main/texstore.c | 210 - program/prog_statevars.c | 29 program/prog_statevars.h | 3 state_tracker/st_atom_pixeltransfer.c | 130 --- state_tracker/st_cb_readpixels.c | 3 state_tracker/st_cb_texture.c | 6 state_tracker/st_extensions.c | 1 swrast/s_copypix.c | 107 -- swrast/s_drawpix.c | 92 -- swrast/s_readpix.c | 59 - 43 files changed, 96 insertions(+), 4014 deletions(-) That's 2.7% of mesa/main/, and driver size dropped correspondingly. Note that we don't get to completely drop histogram.c and convolve.c, as we're supposed to have the entrypoints and just emit INVALID_OPERATION for the missing extensions even if the ARB_imaging subset isn't present. If we don't have any strong justification for keeping this code, I'd like to merge this to master. I am completely okay with this. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [BRANCH] Floating point textures and rendering for Mesa, softpipe and llvmpipe
I think we need to be sure we're not infringing on this patent. Until we know one way or the other I'd prefer that we don't merge this branch into master. In the mean time I'll see if I can learn more about the situation and find a way to proceed. I'm going to bring this up again in 2 weeks at XDS. We talked last year about *doing* something about a few of these patents, including this particular one, and I want to follow up on that. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] targets/egl: rename pipe_radeon to pipe_r300
On Sun, Aug 22, 2010 at 9:24 AM, Benjamin Franzke
benjaminfran...@googlemail.com wrote:
st/egl/x11/x11_screen.c requests a driver named r300 not radeon
KNOWN ISSUE: breaks st/egl/kms/
st/egl/kms requests a pipe named radeon
that will not be found now
so why not leaving pipe_radeon there?
that was possible as long we have only r300g.
now there is also r600g for which st/egl/kms also
requests a pipe named radeon
(possible solution in later commit)
---
src/gallium/targets/egl/Makefile | 14 +++---
src/gallium/targets/egl/pipe_r300.c | 27 +++
src/gallium/targets/egl/pipe_radeon.c | 27 ---
3 files changed, 34 insertions(+), 34 deletions(-)
create mode 100644 src/gallium/targets/egl/pipe_r300.c
delete mode 100644 src/gallium/targets/egl/pipe_radeon.c
diff --git a/src/gallium/targets/egl/Makefile
b/src/gallium/targets/egl/Makefile
index 1585e2d..636fceb 100644
--- a/src/gallium/targets/egl/Makefile
+++ b/src/gallium/targets/egl/Makefile
@@ -90,10 +90,10 @@ nouveau_LIBS := \
$(TOP)/src/gallium/drivers/nv50/libnv50.a \
$(TOP)/src/gallium/drivers/nouveau/libnouveau.a
-# radeon pipe driver
-radeon_CPPFLAGS :=
-radeon_SYS := -ldrm -ldrm_radeon
-radeon_LIBS := \
+# r300 pipe driver
+r300_CPPFLAGS :=
+r300_SYS := -ldrm -ldrm_radeon
+r300_LIBS := \
$(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
$(TOP)/src/gallium/drivers/r300/libr300.a
@@ -151,7 +151,7 @@ ifneq ($(findstring nouveau/drm,$(GALLIUM_WINSYS_DIRS)),)
OUTPUTS += nouveau
endif
ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
-OUTPUTS += radeon
+OUTPUTS += r300
endif
ifneq ($(findstring svga/drm,$(GALLIUM_WINSYS_DIRS)),)
OUTPUTS += vmwgfx
@@ -188,8 +188,8 @@ $(OUTPUT_PATH)/$(PIPE_PREFIX)i965.so: pipe_i965.o
$(i965_LIBS)
$(OUTPUT_PATH)/$(PIPE_PREFIX)nouveau.so: pipe_nouveau.o $(nouveau_LIBS)
$(call mklib,nouveau)
-$(OUTPUT_PATH)/$(PIPE_PREFIX)radeon.so: pipe_radeon.o $(radeon_LIBS)
- $(call mklib,radeon)
+$(OUTPUT_PATH)/$(PIPE_PREFIX)r300.so: pipe_r300.o $(r300_LIBS)
+ $(call mklib,r300)
$(OUTPUT_PATH)/$(PIPE_PREFIX)vmwgfx.so: pipe_vmwgfx.o $(vmwgfx_LIBS)
$(call mklib,vmwgfx)
diff --git a/src/gallium/targets/egl/pipe_r300.c
b/src/gallium/targets/egl/pipe_r300.c
new file mode 100644
index 000..2fa495e
--- /dev/null
+++ b/src/gallium/targets/egl/pipe_r300.c
@@ -0,0 +1,27 @@
+
+#include target-helpers/inline_debug_helper.h
+#include state_tracker/drm_driver.h
+#include radeon/drm/radeon_drm_public.h
+#include r300/r300_public.h
+
+static struct pipe_screen *
+create_screen(int fd)
+{
+ struct r300_winsys_screen *sws;
+ struct pipe_screen *screen;
+
+ sws = r300_drm_winsys_screen_create(fd);
+ if (!sws)
+ return NULL;
+
+ screen = r300_screen_create(sws);
+ if (!screen)
+ return NULL;
+
+ screen = debug_screen_wrap(screen);
+
+ return screen;
+}
+
+PUBLIC
+DRM_DRIVER_DESCRIPTOR(r300, r300, create_screen)
diff --git a/src/gallium/targets/egl/pipe_radeon.c
b/src/gallium/targets/egl/pipe_radeon.c
deleted file mode 100644
index 35550bc..000
--- a/src/gallium/targets/egl/pipe_radeon.c
+++ /dev/null
@@ -1,27 +0,0 @@
-
-#include target-helpers/inline_debug_helper.h
-#include state_tracker/drm_driver.h
-#include radeon/drm/radeon_drm_public.h
-#include r300/r300_public.h
-
-static struct pipe_screen *
-create_screen(int fd)
-{
- struct r300_winsys_screen *sws;
- struct pipe_screen *screen;
-
- sws = r300_drm_winsys_screen_create(fd);
- if (!sws)
- return NULL;
-
- screen = r300_screen_create(sws);
- if (!screen)
- return NULL;
-
- screen = debug_screen_wrap(screen);
-
- return screen;
-}
-
-PUBLIC
-DRM_DRIVER_DESCRIPTOR(radeon, radeon, create_screen)
--
1.7.1
I'm not so sure about this series, because (a) it should be possible
to come up with something that works for both EGL backends (b) we
haven't decided yet how much code r300g and r600g get to share.
Can some of the other people touching radeon code comment? Dave, Jerome, Marek?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] TGSI Sanity Checker
I can't find the email where we were discussing TGSI sanity. Did we want to move the sanity checker to galahad? Also should I be double-checking the documentation around galahad tests and making the documentation specify some of these caveats? The docs are currently really loose on specifying things and don't have any of the SHOULD/MUST/ALLOWED feel of the GL specs, but this might not be a problem given Gallium's flexibility. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium texture rectangles
On Wed, Aug 18, 2010 at 8:50 AM, Luca Barbieri l...@luca-barbieri.com wrote: For instance use 2D/normalized for internal rendering iff the driver advertises CAP_2D_NPOT, otherwise use RECT/non-normalized. Yes, indeed that makes more sense than adding a new cap for that. Hmm - my intention was that TEXTURE_RECT implies non-normalized coordinates -- so this doesn't look like it works. This must not be an absolute rule, because clCreateFromGLTexture2D can be passed GL_TEXTURE_RECTANGLE textures, that OpenCL can subsequently sample with any normalization and wrap mode. I have a feeling that CL performance will not matter that much for nvfx and r300, compared to nv50 and r600. Hence, I propose to make this dependent on the hypotetical PIPE_CAP_FLEXIBLE_SAMPLING cap that would be added when OpenCL is implemented. nVidia also has some OpenGL/DirectX interoperability extensions that might have the same issue. I like (1) for reasons of interface simplicity. If there was an option zero, that would be better still... I'm not sure this is a good idea, because it will cause a (slight) performance regression in r300g, that doesn't support unnormalized coordinates and emulates them with a multiply. In particular, all util_blitter operations on GL_TEXTURE_RECTANGLE would now require an extra per-pixel multiply on r300g. In practice it may have no significant effect on performance, but allowing the driver to express a normalization preference should also have no significant effect on the complexity of the codebase. r300 having to emit a shader instruction unconditionally in this case really isn't that big of a deal. We don't blit that often, and we're still coming out far ahead of where we'd be if we were turning on the 2D engine for every blit. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium texture rectangles
Xorg, at least, should be able to get by with only rects; just gotta write the code. Sending from a mobile, pardon the brevity. ~ C. On Aug 18, 2010 4:55 PM, Luca Barbieri l...@luca-barbieri.com wrote: Pushed a new version that had no piglit regressions on nv30, softpipe and softpipe without NPOT. Vega, Xorg, EGL and WGL still require PIPE_CAP_NPOT_TEXTURES to work properly, but this can be fixed later if desired. It should hopefully have a decent chance of being correct or nearly so at least if PIPE_CAP_NPOT_TEXTURES is supported, or if only OpenGL with DRI is used in case it isn't supported. ___ 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] [PATCH 1/3] u_cpu_detect: make arch and little_endian constants, add abi and x86-64
On Fri, Aug 13, 2010 at 8:03 PM, Luca Barbieri l...@luca-barbieri.com wrote: #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) #define PIPE_ARCH_LITTLE_ENDIAN #elif defined(PIPE_ARCH_PPC) || defined(PIPE_ARCH_PPC_64) #define PIPE_ARCH_BIG_ENDIAN #else #define PIPE_ARCH_UNKNOWN_ENDIAN #endif Note that this isn't really correct: there endianness must be known by the compiler, since it must choose a way to represent global initialized 16/32-bit integer variables, among others. Also, at least some PowerPCs can be configured as little endian (even though it is unusual to do so). Usually the compiler sets the macro WORDS_BIGENDIAN to indicate big-endian targets, and this is the one that should be tested. Feel free to fix it; I introduced those as a base for some r300g PPC-specific fixes, and have never owned the relevant hardware. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/3] Make Gallium aware of GL_TEXTURE_RECTANGLE
On Wed, Aug 11, 2010 at 4:44 AM, Luca Barbieri l...@luca-barbieri.com wrote: Currently Gallium doesn't know about GL_TEXTURE_RECTANGLE textures, except for the normalized coordinates bit in the sampler state. Also, internal code always use normalized coordinates. This works fine on new hardware, but on older hardware like nv30, coordinate normalization is coupled to the resource layout, and rectangular textures cannot be used with normalized coordinates in any way. This makes it impossible to write an efficient nv30 driver (and, in practice, it's also impossible to write a correct one without significant work). The proposed solution is as follows: 1. Add a new PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT resource flag, which tells Gallium that the resource is going to be used with unnormalized coordinates. This allows to distinguish GL_TEXTURE_RECTANGLE from GL_TEXTURE_2D in the case of POT texture. This is supposed in theory to be only an hint, but in practice drivers might not even work with the other normalization. 2. Make all internal drawing done by Mesa and Gallium support use of both unnormalized and normalized coordinates (e.g. blitter module) 3. Set the flag for GL_TEXTURE_RECTANGLE textures A previous revision was already sent a while ago to this list, when it was not opposed, but also didn't get a definitive signoff from Brian or Keith. Luca Barbieri (3): gallium: add PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT gallium: use unnormalized coords internally for NPOT textures st/mesa: set PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT for GL_TEXTURE_RECTANGLE src/gallium/auxiliary/util/u_blit.c | 38 ++ src/gallium/auxiliary/util/u_blitter.c | 48 +++ src/gallium/include/pipe/p_defines.h | 6 +++ src/mesa/state_tracker/st_atom_pixeltransfer.c | 2 +- src/mesa/state_tracker/st_cb_bitmap.c | 4 +- src/mesa/state_tracker/st_cb_drawpixels.c | 2 +- src/mesa/state_tracker/st_cb_texture.c | 18 +++- src/mesa/state_tracker/st_gen_mipmap.c | 8 +++- src/mesa/state_tracker/st_texture.c | 5 +- src/mesa/state_tracker/st_texture.h | 3 +- 10 files changed, 96 insertions(+), 38 deletions(-) I'm completely okay with this iteration of this patchset, since it requires no Gallium API changes and seems very straightforward. I do have a question, though, since I'm so unfamiliar with nvfx. In r300g there is a fragment program rewrite to normalize texcoords unconditionally for r300 and conditionally for r500. This is also how we fake our NPOT support. Is this kind of rewriting truly impossible for nvfx, or just time-consuming? This entire series has my Reviewed-by: Corbin Simpson mostawesomed...@gmail.com. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merge of glsl2 branch to master
On Mon, Aug 9, 2010 at 8:45 PM, Tom Stellard tstel...@gmail.com wrote: On Mon, Aug 09, 2010 at 07:05:52PM -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Stellard wrote: On Fri, Aug 06, 2010 at 03:24:50PM -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As of today the glsl2 branch has three piglit regressions WRT master, and there is only one crashing piglit tests. As before, we have tested swrast and i965. For master I used commit 27041d7cb, and for glsl2 I used commit c234d0b2. The results are available at http://people.freedesktop.org/~idr/results/. The regressed tests cases are: * draw_buffers-05.vert - As mentioned previously, the spec is ambiguous and Nvidia and AMD produce different results for this test. Until the spec ambiguity is resolved, I don't care about this failure. * glsl1-texcoord varying - This test accesses gl_TexCoord[] using a non-constant index without dimensioning the array. The new compiler correctly rejects this shader. Nvidia accepts it, but I believe they're going outside the spec (which they do a lot). I haven't tested this on AMD or Apple yet. Is this shader from an application? We've changed the test in piglit commit c6146f121, but I think it still isn't quite right. * fbo-drawbuffers-maxtargets - Fails on i965 because we don' have loop unrolling in the compiler or good array handling in the driver. We'll get loop unolling in the compiler first. Proper array handling will come to the driver once we move away from using Mesa IR. I propose that we merge master to glsl2 on *Friday, August 13th* (one week from today). Barring unforeseen issues, I propose that we merge glsl2 to master on *Monday, August 16th*. Here is a summary of the piglit regressions on r300g (with an r500 card) Thanks for the reply! I was starting to wonder if my message went to /dev/null. :) These fail because r300 does not implement the SSG opcode: glsl1-acos(vec4) function glsl1-asin(vec4) function glsl1-atan(vec4) function glsl-fs-asin glsl-fs-atan-1 glsl-fs-sign glsl-vs-sign Set sign. It's in NV_vertex_program2 (and 3) and NV_gpu_program4. * SSG: Adds a new set sign operation, which produces a vector holding negative one for negative components, zero for components with a value of zero, and positive one for positive components. Equivalent results could be achieved (less efficiently) in NV_vertex_program with multiple SLT, SGE, and arithmetic instructions. We can either add a lowering pass to break ir_unop_sign into more primitive operations, or drivers can implement the opcode. I don't have a strong opinion here. This one fails because r300 does not implement the DP2 opcode: glsl-fs-dot-vec2 Can r300 do a DP2? I looked at the i915 documentation, and we can implement it there using a DP2A. We can't do a lowering pass for this one, but we could have a flag to cause a different sequence to be generated. In that case, it may actually be better to just do it in the driver. These fail because r300 does not implement the CONT opcode: glsl1-for-loop with continue glsl1-while-loop with continue These should be fixed once loop unrolling is implemented. These three new opcodes shouldn't be a problem for us to implement. r300 also has D2A and the code is already there to send the continue instruction to the hardware, it just needs to be translated from TGSI. This one was fixed in master after master was merged into glsl2: glsl1-discard statement in for loop Not sure why this fails yet: glsl-fs-loop-nested This might also be unrolling related. Some more data would be good. These are almost certainly bugs in the r300 compiler that were uncovered by glsl2 generating a different instruction sequence. I don't think you need to worry about these. These fail on both r300g and llvmpipe with this error: tgsi/tgsi_ureg.c:746:ureg_emit_src: Assertion `src.File != TGSI_FILE_OUTPUT' failed. glsl-orangebook-ch06-bump glsl-deadcode-varying I guess that hardware can't read back outputs that have been written? Ugh. I'm not sure what to do about that one. Maybe a lowering pass to generate writes to a shadow copy that can be read? I'm not sure if this is a hardware limitation, or a limitation imposed by gallium, maybe someone who knows gallium a little better will be able to suggest a solution. It's not doc'd AFAIR, but TGSI forbids reading from outputs. (I think i915, r300, and nvfx have this limitation in HW as well, but I can't say for sure.) I haven't looked at ureg in a while, so I don't know if there's a utility that can rewrite to temp for these, or if somebody needs to write one. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa
Re: [Mesa-dev] [RFC] gallium: Make printing info on debug builds default off
Agreed to all of the above. Libraries, even debug builds, should stay silent by default. We can (and should!) just doc the various env vars instead, IMHO. Sending from a mobile, pardon the brevity. ~ C. On Aug 5, 2010 6:20 PM, Dave Airlie airl...@gmail.com wrote: On Fri, Aug 6, 2010 at 11:17 AM, Jakob Bornecrantz wallbra...@gmail.com wrote: This commit silences the printing off most of the debug information when running debug builds. The big culprits are the the tgsi sanity checker that gets run on all shaders on debug. All the options. And finaly the cpu caps printer. This came after a discussion on #dri-devel that --enable-debug should just make it possible to use gdb and not print a ton of stuff to stderr. My only hesitation is turning of the debug options since its rather usefull to know which options you can play with. Comments, acks and nacks please. ACK. I'm all for this, I think mesa also does some output which really, not something we should be seeing unless we ask for it. Dave. ___ 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] r600g plans
On Fri, Jul 23, 2010 at 3:49 PM, Jerome Glisse gli...@freedesktop.org wrote: Just heads up on r600g plan, i removed the compiler stuff it was getting messy and kind of stopped anyone else from working on other part of r600g. So now there is a very simple dumb tgsi - r600 assembler that does work and can run glxgears and couple others non textured demos. I want to freeze r600_asm* stuff as i plan to reuse at latter point with a proper optimizer (thought there is a couple of thing missing in it like splitting alu node when reaching the 256dwords limit). So now if you want to add opcode the only file you need to touch is r600_shader.c. Also i would like to avoid any kind of work on optimizing what it spit. I am going to add texture support over the next few days (target being tri-tex, multiarb, tunnel, tunnel2 at that point i think quake engine should run). Todo list (kind of sorted): - texture support - use const buffer rather than cfile - avoid recompiling the shader at each draw command (would improve speed a lot) - stencil support - support more states (blending, alpha, rasterization, ...) - geometry shader - tiling support - color mask support - hyperz - a proper compiler Feel free to pick something and have fun. You're awesome as usual. Can we talk about maybe some common optimizations to r300g and r600g (and maybe others) that can be done in TGSI? Code sharing is fun, and I *really* don't want to see features fall by the wayside just because the shader compiler needs work. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g plans
Sounds very much like what nv50 needs/does. I sense opportunity. :3 Posting from a mobile, pardon my terseness. ~ C. On Jul 23, 2010 5:09 PM, Jerome Glisse gli...@freedesktop.org wrote: On 07/23/2010 07:11 PM, Corbin Simpson wrote: On Fri, Jul 23, 2010 at 3:49 PM, Jerome Glissegli... When i first looked at optimization i looked at r300 compiler, but thing is i want to try a different approach that would be very hard to apply to r300-r500 hw. Basic idea is to do all optimization as scalar, and repack the instruction after. The repacking is more or less easy on r6xx and after but it's really tricky on r3xx-r5xx. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] opencl (clover) patches question
Normally I wouldn't mind opening a new branch for your patches, but I don't have commit access to that repo and don't know the code. Zack? Posting from a mobile, pardon my terseness. ~ C. On Jul 21, 2010 6:10 PM, Anthony Waters awate...@gmail.com wrote: mesa-dev, I've done some work with mesa's implementation of opencl (clover) (bug fixes and features), is it acceptable to email the patches to this list? I noticed a patch from 6+ months ago was never applied http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg10561.html from another author. It would be best if this patch was applied first (part of my patches address the same concerns so it would be ideal for me to work off of them and merge my changes). ___ 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] Merge criteria for glsl2 branch
I personally do not care about Gallium breakage as long as the classic drivers do not break. This is because any Gallium breakage in that case would necessarily be from Gallium bugs, which I'd rather find sooner than later. Posting from a mobile, pardon my terseness. ~ C. On Jul 21, 2010 6:58 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As everyone knows, a group of us at Intel have been rewriting Mesa's GLSL compiler. The work started out-of-tree as a stand alone compiler. We moved all of our work to the glsl2 branch in the Mesa tree as soon as we had some actual code being generated. This was about month ago. Since that time we have implemented quite a bit more code generation and a complete linker. The compiler is not done, but it gets closer every day. I think now is the time to start discussing merge criteria. It is well known that the Intel graphics team favors quarterly releases. In order to align with other people's release schedules, we'd really like to have the new compiler in a Mesa release at the end of Q3 (end of September / beginning of October). That's just over two months from now. In order to have a credible release, the compiler needs to be merged to master before then. A reasonable estimate puts the end of August as the latest possible merge time. Given how far the compiler has come in the last month, I have a lot of faith in being able to hit that target. We have developed our own set of merge requirements, and these are listed below. Since this is such a large subsystem, we want to solicit input from the other stakeholders. * No piglit regressions, except draw_buffers-05.vert, compared to master in swrast, i965, or i915. * Any failing tests do not crash (segfault, assertion failure, etc.). draw_buffers-05.vert is specifically excluded because I'm not sure the test is correct. One of the items on the TODO list is proper support for GLSL ES. That work won't happen until the last couple weeks of August, so I don't think any sort of ES testing is suitable merge criteria. Unless, of course, the tests in question should also work on desktop GLSL. We haven't and, for all practical purposes, can't test with Gallium or other hardware drivers. The new compiler generates the same assembly IR that the current compiler generates. We haven't added any instructions. It does, however, generate different combinations of instructions, different uses of registers, and so on. We don't expect there to be significant impact on other hardware, but there may be some. The optimizer in r300 will certainly see different sequences of instructions than it is accustomed to seeing. I can't foresee what impact this will have on that driver. I have put up the results of master and the glsl2 branch at http://people.freedesktop.org/~idr/results/. This run off compiler.tests from the glsl2 branch of Eric's piglit repository. A few of the failures (half a dozen or so) on master seem to be mutex related in the GLX code. Kristian is working on fixing that. :) We're already very close to our proposed merge criteria. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHpJUACgkQX1gOwKyEAw9xfACfZkCpOE0Qo3+OXVJztiPVKpss FPwAn1NvXiSqXZk+XyWpRgPNfI5QtI18 =2Qs1 -END PGP SIGNATURE- ___ 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] [PATCH] Fix kFreeBSD build
I didn't ack the earlier version of the patch because it had no testers. Has this been tested? Posting from a mobile, pardon my terseness. ~ C. On Jul 18, 2010 8:48 AM, nobled nob...@dreamwidth.org wrote: All the other OS tests for FreeBSD use the form '*freebsd*', except for this line. This fixes the build on kFreeBSD/GNU. Based on the patch 06_kfreebsd-ftbfs.diff by Aurelien Jarno: http://bugs.debian.org/524690 NOTE: This is a candidate for the 7.8 branch. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 9619597..d6d37d2 100644 --- a/configure.ac +++ b/configure.ac @@ -800,7 +800,7 @@ if test $mesa_driver = dri; then ;; esac ;; -freebsd* | dragonfly*) +*freebsd* | dragonfly*) DEFINES=$DEFINES -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 DEFINES=$DEFINES -DIN_DRI_DRIVER -DHAVE_ALIAS DEFINES=$DEFINES -DGLX_INDIRECT_RENDERING -- 1.5.4.3 ___ 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] C extensions in Mesa
We cater to MSVC, so sections of code not protected by PIPE_ARCH need to be C89. Additionally, clarity is valued over tenseness. Elegance is even better, but there aren't many opportunities for that in this sort of code. :3 Posting from a mobile, pardon my terseness. ~ C. On Jul 16, 2010 3:52 PM, Segovia, Benjamin benjamin.sego...@intel.com wrote: Hello all, I did not find specific information about that. What is allowed in Mesa code base regarding C? Can I use C99 extensions (like variable not in the top of the scope, c++ comments) or gcc specific extensions (__vectors, labels as values...)? Cheers, Ben ___ 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] [PATCH 2/6] pipe: Add PIPE_OS_HURD
On Wed, Jun 23, 2010 at 6:31 PM, nobled nob...@dreamwidth.org wrote: One tiny step toward porting Gallium to the GNU/Hurd kernel (and fixing Debian bug #585618). --- src/gallium/include/pipe/p_config.h | 5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index 68025fa..b077933 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -146,6 +146,11 @@ #define PIPE_OS_UNIX #endif +#if defined(__GNU__) +#define PIPE_OS_HURD +#define PIPE_OS_UNIX +#endif + #if defined(__sun) #define PIPE_OS_SOLARIS #define PIPE_OS_UNIX -- 1.5.4.3 This is only defined on HURD, right? It's not part of the GCC-specific defines? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium API questions
On Thu, Jun 24, 2010 at 6:03 AM, Brian Paul bri...@vmware.com wrote: Keith Whitwell wrote: We currently allow partial specification of position, requiring only (x, y) and filling in z as 0 and w as 1 if missing. Is that still valid? Similarly, colors may be specified as (r, g, b) triplets with no alpha, and alpha defaults to 1. Is that still valid, or are there changes further up the API that make this not needed? I don't think either of those statements are true, except for the special case that in the fragment shader *only* position.z is writeable - ie the x,y coordinates are already fixed, and there is no meaning to writing the position.w coordinate once you're inside the fragment shader. I believe Corbin was referring to incoming vertex data in the case of glVertex2f and glColor3f, for example. I need to update the docs with fragment shader z-write... Yep. I went ahead and noted the lop rules (and added a small galahad test) and also filled out the vertex element page with some simple rules on vertex data formats. More work remains, but I have things on my plate for the day. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Gallium API questions
Yep, it's that time again. These are just things marked in the docs as unknown, so I'm not grinding any axes, just cleaning stuff up. ~ If a surface includes several layers/slices (XXX: not yet...) then all layers will be cleared. From the information on pipe_context::clear(). Is this just wishful thinking, or do drivers need to implement this? ~ An explanation of dual-source blends and how they work would be nice. ~ If logicop_enable and independent_blend_enable are set, are lops performed for all render targets, or only those that have blend_enable set? ~ PIPE_CAP_TEXTURE_SHADOW_MAP and PIPE_CAP_MAX_PREDICATE_REGISTERS aren't explained. ~ PIPE_CAP_GUARD_BAND_* obviously refers to the guard bands, but what exactly do they mean as capabilities? Maximum guard band settings? Minimum? ~ Could somebody explain exactly what's up with the RCC opcode? Its definition is kind of ridiculous: dst = (1 / src.x) 0 ? clamp(1 / src.x, 5.42101e-020, 1.884467e+019) : clamp(1 / src.x, -1.884467e+019, -5.42101e-020) ~ Are we going to introduce new cap bits for parts of the TGSI ISA? (I'll understand if this is off the table for now.) ~ TGSI_SEMANTIC_POSITION is (x, y, z, w) where x, y, and z are position, and w is the homogeneous coordinate. Is w also for perspective divide? Is the perspective divide configurable, or is it always done in shaders? ~ Position, if not specified, usually defaults to (0, 0, 0, 1), and can be partially specified as (x, y, 0, 1) or (x, y, z, 1). Usually is probably Corbin-speak for I'm just guessing here. Is that actually how it goes, or is position mandatory? ~ Can somebody explain the format of TGSI_SEMANTIC_EDGEFLAG? ~ What are the components of textures in the UV or Z format when sampled? For UV, current candidates are (0, 0, 0, 1) and (u, v, 1, 1). The latter seems more reasonable given that Gallium is shaderful. For Z, it could be (z, z, z, 1), (0, z, 0, 1), (0, 0, 0, z), or (z, z, z, z) and is configurable in GL. Maybe we want to have this be configurable? Thanks! ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium API questions
On Wed, Jun 23, 2010 at 4:36 PM, Brian Paul bri...@vmware.com wrote: I'll try to answer a few... Corbin Simpson wrote: Yep, it's that time again. These are just things marked in the docs as unknown, so I'm not grinding any axes, just cleaning stuff up. ~ If a surface includes several layers/slices (XXX: not yet...) then all layers will be cleared. From the information on pipe_context::clear(). Is this just wishful thinking, or do drivers need to implement this? ~ An explanation of dual-source blends and how they work would be nice. Marek provided a pointer, but I don't think we've done anything with this in gallium yet. ~ If logicop_enable and independent_blend_enable are set, are lops performed for all render targets, or only those that have blend_enable set? The GL_ARB_drawbuffers2 spec is a bit vague on this but in swrast logicop had precedence over blending and either applies to all color buffers or none. ~ PIPE_CAP_GUARD_BAND_* obviously refers to the guard bands, but what exactly do they mean as capabilities? Maximum guard band settings? Minimum? They're probably the guard band width in pixels. ~ Are we going to introduce new cap bits for parts of the TGSI ISA? (I'll understand if this is off the table for now.) ~ What are the components of textures in the UV or Z format when sampled? For UV, current candidates are (0, 0, 0, 1) and (u, v, 1, 1). The latter seems more reasonable given that Gallium is shaderful. For Z, it could be (z, z, z, 1), (0, z, 0, 1), (0, 0, 0, z), or (z, z, z, z) and is configurable in GL. Maybe we want to have this be configurable? Very cool. I like the new information, although a couple pieces of information vanished. We currently allow partial specification of position, requiring only (x, y) and filling in z as 0 and w as 1 if missing. Is that still valid? Similarly, colors may be specified as (r, g, b) triplets with no alpha, and alpha defaults to 1. Is that still valid, or are there changes further up the API that make this not needed? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI ISA formalization
On Thu, Jun 17, 2010 at 1:59 AM, Zack Rusin za...@vmware.com wrote: That doesn't make much sense to me, all those sets contain portion if not everything from the other set. If anything the instructions should be divided into something like: 1) move 2) arithmetic - integer - floating point - double 3) bitwise 4) resource access (sampling, tex instructions, ld etc done in the resources branch) 5) raster instructions (e.g. kill) 6) conditions (sge etc.) 7) control flow (bgnloop, call, end, if etc) 8) primitives (emit, end_primitivive) 9) type conversion Figuring out which state trackers use which for what purposes is a different problem. It could be noted in the instructions docs what uses it, but I doubt we'll be able to keep that up to date. I like the bitwise, flow control, and primitive groups. My main concern is splitting things into groups that make it easy to say, Oh yes, this hardware supports all of these opcodes. Also, we have a *lot* of opcodes. Any kind of grouping based on the semantics of the opcodes is going to be useful. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI ISA formalization
On Thu, Jun 17, 2010 at 11:34 AM, Zack Rusin za...@vmware.com wrote: Why would you want that? Is that useful to anyone? The state trackers will use the instructions they need whether a group of GPUs supports it or not, i.e. it's not like they could emulate LOAD. Besides we can't really do that. We already had a number of discussions about caps and the outcome each time was that you can't just create a few groups and expect the hardware to neatly fall into them (while quite frankly I never quite agreed with this sentiment, majority has spoken). In any way the question of which opcodes the given hardware supports is not up to gallium docs to define. I think we can only make it easy for people to understand the instructions Gallium does provide and for that logical grouping is really the only way to go. Considering the disparate ISAs of nvfx, r300, i915, and things we don't have public drivers for (yet), like poulsbo and volari; and considering the inability of contexts to fail to compile shaders, I'd say that this is not such a simple thing. Sure, TGSI has double opcodes. One might think that this is awesome, and writes a shader using double opcodes. But, it mysteriously doesn't work on r300g. Either it asserts (current behavior), or it drops all the rendering on the floor. We have no way to tell the state tracker that the shader failed to compile. In my mind, this is a big problem, since it requires drivers to magically Just Work for any shader. GL (and IIRC D3D) permit shaders to fail for arbitrary reasons; why can't we do the same? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI ISA formalization
I know that it won't work. I'm interested in how we will make it not work. I will back out some of my doc changes for now, but there are still too many potholes in the spec, and I do not want to unduly delay in fixing them. Posting from a mobile, pardon my terseness. ~ C. On Jun 17, 2010 12:05 PM, Zack Rusin za...@vmware.com wrote: Considering the disparate ISAs of nvfx, r300, i915, and things we don't have public drivers for ... What isn't such a simple thing? Sure, TGSI has double opcodes. One might think that this is awesome, and writes a shader using ... We don't provide access to those from anywhere, so that would be very hard. And when we do it's going to be in the next generation of state trackers and these will simply not work with r300g, so as far as I can tell that can't happen. The only scenario here that could make this even remotely possible is GL and the GL state tracker will need to solve this problem with caps like it already does. Runtime checking of those things is the only way it will ever work, docs just don't solve this problem. Either it asserts (current behavior), or it drops all the rendering on the floor. We have no wa... Yes, that's not ideal, but that's a different discussion. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] TGSI ISA formalization
So I've gone ahead and pushed some more doc patches, and I'll probably push more later too. One of them is 8b548846, which changes the TGSI ISA listing to be grouped by caps. The bits I've guessed at are: ~ Core ~ Compute ~ Geometry ~ GLSL ~ Double In addition, there is ps_2_x, which I'm hoping somebody can explain for me, and CONT, which is listed under compute but already has its own cap. Are these acceptable? I would assume that some of these want to be shuffled around to better match hardware. In my mind, the GLSL cap bit is especially annoying, and it only contains some loop instructions and NOP, and the latter can definitely be in core without hurting things. The goal here is to hopefully version out TGSI in a way that focuses on the abilities of each part of the ISA and not the NV extension in which they debuted. If you don't have a local copy of the docs, I have an up-to-date one at http://people.freedesktop.org/~csimpson/gallium-docs . Oh, and could we get the swizzle info for UV and Z textures settled? I finally doc'd the R and RG textures... ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI ISA formalization
On Wed, Jun 16, 2010 at 7:04 PM, Corbin Simpson mostawesomed...@gmail.com wrote: So I've gone ahead and pushed some more doc patches, and I'll probably push more later too. One of them is 8b548846, which changes the TGSI ISA listing to be grouped by caps. The bits I've guessed at are: ~ Core ~ Compute ~ Geometry ~ GLSL ~ Double In addition, there is ps_2_x, which I'm hoping somebody can explain for me, and CONT, which is listed under compute but already has its own cap. Are these acceptable? I would assume that some of these want to be shuffled around to better match hardware. In my mind, the GLSL cap bit is especially annoying, and it only contains some loop instructions and NOP, and the latter can definitely be in core without hurting things. The goal here is to hopefully version out TGSI in a way that focuses on the abilities of each part of the ISA and not the NV extension in which they debuted. If you don't have a local copy of the docs, I have an up-to-date one at http://people.freedesktop.org/~csimpson/gallium-docs . Oh, and could we get the swizzle info for UV and Z textures settled? I finally doc'd the R and RG textures... One more thing! PIPE_CAP_SM3. What's up with this? Which opcodes belong here? Does this actually describe hardware accurately? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium-array-textures branch
On Mon, Jun 14, 2010 at 4:09 AM, Roland Scheidegger srol...@vmware.com wrote: I'm planning to merge this branch soon, though I'll fix some broken things first. In any case, the probably most fundamental change is that get_tex_surface not only got renamed (to create_surface) but also moved to context. In short, pipe_surface is not (or no longer as there were free standing surfaces once upon a time in gallium) some kind of 2d surface which should be used in (non-rendering) state trackers to move any kind of images around. pipe_surface is meant to be used to attach resources to depthstencil and color render target outputs (similar to DX10 DepthStencil and RenderTarget Views). One thing though I'm not quite sure is if for array textures, the same field should be used in the resource as for storing depth of 3d textures (the depth0 field). Using the same layer field both for faces, array index and 3d depth seems to make a lot of sense for transfers, the sampler views and in pipe_surface, but I'm not sure the same field should be used in the resource itself. I've actually converted some code to do that (but not quite all for instance the mesa state tracker is broken there). The reason for using the same field would be that it's mutually exclusive anyway (unless someone introduces 3d array textures...), hence not really 2 fields are necessary. But OTOH depth behaves differently to arraysize (and cube faces) because it doesn't get minified for smaller mips. So if someone has convincing reasons what should be preferred I'll follow it :-). One this is for sure though we need some way to store array size, and cube maps will follow that pattern since for resource handling they are pretty much the same as a 2d array texture with array size of 6. This all seems fine. Drivers for pre-texture-array chipsets can handle all this by forcing off trilinear filtering, right? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stream output
On Tue, Jun 8, 2010 at 6:25 AM, Roland Scheidegger srol...@vmware.com wrote: But only chips supporting DX10 typically can really export data after geometry shader stage. It doesn't look to me like any kind of emulation is really feasible nor desirable. With that in mind, do we want to introduce a new object for this? pipe_stream_feedback or something along those lines? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stream output
On Mon, Jun 7, 2010 at 11:43 AM, Zack Rusin za...@vmware.com wrote:
Dear friends,
I'm a long lost prince of Nigeria and I'm writing to you with an incredible
business offer. I have this gallium-stream-output branch which is worth
$1000 and I'm going to send it your mesa/master account for free! All you
have to do is review it (and send me $20 to cover my transaction costs).
In case of a successful completion of this transaction you'll be able to
indulge all your senses with a plethora of amazing new
words_combined_with_underscores. Some of my personal favorites include:
struct pipe_stream_output_state
{
/** number of the output buffer to insert each element into */
int output_buffer[PIPE_MAX_SHADER_OUTPUTS];
/** which register to grab each output from */
int register_index[PIPE_MAX_SHADER_OUTPUTS];
/** TGSI_WRITEMASK signifying which components to output */
ubyte register_mask[PIPE_MAX_SHADER_OUTPUTS];
/** number of outputs */
int num_outputs;
/** stride for an entire vertex, only used if all output_buffers
* are 0 */
unsigned stride;
};
which is the main stream output object and
struct p_context {
...
void * (*create_stream_output_state)(struct pipe_context *,
const struct pipe_stream_output_state
*);
void (*bind_stream_output_state)(struct pipe_context *, void *);
void (*delete_stream_output_state)(struct pipe_context*, void*);
void (*set_stream_output_buffers)(struct pipe_context *,
struct pipe_resource **buffers,
int *offsets, /*array of offsets
from the start of each
of the buffers */
int num_buffers);
};
There's also a short blurb about the whole thing in the official gallium
docs, you can preview it at
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/docs/source/context.rst?h=gallium-stream-out
.
If you have any concerns please let me know.
Ah, hello. I am going to university and working on a project. The
project is in C# and Java but I think that your project is like mine.
I would appreciate very much if you could email me the codes for your
project. My name is Corbin and I am in university. I do have several
questions though.
This is for vert feedback, not render-to-VBO, correct? Do we have a
list of HW that can do it? Is there a trivial way to emulate this on
older HW, or should those chipsets just use Draw?
Thank you very much for the docs. Looks good.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-front-ccw branch
On Fri, May 21, 2010 at 8:00 AM, José Fonseca jfons...@vmware.com wrote: On Fri, 2010-05-21 at 07:45 -0700, Keith Whitwell wrote: On Wed, 2010-05-19 at 05:29 -0700, Keith Whitwell wrote: So, the front vs. ccw feature branch is working pretty well for softpipe and llvmpipe. I've got some documentation fixup to do, but it would also be good if the various driver owners could take a look at the changes there. I've tried to adjust each driver correctly, but it's likely that mistakes have crept in... OK, interpreting silence as approval... Let me know if there are any problems. I had no time to check the code, but I think the general idea good FWIW. Just tested, works excellently over here. The actual patch to r300g was perfect. (I *knew* commenting that code block would help somebody!) ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa devel requiring Python
On Sun, May 2, 2010 at 8:17 AM, José Fonseca jfons...@vmware.com wrote: On Thu, 2010-04-29 at 09:50 -0700, Karl Schultz wrote: What version of Python is needed to run these build scripts? Are there any other prerequisites? I just realized it's not just vanilla python. The GL API code generation requires python-libxml2 . http://users.skynet.be/sbi/libxml-python/ . Is it important to remove this dependency? Python is typically built with expat already and has a handful of XML handlers builtin; I could rewrite the code in question. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] New state tracker: Pylladium
So I got bored a few days ago and broke ground on a little bit of code I've had in mind for a while. This is a new state tracker, Pylladium, that acts to expose the core Gallium objects of a driver in a clean, Pythonic fashion, without being overly low-level or abstracted away. So why make another tracker when there's already a great one maintained by Jose? 1) SWIG. The current tracker must be compiled against a pipe driver library, and can't dynamically switch between drivers. Additionally, it can't be run on any Python besides CPython, which is mostly a personal annoyance but something some people honestly have to work with. 2) The interface, being SWIG'd, is a straight copy of the interface defined in the Gallium headers, which isn't very Python-friendly. In particular, there's no encapsulation. Zack indicated this was a feature, not a bug, and frankly, I agree. It was designed to replicate the Gallium interface in Python, and it does it well. No need to change it. 3) I could not pass up the pun. Seriously, I've been sitting on it for months, and I finally got fed up and acted on it. You can take a look at the general direction I've taken at http://cgit.freedesktop.org/~csimpson/pylladium . It acts on raw Gallium drivers, something not present yet in master. My raw-targets branch of Mesa (http://cgit.freedesktop.org/~csimpson/mesa/log/?h=raw-targets) has a r300g target already and I have an i915g target that I'll push when I get home later. These drivers make drm_api_create being publicly accessible. (I needed to do this because one cannot dlopen() DRI or EGL drivers in the general case.) A softpipe variant using null_sw_winsys should be fairly trivial, but I haven't done it yet. One thing that I feel is important: This isn't meant to be performant. At all. Buffers are going to be displayed through a variety of fairly slow methods, most of them likely involving PIL. ctypes is the binding I'm using, and it incurs a fair overhead on anything besides PyPy. This is meant to be a clear demonstration of how the objects in Gallium interact and work, more than anything else. Oh, and a brief demonstration, culled from my main.py: da = drm.DrmApi(raw) print Loaded drm_api object, name %s % da.name s = da.create_screen(raw.drmOpen(da.name, None)) print Created screen, name %s vendor %s % (s.name, s.vendor) if s.params[GLSL]: print Whoo, GLSL! else: print No GLSL... b = screen.Bindings() b.RENDER_TARGET = True b.SAMPLER_VIEW = True g = screen.Geom() for name, number in formats.by_name.iteritems(): if s.is_format_supported(number, 2, b, g): print %s is an acceptable FBO colorbuf % name Comments, criticisms, flames, etc. welcome. ~ C. (Just watch, Phoronix; next time, it'll be a tracker for Flash rendering. I'll call it, Galoshes!) -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Convert mesa to automake/libtool
On Sun, May 2, 2010 at 10:48 AM, Eric Anholt e...@anholt.net wrote: On Sun, 2 May 2010 09:46:15 -0700, Dan Nicholson dbn.li...@gmail.com wrote: Brian, I'm putting forward this request completely understanding your position why you don't want automake and libtool in your project. However, I think that mesa has outgrown the static Makefiles approach for a number of reasons. For a project that's grown to the complexity of mesa, I believe you need something that is more flexible and robust than the current system can provide. Eric (and I think Corbin, too) has a branch adding automake and libtool to the mesa repo. http://cgit.freedesktop.org/~anholt/mesa/log/?h=automake Yeah, I got burned out on that work because the initial change is huge. My intention for that branch was to get it to the point that it could replace the static Makefiles and squash-merge it (sadly, the history is completely unbisectable and has been sloppily rebased a couple of times.). The separate demos repo was a step towards making that work less intrusive (and because demos in the main repo has bothered me since I started out packaging Mesa). After that, several of the libraries could go away, and that branch would be much closer to done. I completely agree with the rest of Dan's reasons for using automake. In particular, it's standard, reliable, well documented, and we have a lot of expertise in it among Mesa developers. I'm sick of the Mesa build process for developers and casual followers having to start with make clean. I completely agree with these gentlemen. My automake branch is a bit further than Eric's, but it's more or less invalid now. It could build Gallium DRI drivers though. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Expose vertex/fragment progam limits in Mesa state tracker
On Fri, Apr 30, 2010 at 9:15 AM, José Fonseca jfons...@vmware.com wrote: I agree that deriving coarse grained caps from fine grained sounds better. Anyway, I'll apply this on until we have better caps system inplace, as it's better than nothing. One more question, having the design of these new fine caps in mind, are the gl_program_constants sufficient? MaxNativeInstructions MaxNativeAluInstructions MaxNativeTexInstructions MaxNativeTexIndirections MaxNativeAttribs MaxNativeTemps MaxNativeAddressRegs MaxNativeParameters One obvious omission relative to D3D9 caps are max dynamic control flow depth. These are not mentioned in the R300ToDo wiki page. Does hardware we care about has such limitations too? Also, it's interesting to read on the R300ToDo wiki page Vertex formats GL_*INT and GL_DOUBLE are not supported. GL_*SHORT is supported only for 2- and 4-component vertex attributes, and GL_*BYTE only for 4-component attributes. All individual vertex attribute fetches must be DWORD-aligned. This clearly resembles the http://msdn.microsoft.com/en-us/library/bb172533(VS.85).aspx . It appears that modifying draw module or a new library for software vertex fetch/emit without vertex shading would be useful for a lot of hardware. Jose On Thu, 2010-04-29 at 14:12 -0700, Marek Olšák wrote: I was getting at your former idea of replacing caps with feature levels. I was also commenting on the proposed José's patch that we should have fine-grained On Thu, Apr 29, 2010 at 10:09 PM, Zack Rusin za...@vmware.com wrote: On Thursday 29 April 2010 15:44:35 Marek Olšák wrote: On Thu, Apr 29, 2010 at 8:30 PM, Zack Rusin za...@vmware.commailto:za...@vmware.com wrote: It seems like all we'd really need is relate those things to the feature/api levels it exposes and document it. Feature levels are a pretty bad match for D3D9-level chipsets since the hardware is so divergent that you'd need a lot of them. You'd have at least 2 (I can come up with 3) levels just for r300g, at least two levels for nvfx, and another two levels for the i9xx drivers, provided all these drivers want to expose precisely every feature they can support. There is a reason for having shader models sm2.0, sm2.0a, and sm2.0b. Moreover this Microsoft idea is _absolutely_ useless for a GL driver. I like more the idea of having util functions for deriving feature levels from a set of caps rather than caps from feature levels. I'm not sure if you actually looked what Jakob committed, because what you're describing is what he's done. Or are you arguing against some part of that implementation? I was assuming you'd wanted to return to your former idea of replacing caps with feature levels rather than having what Jakob has committed. If it's not the case then ignore my message. Also looking at José's patch I think we should have fine-grained queries ideally for each shader stage separately if we want it to be useful at all. The proposed minimum limits are fine except that MaxNativeTexIndirections for ps2.0 should be 4. For an idea how the shader limits vary for r300g, please see the two tables at the beginning of this page: http://dri.freedesktop.org/wiki/R300ToDo Vertex formats GL_*INT and GL_DOUBLE are not supported. GL_*SHORT is supported only for 2- and 4-component vertex attributes, and GL_*BYTE only for 4-component attributes. All individual vertex attribute fetches must be DWORD-aligned. Yeah, one of the things I wanted to do was provide a shadow-VBO setup, and the primary consumer would be the driver (or state tracker, with caveats). At VBO bind, call a translate-on-steroids function that creates shadow VBOs as needed, filled with formats that the driver can handle. The caveat, of course, is that the state tracker would need access to the list of PIPE_FORMATs the driver can use in VBOs before it could call this function itself. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSOC: R300 GLSL Compiler
On Mon, Apr 26, 2010 at 10:59 PM, Tom Stellard tstel...@gmail.com wrote: Hi, I am honored to have my Google Summer of Code application accepted, and I am really looking forward to starting the project. Thanks to everyone who took the time to give me feedback on my proposal throughout the application process. It was great that there were so many people willing to help me out. My first goal is to find some hardware for testing. I have an RS480, which is fine for the branch emulation tasks, but I'll need to find an R500 card for when I start generating hardware branching instructions. Otherwise, when I get some free time, I'll be reviewing the code, setting up some test cases and getting ready for when the program starts at the end of May. I'm always hanging out in the IRC channels, and I'll try to ask questions as they come up. Thanks again to everyone. I can't wait to get started. Welcome (again) to the project! ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r300g + mesa/st support for EXT_texture_swizzle
Why do we need any caps for this? Unless I read the spec wrong, this is a mere SWZ following the affected texture lookup, in the worst case. Posting from a mobile, pardon my terseness. ~ C. On Apr 27, 2010 9:29 AM, José Fonseca jfons...@vmware.com wrote: On Tue, 2010-04-27 at 08:59 -0700, Roland Scheidegger wrote: On 27.04.2010 17:32, Roland Scheidegg... I think it is worthwhile to keep the format swizzle orthogonal to the sampler view swizzles. It is actually more complex trying to describe swizzles in terms of the packed vector, since they not always have unambiguous meaning (bitmasks, subsampled formats, compressed textures). Jose ___ mesa-dev mailing list mesa-...@lists.freedesktop.or... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa/Gallium overall design
[snip'd] Two observations: 1) I wrote most of a Gallium driver. By myself. It took OVER 9000 lines of code, but it happened. I'd say that an interface that permits one mediocre coder armed with docs to craft a working, simple driver in a couple months (effectively three man-months, by my estimate) is a roaring success. 2) I worked by myself. Except for occasional patches from the community (Marek, Joakim, Nicolai) and lately from Dave, the initial bringup was something I had to do by myself, without assistance. So what I'm seeing here is a chicken-and-egg problem where Gallium has no drivers because nobody wants to write drivers for it because its interface is unproven because it has no drivers... Now that we're actually having real drivers for real hardware reaching production quality, I think we can break this cycle and get people to start contributing to Gallium, or at least bump down to the next level of reasons why they won't write Gallium code. :3 Not that I'm saying excuses are bad or wrong, but in the end, r300g is 14.7klocs and r300c is 26.9klocs (and yes, I didn't count the shared shader compiler code), so the goal of Bring up drivers in less time, with less code, appears to be achieved. We are almost reaching r300c performance levels, and beating it handily in certain benchmarks, so it is possible to write good new drivers on this codebase. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
