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.
Marek
On Fri, Nov 14, 2014 at 12:43 AM, Aaron Watry awa...@gmail.com wrote:
Walk the array
On 05/11/14 20:39, Eric Anholt wrote:
Marek Olšák mar...@gmail.com writes:
Hi everybody,
I'm about to address this long-standing issue: The EGL state tracker is
redundant. It duplicates what st/dri does and it also duplicates what
the common loader egl_dri2 does, which is used by all
On 02/11/14 18:27, David Heidelberg wrote:
Hello everyone!
First I'd like thank you for great feedback.
Sending third Gallium Nine merge request. We reduced number of commits
to necessary minimum. I hope all proposed changes are incorporated in v3.
Thank you
Gents,
Can we get an
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
...
mesa 10.4.0 - 10.4.0
mesa 10.4.1-rc1 - 10.4.0.901
... you get the idea.
https://bugs.freedesktop.org/show_bug.cgi?id=84724
yas...@windowslive.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
I googled and tried to find any evidence of anybody using Mesa's EGL on Windows
over the last years but couldn't.
Furthermore since my last reply on this thread I become quite fond of
GLX/WGL_EXT_create_context_es/es2_profile extensions. They seem a much easier
mechanism to use and test OpenGL
On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
On Fri, Nov 14, 2014 at 9:14 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 02/11/14 18:27, David Heidelberg wrote:
Hello everyone!
First I'd like thank you for great feedback.
Sending third Gallium Nine merge request. We reduced number of commits
to necessary minimum. I hope all
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote:
To the best of my knowledge, wine has no intent on merging anything
related to nine/st.
That's a bit broader than I'd put it, but yes, in it's current form
this is not something we'd merge.
We plan make automatized tests based on apitrace (documented how to use
it with wine just few days ago) of used games. Also we have wine tests.
About merging to wine, it needs more work to be done, but in generally,
we have packages for wide range of distributions, inlucluding livecd etc.
On 11/14/2014 04:31 PM, Henri Verbeet wrote:
On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote:
To the best of my knowledge, wine has no intent on merging anything
related to nine/st.
That's a bit broader than I'd put it, but yes, in it's current form
this is not something
On Fri, Nov 14, 2014 at 10:31 AM, Henri Verbeet hverb...@gmail.com wrote:
On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote:
To the best of my knowledge, wine has no intent on merging anything
related to nine/st.
That's a bit broader than I'd put it, but yes, in it's current
It looks like you're missing minor_ver checking here? For instance, 2.99
isn't a valid GLES version.
I think these things are already validated on GLX/eGL, but I confess I'm not
100% sure.
Jose
From: Daniel Stone dan...@fooishbar.org
Sent: 12 November 2014
FYI, I've pushed these patches.
Marek
On Fri, Nov 14, 2014 at 3:51 PM, Jose Fonseca jfons...@vmware.com wrote:
I googled and tried to find any evidence of anybody using Mesa's EGL on
Windows over the last years but couldn't.
Furthermore since my last reply on this thread I become quite fond
On 14/11/14 15:07, Erik Faye-Lund wrote:
On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 -
On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote:
Is there a different form that you believe would be more likely to be merged?
The main issue is probably that we'd really like to avoid having two
parallel implementations of the high-level d3d9 stuff. I.e., anything
dealing with
On 14/11/14 15:24, Ilia Mirkin wrote:
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 -
On Fri, Nov 14, 2014 at 11:15 AM, Henri Verbeet hverb...@gmail.com wrote:
On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote:
Is there a different form that you believe would be more likely to be merged?
The main issue is probably that we'd really like to avoid having two
Hi,
On 14 November 2014 15:07, Erik Faye-Lund kusmab...@gmail.com wrote:
On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Are there any objections if I move to the above format starting with
mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3
[...] We'd
potentially be open to using something closer to the Gallium interface
instead of OpenGL on the backend in wined3d. In that scenario wined3d
would essentially be the statetracker. The main issue with that
approach has always been that the Gallium statetracker/driver
interface
On Fri, Nov 14, 2014 at 11:17 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 14/11/14 15:24, Ilia Mirkin wrote:
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more
On 14/11/2014 17:15, Henri Verbeet wrote :
On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote:
Is there a different form that you believe would be more likely to be merged?
The main issue is probably that we'd really like to avoid having two
parallel implementations of the
From: José Fonseca jfons...@vmware.com
Tested with piglit glx tests.
---
src/gallium/state_trackers/glx/xlib/glx_api.c | 125 ++
1 file changed, 109 insertions(+), 16 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
From: José Fonseca jfons...@vmware.com
Derived from st/glx's GLX_EXT_create_context_es/es2_profile implementation.
Tested with an OpenGL ES 2.0 ApiTrace.
---
src/gallium/state_trackers/wgl/stw_context.c | 74 +-
src/gallium/state_trackers/wgl/stw_ext_context.c | 65
On 14 November 2014 17:37, Ilia Mirkin imir...@alum.mit.edu wrote:
Dave Airlie's virgl work is creating a gallium driver which actually
uses OpenGL for hardware. I'm not sure how far he is, but I believe
he has enough for GL3. This could be a way forward towards *only*
using gallium (since
On 14 November 2014 17:42, Jose Fonseca jfons...@vmware.com wrote:
[...] We'd
potentially be open to using something closer to the Gallium interface
instead of OpenGL on the backend in wined3d. In that scenario wined3d
would essentially be the statetracker. The main issue with that
approach
On Thu, Nov 13, 2014 at 07:05:51PM +0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously
specified, which has the effect that some kernel drivers do not consider
the .pitch and .size fields of struct
On 14 November 2014 17:52, Axel Davy axel.d...@ens.fr wrote:
Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL.
As for me, I contributed only since a few months ago, and was able to
implement a lot of things quite easily, for exemple:
. Respect the number of
Le 14/11/2014 18:40, Henri Verbeet a écrit :
On 14 November 2014 17:52, Axel Davy axel.d...@ens.fr wrote:
Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL.
As for me, I contributed only since a few months ago, and was able to
implement a lot of things quite easily, for
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v4: Call dlerror() twice instead of freeing glibc's memory.
Prevents issues on C Libraries that don't malloc the error string.
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
[changing subjects not to derail original discussion]
On Fri, Nov 14, 2014 at 12:25 PM, Henri Verbeet hverb...@gmail.com wrote:
I strongly doubt that the performance increases are due
to better d3d9 bytecode - TGSI conversion than - glsl - tgsi
conversion -- most serious backends (r600,
On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry awa...@gmail.com wrote:
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v4: Call dlerror() twice instead of freeing glibc's memory.
Prevents issues on C Libraries that don't malloc the error string.
v3: Switch
Just one minor comment below. Otherwise looks fine.
Reviewed-by: Brian Paul bri...@vmware.com
On 11/14/2014 10:20 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Derived from st/glx's GLX_EXT_create_context_es/es2_profile implementation.
Tested with an OpenGL ES 2.0
Fixes build process failure when providing -mno-sse4.1 CFLAGS:
vbo_exec_array.c:(.text+0x9bb): undefined reference to
`_mesa_uint_array_min_max'
Similar bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71547
---
src/mesa/vbo/vbo_exec_array.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Fri, Nov 14, 2014 at 12:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry awa...@gmail.com wrote:
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v4: Call dlerror() twice instead of freeing glibc's memory.
On Fri, Nov 14, 2014 at 1:31 PM, Aaron Watry awa...@gmail.com wrote:
On Fri, Nov 14, 2014 at 12:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry awa...@gmail.com wrote:
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
On 11/10/2014 04:28 AM, Emil Velikov wrote:
On 09/11/14 04:37, Siavash Eliasi wrote:
On 11/08/2014 09:55 PM, Emil Velikov wrote:
[...]
Can you confirm that it does not cause issues with interesting setups
such as https://bugs.freedesktop.org/show_bug.cgi?id=71547
Challenge accepted! What my
On Friday, November 14, 2014 02:39:24 PM Emil Velikov wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
...
mesa
On 14 November 2014 18:50, Ilia Mirkin imir...@alum.mit.edu wrote:
I can't speak for the radeon guys, but I know I sure would love to see
any reports of poor code being generated by nouveau in response to
legitimate-seeming TGSI (or GLSL). In some cases, a simple
optimization can be added to
And disables the optimization unless you're building with a -march
that has sse4.1... thus defeating the purpose of doing it this way.
On Fri, Nov 14, 2014 at 1:23 PM, Siavash Eliasi siavashser...@gmail.com wrote:
Fixes build process failure when providing -mno-sse4.1 CFLAGS:
You are right. Any suggestions on how to fix this build failure?
On 11/14/2014 10:10 PM, Ilia Mirkin wrote:
And disables the optimization unless you're building with a -march
that has sse4.1... thus defeating the purpose of doing it this way.
On Fri, Nov 14, 2014 at 1:23 PM, Siavash Eliasi
On Thu, Nov 13, 2014 at 11:22 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Saves a tiny bit of CPU overhead.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 +-
src/mesa/drivers/dri/i965/gen6_vs_state.c| 12
Thanks for the review.
I'd probably put the version checking logic into a helper function, but
not a big deal.
Good idea. I'll do that in a follow on patch.
It looks like we're not doing as extensive version checking in the glx code.
It's actually the same amount of checking. But on GLX we
This issue isn't totally just that. LIBGL_ALWAYS_SOFTWARE=true mode does use
LLVM doesn't it? And I find profiling information trailing from a perf-foo.map
file that seems to correspond to JITted code. So, I think this is still valid
for LIBGL_ALWAYS_SOFTWARE=true mode. I was mistaken for unset
And I find profiling information trailing from a perf-foo.map file that seems
to correspond to JITted code.
Yep. That sounds like llmvpipe. See http://mesa3d.org/llvmpipe.html for details.
But note that have source lines for jit code is hard:
- Some of the LLVM IR we generate comes from TGSI
On 11/14/2014 12:13 PM, Jose Fonseca wrote:
Thanks for the review.
I'd probably put the version checking logic into a helper function, but
not a big deal.
Good idea. I'll do that in a follow on patch.
It looks like we're not doing as extensive version checking in the glx code.
It's
On Fri, Nov 14, 2014 at 1:38 PM, Henri Verbeet hverb...@gmail.com wrote:
On 14 November 2014 18:50, Ilia Mirkin imir...@alum.mit.edu wrote:
I can't speak for the radeon guys, but I know I sure would love to see
any reports of poor code being generated by nouveau in response to
Am 14.11.2014 um 19:38 schrieb Henri Verbeet:
On 14 November 2014 18:50, Ilia Mirkin imir...@alum.mit.edu wrote:
I can't speak for the radeon guys, but I know I sure would love to see
any reports of poor code being generated by nouveau in response to
legitimate-seeming TGSI (or GLSL). In some
I'd probably put the version checking logic into a helper function, but
not a big deal.
Any suggestion to where put such helper? I'm searching but I'm not confident
where's the best place to put it so that it can be used everywhere.
Would src/mesa/main/version.[ch] be ok? This would at least
Am 14.11.2014 um 15:39 schrieb Emil Velikov:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
...
mesa 10.4.0 - 10.4.0
On 11/14/2014 12:44 PM, Jose Fonseca wrote:
I'd probably put the version checking logic into a helper function, but
not a big deal.
Any suggestion to where put such helper? I'm searching but I'm not confident
where's the best place to put it so that it can be used everywhere.
Would
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
Reviewed-by: Grigori Goronzy g...@chown.ath.cx
I've been using a similar patch to fix stability issues on my machine
for quite a while. Still, it's a pity we have to go that far to get
everything stable again.
On 13.11.2014 07:52, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
On 14 November 2014 20:41, Roland Scheidegger srol...@vmware.com wrote:
That looks quite ok to me. Slightly suboptimal maybe but quite
reasonable - you can't really expect optimal code always. (With the
proposal to nuke cnd from tgsi though you'd just generate the same in
any case probably.)
From: José Fonseca jfons...@vmware.com
As suggested by Brian Paul.
Tested with piglit glx-create-context-invalid-{gl,es}-version.
---
src/gallium/state_trackers/glx/xlib/glx_api.c| 13 +++---
src/gallium/state_trackers/wgl/stw_ext_context.c | 13 +++---
src/mesa/main/version.c
On Fri, Nov 14, 2014 at 3:33 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
As suggested by Brian Paul.
Tested with piglit glx-create-context-invalid-{gl,es}-version.
---
src/gallium/state_trackers/glx/xlib/glx_api.c| 13 +++---
piglit didn't catch this but I just noticed there a bug. It should be:
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 5bdef16..3f08d31 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -472,8 +472,8 @@ _mesa_is_valid_version(int major, int minor)
Is it OK to depend on mesa/main from state trackers? (other than the GL state
tracker, obviously)
No, not in general. It's only because these two state trackers are GL state
trackers, and already depend on mesa/main. (The code src/mesa/state_tracker
doesn't completely hide classic Mesa
While I agree it would be useful to have some D3D features in OpenGL
as extensions to facilitate porting D3D apps to GL, I don't think the
features would be very useful for playing Windows D3D games on Linux,
because I don't believe that translating D3D to GL is even an option
if you want
All four Tested-by: Nick Sarnie commendsar...@gmail.com using Gallium
Nine.
On Sun, Nov 9, 2014 at 6:08 PM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c| 153
++
Tested-by: Nick Sarnie commendsar...@gmail.com using Gallium Nine.
On Sun, Nov 9, 2014 at 6:09 PM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
Required by Nine.
---
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_state.c
On Fri, 2014-11-14 at 22:14 +0330, Siavash Eliasi wrote:
You are right. Any suggestions on how to fix this build failure?
Using this would fix it but the optimisation would be disabled on clang.
Not sure how many people are concerned about this, I don't use clang
myself.
[1]
On 15 November 2014 03:25, Henri Verbeet hverb...@gmail.com wrote:
On 14 November 2014 17:37, Ilia Mirkin imir...@alum.mit.edu wrote:
Dave Airlie's virgl work is creating a gallium driver which actually
uses OpenGL for hardware. I'm not sure how far he is, but I believe
he has enough for GL3.
For patches 1, 5, 7:
Reviewed-by: Marek Olšák marek.ol...@amd.com
BTW, I'd like to have standard Mesa coding style for Nine (indenting
code blocks by 3 spaces).
Marek
On Sun, Nov 2, 2014 at 7:28 PM, David Heidelberg da...@ixit.cz wrote:
v2: moved in in same order as in p_shader_tokens (thanks
On Thursday, November 13, 2014 04:28:06 PM Kristian Høgsberg wrote:
Hi,
Here's v2 of the patch series. It incorportes Matts review comments and
adds a new patch to refactor the way we call fs_generator. The idea is
to get rid of the MESA_SHADER_FS assertion in generate_assembly)() in a
On Thursday, November 13, 2014 04:28:22 PM Kristian Høgsberg wrote:
With everything in place, we can now use the scalar backend compiler for
vertex shaders on BDW+. We make scalar vertex shaders the default on
BDW+ but add a new vec4vs debug option to force the vec4 backend.
No piglit
Hello,
This would be a tough task then. However, all I really want are symbol
names. Having source level debugging would be really cool but not
something I would actually use that much. Even just having a basic
outline of the code would be nice. In fact, I'd imagine it'd be
easiest and best if
However, all I really want are symbol names.
You should have them when running inside perf.
Also for some reason I can't seem to view the assembly of the JITted code.
Did you follow the instructions on http://mesa3d.org/llvmpipe.html and use
bin/perf-annotate-jit script ?
Jose
On Thursday, November 13, 2014 04:28:20 PM Kristian Høgsberg wrote:
This patch uses the previous refactoring to add a new run_vs() method
that generates vertex shader code using the scalar visitor and
optimizer.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
On Thursday, November 13, 2014 04:28:20 PM Kristian Høgsberg wrote:
This patch uses the previous refactoring to add a new run_vs() method
that generates vertex shader code using the scalar visitor and
optimizer.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
On Thursday, November 13, 2014 04:28:16 PM Kristian Høgsberg wrote:
With scalar vertex shader coming up, we're going to reuse brw_vec4_prog_data
in the scalar backend. There's nothing vec4 specific in the struct, it's
instead common state for stages that operate on VUEs. This patch renames
72 matches
Mail list logo
