> XXX: Should we nuke gallivm/f.cpp ? It seems that no-one is using it.
No, it's important to keep this file.
It's not meant to be compiled into mesa. It is meant to be used out of tree for
computing polynomial coefficients as explained in the comments.
We already had to review the coeffs once
https://bugs.freedesktop.org/show_bug.cgi?id=86330
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Dear Dave,
Dave Airlie wrote on 16.11.2014 06:20:
> no idea but I'm picking Emil as the culprit!
I've seen the same failure, but a more recent LLVM 3.6 fixed it for me. I can
report LLVM SVN r222082 as working.
Cheers,
Kai
signature.asc
Description: OpenPGP digital signature
__
Kai Wasserbäch wrote on 16.11.2014 11:49:
> Dear Dave,
> Dave Airlie wrote on 16.11.2014 06:20:
>> no idea but I'm picking Emil as the culprit!
>
> I've seen the same failure, but a more recent LLVM 3.6 fixed it for me. I can
> report LLVM SVN r222082 as working.
Nah, sorry. I was wrong. You've s
On Saturday, November 15, 2014 10:42:47 PM Gustaw Smolarczyk wrote:
> Hello all,
>
> I would like to ask what is the status of DSA (direct state access)
> extensions in mesa. If I understand correctly, there was a GSoC
> project by Dylan Noblesmith and there currently is a dsa branch in
> mesa rep
Acked by me.
I didn't review the state tracker code, but at least I didn't notice anything
wrong with the changes to the auxiliary modules, and I don't obecjt having this
merged back in now that it is being actively maintained,
Jose
From: mesa-dev on
Looks good. Thanks.
Jose
From: mesa-dev on behalf of Vinson Lee
Sent: 15 November 2014 22:16
To: mesa-dev@lists.freedesktop.org
Cc: 10.4
Subject: [Mesa-dev] [PATCH] scons: Require glproto >= 1.4.13 for X11.
GLXBadProfileARB and X_GLXCreateContextAtrribs
> Fun fact -- llvmpipe also needs this.
I think this is because this functionality was developed with D3D10 in mind,
and
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb509647.aspx
states that SV_RenderTargetArrayIndex "an be written from the geometry shader
and read by the pixel s
Hi Jose,
First of all, sorry for breaking Draw yesterday.
On Sun, Nov 16, 2014 at 2:57 PM, Jose Fonseca wrote:
>> Fun fact -- llvmpipe also needs this.
>
> I think this is because this functionality was developed with D3D10 in mind,
> and
>
> http://msdn.microsoft.com/en-gb/library/windows/desk
Ok. It would be helpful to note the progress in the docs/GL3.txt file.
The overview of ARB_dsa summarizes the difference between it and the
EXT variant, so I understand the undesirability of implementing
EXT_dsa.
Gustaw
2014-11-16 12:07 GMT+01:00 Kenneth Graunke :
> On Saturday, November 15, 201
Hello once again,
This time, I would like to ask about the shader subroutine extension.
I believe this extension is not very popular, but is still needed for
GL4 compliance.
What is the reason for its unpopularity?
Is it because one needs to reset subroutine uniform values after any glUse*?
Or it
On 16/11/14 05:20, Dave Airlie wrote:
> no idea but I'm picking Emil as the culprit!
>
Yes that was me. Apologies for the breakage Dave, it seems that rebasing
that commit did cause some fun.
Afaics Jose (big thanks) has fixed it already, but if there is anything
else please let me know.
-Emil
_
On 16/11/14 10:07, Jose Fonseca wrote:
>> XXX: Should we nuke gallivm/f.cpp ? It seems that no-one is using it.
>
> No, it's important to keep this file.
>
> It's not meant to be compiled into mesa. It is meant to be used out of tree
> for computing polynomial coefficients as explained in the co
On 13/11/14 11:10, Jose Fonseca wrote:
> Hi Tom,
>
> That's peculiar. It looks like pthreads got into a weird state somehow.
> Don't precisely understand how though. Maybe there's a race inside
> pipe_semaphore_signal() with the destruction of the semaphore.
>
> I think the best thing for now
Hi Gustaw,
My understanding is that it's a combination of the awkward API, and
dubious value. It's certainly not something that everyone is screaming
for.
As far as mesa's implementation goes, I started on the parser changes
and tests a while ago; I believe Ian was going to pick it up. I'm not
su
Hi,
I am currently working on implementing the extension
*GL_ARB_shader_atomic_counters*. I have a few questions.
1. What does CSO and cso_context for? Why do we have to bind with it?
2. There is a file called st_atom_constbuf.c/.h in mesa/state_tracker. As
counter buffers are different from cons
Cosmetics? Intended?
$ LC_ALL=C git status
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
nothing to commit, working directory clean
$ LC_ALL=C git checkout -b 10.4 origin/10.4
Branch 10.4 set up to track remote branch 10.4 from origin.
Switched to a new branch '10.4'
$ L
Hi,
I appreciate the work you've done to make the GL3.txt file much more
readable.
To improve it even more I would like to be able to click on the
extensions names and see the whole text of the extension from the
registry on opengl.org. I think it would help to understand why
something isn't imple
Signed-off-by: Guo Yejun
---
xf86drm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index d900b4b..40997d2 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -553,9 +553,8 @@ static int drmOpenByName(const char *name)
drmFreeVersion(ver
The spec states that pow is undefined for x < 0.
Just set the range to correspond to a constant 0
if this is the case.
---
src/glsl/opt_minmax.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 9852dd9..ad8c88a 100644
--- a/
Also handle undefined behaviour for sqrt(x) where x < 0
and rsq(x) where x <= 0.
This gives us some reduction in instruction count on some
Dungeon Defenders shaders as they are doing: max(exp(x), 0)
---
src/glsl/opt_minmax.cpp | 17 +
1 file changed, 17 insertions(+)
diff --git a
They are bound between -1 and 1, so report that.
---
src/glsl/opt_minmax.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 111d183..341006e 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -271,6 +271
The spec states that log / log2 of x <= 0 is undefined.
Just set the range to 0 if this is the case.
---
src/glsl/opt_minmax.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index ad8c88a..0638a12 100644
--- a/src/glsl/opt_mi
---
src/glsl/opt_minmax.cpp | 33 +
1 file changed, 33 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 9d300d3..49a816e 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -344,6 +344,39 @@ get_range(ir_rvalue *r
---
src/glsl/opt_minmax.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 49a816e..466db8c 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -293,6 +293,14 @@ get_range(ir_rvalue *rval)
high = la
---
src/glsl/opt_minmax.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 1aa4611..9852dd9 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -326,6 +326,15 @@ get_range(ir_rvalue *rval)
// We can g
This will make expansion easier and less cluttered.
---
src/glsl/opt_minmax.cpp | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 89970d5..111d183 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_
We can use the intersection function to reduce the range
even further if the operand has bounds between 0.0 and 1.0.
---
src/glsl/opt_minmax.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 341006e..b925aaa 100644
--- a/src/glsl
---
src/glsl/opt_minmax.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 0638a12..9d300d3 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -335,6 +335,15 @@ get_range(ir_rvalue *rval)
high = a
---
src/glsl/opt_minmax.cpp | 24
1 file changed, 24 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 466db8c..96b1e07 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -301,6 +301,30 @@ get_range(ir_rvalue *rval)
This allows opt_algebraic to resolve open-coded
saturates into ir_unop_saturate before we potentially
mess it up by removing the min or max in min/max-pruning.
Since we are now emitting more free saturates on i965
this gives us some decrease in instructions.
total instructions in shared programs:
This will allow for less code duplication.
I'll be using this in opt_minmax in the coming commits.
---
src/glsl/ir_constant_util.h | 122
src/glsl/opt_algebraic.cpp | 88 +---
src/glsl/opt_minmax.cpp | 17 +-
3 fil
---
src/glsl/opt_minmax.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index b925aaa..a48d4d8 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -283,6 +283,16 @@ get_range(ir_rvalue *rval)
r1 = get
This allows the backend to decide if it does not
want saturates, or if it wants to combine min/max
together by itself.
Usefull for drivers that implement saturate with min/max
as it can allow for some optimizations by min/max-pruning.
Drivers like freedreno and vc4 will benefit.
---
I have not mad
My exams are aproaching fast, so I thought I'd put this second
version of the series onto the list.
This hopefully addresses the issues with the first version.
I have tested that I don't cause regressions with Brutal Legend,
and that I maintain the improvement in Dungeon Defenders.
These are the o
Add functions:
is_greater_than_one
is_less_than_zero
Add variations like greater_than_or_equal_zero.
---
This is not ideal computation-wise, as we are doing two
iterations instead of one. The question is wether or not
the extra code is worth the duplicaton.
---
src/glsl/ir_constant_util.h | 5
The direction I went in was by adapting the shader resources interface
for this. I believe it will be possible to use for
shader_image_load_store as well.
See https://github.com/imirkin/mesa/commits/atomic
I believe that makes a lot more sense than creating a special counter
buffer type only to b
On Sun, Nov 16, 2014 at 5:51 PM, Thomas Helland
wrote:
> This allows the backend to decide if it does not
> want saturates, or if it wants to combine min/max
> together by itself.
>
> Usefull for drivers that implement saturate with min/max
> as it can allow for some optimizations by min/max-pruni
On Sun, Nov 16, 2014 at 7:33 PM, Matt Turner wrote:
> On Sun, Nov 16, 2014 at 5:51 PM, Thomas Helland
> wrote:
>> This allows the backend to decide if it does not
>> want saturates, or if it wants to combine min/max
>> together by itself.
>>
>> Usefull for drivers that implement saturate with min
On Sun, Nov 16, 2014 at 5:51 PM, Thomas Helland
wrote:
> Add functions:
> is_greater_than_one
> is_less_than_zero
>
> Add variations like greater_than_or_equal_zero.
> ---
> This is not ideal computation-wise, as we are doing two
> iterations instead of one. The question is wether or not
> the
Hi,
On Sunday, November 16, 2014, Ilia Mirkin wrote:
> The direction I went in was by adapting the shader resources interface
> for this. I believe it will be possible to use for
> shader_image_load_store as well.
>
I asked some questions on mailing list about the implementation. I took the
sam
On 14.11.2014 19:37, Marek Olšák wrote:
> surface_destroy should never be called directly, because surfaces have
> a reference counter. For unreferencing resources, use
> pipe_surface_reference(&pointer, NULL). It will call surface_destroy
> if needed.
Indeed, if this was the right place for this,
42 matches
Mail list logo
