-01 10:10, Martin Peres wrote:
>>
>> On 29/02/16 20:48, Jason Ekstrand wrote:
>>>
>>> On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert <galib...@pobox.com
>>> <mailto:galib...@pobox.com>> wrote:
>>>
>>> Ok, I can tell you that
Beware of path issues, vk* has no error checking and gives funky
values to the driver if it fails at finding its extra files.
OG.
On Tue, Mar 1, 2016 at 10:10 AM, Martin Peres <martin.pe...@free.fr> wrote:
> On 29/02/16 20:48, Jason Ekstrand wrote:
>
> On Fri, Feb 26, 2016 at 2
;ja...@jlekstrand.net> wrote:
> On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert <galib...@pobox.com>
> wrote:
>>
>> I'm actually interested about how one goes about debugging that kind
>> of problem, if you have pointers. I would have an idea or two on how
>> to go abou
Ok, I'll do that, thanks :-) No matter what, I'll learn interesting things.
OG.
On Wed, Feb 17, 2016 at 4:31 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert <galib...@pobox.com>
> wrote:
>>
>> I'm actually
at 2:51 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert <galib...@pobox.com>
> wrote:
>>
>> Hi,
>>
>> I'm getting gpu hangs with the lunarg examples (cube and tri) on my
>> Haswell (64 bits).
Hi,
I thought mesa was C++ by now? That API is really C-ish.
OG.
On Wed, Feb 18, 2015 at 2:12 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On Friday, February 06, 2015 04:00:10 PM Eric Anholt wrote:
v2: Rebase on the nir_opcodes.h python code generation support.
v3: Use SSA values,
Hi,
Not sure there's anything to maintain, but sure, I'll maintain it.
Best,
OG.
On Sun, Dec 21, 2014 at 8:51 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 20 December 2014 at 14:21, Olivier Galibert galib...@pobox.com wrote:
Here is an implementation I've written myself, so
Olivier Galibert Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify
Hi,
Something is not clear to me: In which way -1 is incorrect?
Also, w.r.t comments, what you're doing is masking, not clamping,
which incidentally is a good thing since clamping would be severely
bad for stencil.
Best,
OG.
On Thu, Dec 11, 2014 at 11:34 PM, Eduardo Lima Mitev
Note that ~0U is perfectly correct w.r.t the GLES3 spec. It just
means that s=32, which happens to be greater or equal to 8.
Best,
OG.
On Tue, Dec 16, 2014 at 8:58 AM, Eduardo Lima Mitev el...@igalia.com wrote:
On 12/15/2014 08:30 PM, Ian Romanick wrote:
On 12/15/2014 08:04 AM, Eduardo
Hi,
SHA1 is easy to implement. If you want an always-working backup, I
have a couple of C versions I wrote myself. Libraries are only
interesting if they offer significant speedups through cpu-dependance.
Especially since the shader cache is not in the happy fun land of
hardware-based attacks
Applied.
OG.
On Fri, Sep 26, 2014 at 6:11 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Our current atan()-approximation is pretty inaccurate at 1.0, so
let's try to improve the situation by doing a direct approximation
without going through atan.
This new implementation uses an 11th
Sorry for not replying earlier, I didn't see your answer.
On Thu, Sep 4, 2014 at 12:33 AM, Matt Turner matts...@gmail.com wrote:
Did you change the leading whitespace on purpose?
Not really, I can un-change that. I have an emacs config that's
supposedly what mesa wants, but it may be
.
On 08/21/2014 05:02 AM, Olivier Galibert wrote:
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/main/getstring.c | 6 ++
src/mesa/main/version.c | 140
+-
2 files changed, 143 insertions(+), 3 deletions(-)
diff --git a/src/mesa
This adds all the extension names and numbers, adds some missing
numbers and fixes the order in places. Future extension additions
should be slightly easier by not requiring to find where it should go
anymore.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mapi/glapi/gen/gl_API.xml
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/glsl_parser_extras.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 490c3c8..87d4846 100644
In that case staying as close as possible to spir may make sense?
OG.
On Fri, Aug 22, 2014 at 5:08 AM, Dave Airlie airl...@gmail.com wrote:
On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:
On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:
On 21
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/main/getstring.c | 6 ++
src/mesa/main/version.c | 140 +-
2 files changed, 143 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
index
And don't forget that explicit vec4 becomes immensely amusing once you
add fp64/double to the problem.
OG.
On Wed, Aug 20, 2014 at 4:01 PM, Francisco Jerez curroje...@riseup.net wrote:
Connor Abbott cwabbo...@gmail.com writes:
On Tue, Aug 19, 2014 at 11:33 PM, Francisco Jerez
Hi,
That patch makes glDrawBuffer(0, NULL); segfault because
_mesa_drawbuffers expects buffers[0] to be valid. Note that the bug
is there, but I'm not sure what the final setup should look like in
that case.
Best,
OG.
PS: reported by haagch on irc
On Fri, Aug 8, 2014 at 11:20 PM, Brian
On Mon, Jul 30, 2012 at 10:30:57AM -0700, Eric Anholt wrote:
I'm perfectly fine with the VUE containing slots for both when the app
has gone out of its way to ask for deprecated two-sided color
rendering.
Are you also ok with recompiler the shaders when that enable is
switched?
OG.
On Tue, Jul 17, 2012 at 07:37:43AM -0700, Paul Berry wrote:
If possible, I would still like to think of a way to address this situation
that (a) doesn't require modifying both fragment shader back-ends and the
SF program, and (b) helps all Mesa drivers, not just Intel Gen4-5.
Especially
On Thu, Jul 26, 2012 at 10:18:01AM -0700, Eric Anholt wrote:
Olivier Galibert galib...@pobox.com writes:
In some cases the fragment shader view of the vue registers was out of
sync with the builder. This fixes it.
s/builder/SF outputs/ ?
I'd love to see the pre-gen6 code get
On Thu, Jul 26, 2012 at 05:27:43PM -0700, Eric Anholt wrote:
As we get into supporting GL 3.x core, we come across more and more features
of the API that depend on the version number as opposed to just the extension
list. This will let us more sanely do version checks than (VersionMajor == 3
On Fri, Jul 27, 2012 at 10:40:28AM -0500, Bryan Cain wrote:
https://github.com/Plombo/mesa/tree/geometry-shaders .
Quick remarks from a fast read:
- you missed draw_pipe_clip.c:clip_init_state, where you need to plug
in the gs info where appropriate. Should be easy. It will take
care of
On Fri, Jul 27, 2012 at 10:49:19AM -0700, Kenneth Graunke wrote:
It's more convenient to use shortcuts like glsl_type::bvec2_type than
the longwinded glsl_type::get_instance(GLSL_TYPE_BOOL, 2, 1).
Yay, code in zones I understand :-)
Reviewed-by: Olivier Galibert galib...@pobox.com
On Fri, Jul 27, 2012 at 10:49:20AM -0700, Kenneth Graunke wrote:
+/**
+ * Convert sampler type attributes into an index in the sampler_types array
+ */
+#define SAMPLER_TYPE_INDEX(dim, sample_type, array, shadow) \
+ ((unsigned(dim) * 12) + (sample_type * 4) + (unsigned(array) * 2)
columns = 1.
Reviewed-by: Olivier Galibert galib...@pobox.com
That's an obvious bugfix. If there's a stable branch with the glsl
compiler in, it probably should go there.
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
On Fri, Jul 27, 2012 at 10:49:23AM -0700, Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
This matches the typeless constructors for unop and binop
ir_expressions.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
/glsl/ir.h
@@ -1027,7 +1027,7 @@ enum ir_expression_operation {
/**
* A sentinel marking the last of all operations.
*/
- ir_last_opcode = ir_last_binop
+ ir_last_opcode = ir_quadop_vector
};
Another obvious-in-hindsight bugfix.
Reviewed-by: Olivier Galibert galib
On Fri, Jul 27, 2012 at 10:49:25AM -0700, Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
There can only be one variable used in an ir_quadop_vector. Accesses
of this variable must be swizzled.
There's nothing anywhere ensuring the presence of the swizzle. I
completely
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index f215b90..0aeb8e2 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -1950,8 +1950,8 @@
On Thu, Jul 19, 2012 at 10:57:38AM -0600, Brian Paul wrote:
static const float ...
Indeed.
Reviewed-by: Brian Paul bri...@vmware.com
Thanks. Could you commit it please?
Best,
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Hi,
This is the second verion of the clipping/interpolation patches.
Main differences:
- I tried to take all of Paul's remarks into account
- I exploded the first patch in 4 independant ones
- I've added a patch to ensure that integers pass through unscathed
Patch 4/9 is (slightly)
In some cases the fragment shader view of the vue registers was out of
sync with the builder. This fixes it.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 -
src/mesa/drivers/dri/i965/brw_wm_pass2.c | 10 +-
2 files
This patch is mostly designed to make followup patches simpler, but
it's a simplification by itself.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_sf_emit.c | 93 +--
1 file changed, 52 insertions(+), 41 deletions(-)
diff
Previous code only selected two side in pure fixed-function setups.
This version also activates it when needed with shaders programs.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_sf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
most of the generated piglit tests useless to test the
backface selection, but it's simple and it works.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 +
src/mesa/drivers/dri/i965/brw_wm_pass2.c |9 +
2 files changed, 18
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c| 90 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965
would require putting
brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
thing, but it could have unexpected consequences, so it's better be
done independently in any case.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_clip.c | 13 --
src/mesa/drivers
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri
This patch ensures that integers will pass through unscathed. Doing
(useless) computations on them is risky, especially when their bit
patterns correspond to values like inf or nan.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip_util.c | 48
On Tue, Jul 17, 2012 at 03:41:44PM -0600, Brian Paul wrote:
On 07/13/2012 10:30 AM, Olivier Galibert wrote:
On Wed, Jun 20, 2012 at 08:33:38AM -0600, Brian Paul wrote:
Yeah, I think it's pretty clear that we need to support per-pixel LOD
selection. For softpipe, Olivier's big patch looks
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote:
Can you split this into three separate patches? That will make it easier
to troubleshoot in case we find bugs with these patches in the future.
I'm going to try.
Also, I'm not convinced that #3 is necessary. Is there something in
On Fri, Jul 13, 2012 at 02:45:10PM -0700, Kenneth Graunke wrote:
Sorry...been really busy, and most of us haven't actually spent much if
any time in the clipper shaders. I'll try and review it within a week.
Ok cool, lack of time is something I completely understand :-)
Despite the lack of
On Sat, Jun 30, 2012 at 08:50:10PM +0200, Olivier Galibert wrote:
This is the first part of the fixes I've done to make my gm45 work
correctly w.r.t clipping and interpolation. There's a fair chance
they work for everything gen 4/5, but I have no way to be sure.
So, not even one comment
On Thu, Jul 12, 2012 at 08:50:13PM +0100, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Tested by running piglit draw-instanced, and by forcing llvmpipe advertise no
native
integer support, which now produces:
Looks like a very good solution to me. Did you check
On Wed, Jun 20, 2012 at 08:33:38AM -0600, Brian Paul wrote:
Yeah, I think it's pretty clear that we need to support per-pixel LOD
selection. For softpipe, Olivier's big patch looks good.
... and then nothing happened. Ping? The only code remark was a
whitespace issue on one line :-)
For
On Tue, Jul 10, 2012 at 03:51:22PM +0200, Marek Ol??ák wrote:
I just wanted to tell you Stephane's change cannot work and it even
has no effect at the moment. The native integer support is global in
core Mesa. It's because integer uniforms are converted to floats based
on the global
On Tue, Jul 10, 2012 at 09:19:05AM -0700, Stéphane Marchesin wrote:
There is also option 3): revert the two patches causing the regression.
And then you'll have this problem again as soon as you want llvmpipe
to reach GL 3.00+/GLSL 1.30+. So why not find a definitive solution
now?
Previous
On Wed, Jul 11, 2012 at 12:51:32PM +0200, Marek Ol??ák wrote:
Dude, you should really learn GLSL. The idea to emulate integers is
even older than the GLSL itself. It first appeared in HLSL and NVIDIA
Cg on hardware that wasn't even GL2-capable.
I'm learning 3.30+, which is what I consider
On Wed, Jul 11, 2012 at 02:19:02PM +0200, Marek Ol??ák wrote:
On Wed, Jul 11, 2012 at 1:09 PM, Jose Fonseca jfons...@vmware.com wrote:
My current plan is to:
- make it clear that INSTANCEID/VERTEXID always means integer
- require PIPE_SHADER_CAP_INTEGERS to be advertise in the vertex shader
On Wed, Jul 04, 2012 at 01:59:44PM +0200, Marek Ol??ák wrote:
Please disregard patch 1 and 2. It wouldn't work.
What's wrong with them?
I still plan to commit patch 3.
Patch 3 makes sense. I probably should have done it like that in the
first place (learned a lot since :-).
OG.
On Tue, Jul 03, 2012 at 12:39:47PM -0700, Jose Fonseca wrote:
Note that all registers are stored as floats (for convenience, and
because LLVM has no unions), so integers are bitcasted into floats
while storing/loading. And I'm not sure if your patch would break
that.
I did test the patch
On Mon, Jul 02, 2012 at 06:44:37AM -0700, Jose Fonseca wrote:
But I think that this fix is too ad-hoc, and I suspect it may
introduce other regressions.
If I understood the problem correctly, the issue here is that some
drivers want system values in floats, others want in
integers. Right?
Hi,
This is the first part of the fixes I've done to make my gm45 work
correctly w.r.t clipping and interpolation. There's a fair chance
they work for everything gen 4/5, but I have no way to be sure.
[PATCH 1/5] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
[PATCH 2/5] intel gen4-5: Compute
at you. The code instead picks whatever slot
was written to by the vertex shader. That makes most of the generated
piglit tests useless to test the backface selection though.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 18 +-
src/mesa
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c| 82 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965
would require putting
brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
thing, but it could have unexpected consequences, so it's better be
done independently in any case.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |2
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c | 10 -
src/mesa/drivers/dri/i965/brw_clip.h |6 +--
src/mesa
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri/i965/brw_clip_util.c | 133
On Fri, Jun 29, 2012 at 12:52:06PM -0700, Stéphane Marchesin wrote:
Yeah, but my question was more high level, whether the vertex id
support required the previous refactor. It looks like it does though,
and I don't want to untangle, so I'll revert both 3/4 and 4/4.
You realize that will
and
shaken for bugs (subsystem trees, -next, akp patch tree, etc). I'm
not sure Mesa can afford it.
That said, try this.
commit 56555c58d7f16c8d619c21feb23096155e2fb505
Author: Olivier Galibert galib...@pobox.com
Date: Sat Jun 30 00:41:20 2012 +0200
lp_bld_tgsi_soa: Fix conversion of system
On Wed, Jun 27, 2012 at 03:17:05AM -0700, Jose Fonseca wrote:
I took a look at the results, and it seems to me that bri linear
code is fine -- the test is merely too strict, and doesnot forgive
the gravitation towards integer lod that brilinear implements.
Yes, the current code maps [0,.25] to
On Mon, Jun 25, 2012 at 03:16:35PM -0700, Jose Fonseca wrote:
Indeed lp_build_brilinear_lod is not faster than
lp_build_ifloor_fract, but brilinear is faster, not because log is a
faster approximation, but because it increases the odds that fract
part is zero, which means that we can sample
On Tue, Jun 26, 2012 at 02:46:01PM -0600, Brian Paul wrote:
As with the previous commit for softpipe.
v2: remove 'default' case to get compile-time warning
---
src/gallium/drivers/llvmpipe/lp_screen.c | 52 +++--
1 files changed, 48 insertions(+), 4 deletions(-)
, but
they mostly have their own extension anyway. And the overall picture
ain't so bad.
Signed-off-by: Olivier Galibert galib...@pobox.com
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 40037a5..5eb826e 100644
--- a/src/gallium/drivers/llvmpipe
On Fri, May 18, 2012 at 08:55:39AM -0600, Brian Paul wrote:
In any case, I think this function could be moved into u_math.c so it
could be used elsewhere.
[...]
I was looking at the GLSL round() and roundEven() functions. The GLSL
spec says round() can use whatever method is fastest. But
It can be argued it makes to sense to advertise an integer system
variable in GLSL levels where integers aren't handled.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
I don't really know if that's a patch we want, but otoh having
gl_InstanceIDARB being a different type depending
Hi,
I've just finished two piglit runs of llvmpipe with glsl 1.40 and gl
3.1 forced on, one with LLVM 2.9, the other with 3.1.
The least we can say is that there aren't many differences.
- fp-indirections2, didn't have the patience to wait to see whether it
would eventually stop. Looks
The type is the destination type (i.e. float vector) and not the
source type. Fixes piglit fs-{in,de}crement-uint.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src
Brilinear folding must only be used if the log2 was computed with
brilinear too. Fixes fs-textureLod-miplevels.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/gallivm/lp_bld_sample.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium
On Mon, Jun 25, 2012 at 05:34:25AM -0700, Jose Fonseca wrote:
- Original Message -
That capability requires integer handling and that's not yet active,
ending with a failure in draw-non-instanced unless you force it on.
See bug 51366.
Frankly, I'd rather have that patch
On Mon, Jun 25, 2012 at 07:31:20PM +0100, Roland Scheidegger wrote:
Does this fix the test because lp_build_brilinear_lod produces bogus
values in this case or just because the test is strict about such
filtering optimizations? In the latter case I'm not sure I really see
much point.
On Mon, Jun 25, 2012 at 11:40:08AM -0700, Jose Fonseca wrote:
My thoughts too.
Brilinear filtering provides a significant boost, and I don't see why skip
the optimization for explicit lod over implicit lods.
Warning: code misread :-)
Explicit lod does not need brilinear filtering because
That old bug was hidden but the clipper always interpolating in 3d
space no matter what it should have been doing. Now that the
interpolation has been fixed, the bug shows up.
Fixes bugzilla 51364.
Signed-off-by: Olivier Galibert galib...@pobox.com
diff --git a/src/mesa/state_tracker
On Wed, Jun 20, 2012 at 01:44:14PM +0100, Roland Scheidegger wrote:
A lot of code I just glossed over it, but seems to look ok other than
the (performance) implications this might have.
Actually whether there's a performance implication is not obvious. In
practice the code just kicks the
On Thu, Jun 21, 2012 at 11:19:39AM +0200, Michel Dänzer wrote:
On Die, 2012-06-19 at 17:18 -0700, Kenneth Graunke wrote:
Also, distribute the appropriate emacs and vim settings to indent things
correctly.
In any case, please do this *before* any kind of cleanup.
(global-set-key [(control
On Thu, Jun 21, 2012 at 11:58:57AM +0200, Michel Dänzer wrote:
On Don, 2012-06-21 at 11:38 +0200, Olivier Galibert wrote:
On Thu, Jun 21, 2012 at 11:19:39AM +0200, Michel Dänzer wrote:
On Die, 2012-06-19 at 17:18 -0700, Kenneth Graunke wrote:
Also, distribute the appropriate emacs
edc7b26b03c0393582ff5ec8c963207c7553850a
Author: Olivier Galibert galib...@pobox.com
Date: Thu Jun 21 19:37:11 2012 +0200
clip_init_state: Handle the case when there isn't a fragment shader.
Signed-off-by: Olivier Galibert galib...@pobox.com
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium
Hi,
They've been revieved, they've been changed when requested :-)
Best,
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Brian Paul bri...@vmware.com
---
src/gallium/drivers/softpipe/sp_tex_sample.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe
.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Brian Paul bri...@vmware.com
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 144 +--
1 file changed, 113 insertions(+), 31 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Brian Paul bri...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 32 ++-
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 13 +++--
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 11
for now, as the previous code)
- correctly handle the expected type in emit_fetch_system_value
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Brian Paul bri...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
On Tue, Jun 19, 2012 at 02:46:35PM -0700, Jose Fonseca wrote:
Could you give more background on why is this necessary?
This will make software renderering slower, so I'd really like to avoid it on
llvmpipe if at all possible.
Well, given the existence of textureLod and textureGrad every
Hi all,
I'm getting a little lost in all the interactions between the
different parts of the GL standards and what I understand of the
expectations when it comes to MSAA. It would be nice if I could have
some clarifications.
I'll start with what I think I understand (and please correct me
On Tue, Jun 05, 2012 at 04:51:54PM -0700, Paul Berry wrote:
The best idea I've got so far would be a shader_runner test with a fragment
shader that computes dFdx(asin(x)), compares it to the theoretical closed
form derivative of asin(x) (which is 1/sqrt(1-x^2)), and draws red pixels
if the
On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
In single precision, 1.5707963 becomes 1.5707962513 which is too
small. However, 1.5707964 becomes 1.5707963705 which is just right.
The value 1.5707964 is already used in asin.ir.
On Mon, Jun 04, 2012 at 03:23:34PM -0700, Paul Berry wrote:
I'm not even kidding--I love this
stuff and I'm jealous that I don't have time to work on it right now
Do you have a favorite method for Vandermonde matrix inversion?
OG.
___
mesa-dev
Hi,
The following pair of patches add gl_VertexID support to llvmpipe.
They also simplify the system value fetch methodology (hopefully
generating better code in the end) and fixes some issues with
gl_InstanceID. The I don't understand how it could ever work kind
of issues, converting from
for now, as the previous code)
- correctly handle the expected type in emit_fetch_system_value
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 11 +--
src/gallium/auxiliary
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 --
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |3 ++-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |7 +++
src/gallium/drivers/llvmpipe/lp_state_fs.c
Hi,
The following pair of patches add gl_VertexID support to llvmpipe.
They also simplify the system value fetch methodology (hopefully
generating better code in the end) and fixes some issues with
gl_InstanceID. The I don't understand how it could ever work kind
of issues, converting from
for now, as the previous code)
- correctly handle the expected type in emit_fetch_system_value
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 11 +--
src/gallium/auxiliary
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 --
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |3 ++-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |7 +++
src/gallium/drivers/llvmpipe/lp_state_fs.c
On Wed, May 30, 2012 at 11:38:06AM +0100, Dave Airlie wrote:
Have you checked llvmpipe with this? since it might need changes to go
along with this.
It didn't look like llvmpipe was going anywhere near that. OTOH, a
piglit run of llvmpipe I just did on the place gave me zero errors in
that
On Wed, May 30, 2012 at 07:32:16AM -0600, Brian Paul wrote:
All the code above could use more comments. Otherwise it takes some
pretty intense studying to understand what's going on there.
Ok, I'll take that into account (and the previous comments too).
OG.
.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 144 +--
1 file changed, 113 insertions(+), 31 deletions(-)
I've kicked the f_nopersp computation up so that it's always
evaluated, and I've added a bunch of comments
1 - 100 of 165 matches
Mail list logo
