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 wrote:
> Walk the array of cbufs backwa
On 05/11/14 20:39, Eric Anholt wrote:
> Marek Olšák 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 classic dr
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.
A
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 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 10.
On Fri, Nov 14, 2014 at 9:14 AM, Emil Velikov 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 proposed changes are
On Fri, Nov 14, 2014 at 9:39 AM, 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 10.
On 14 November 2014 16:21, Ilia Mirkin 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.
___
mesa-dev
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.
Maint
On 11/14/2014 04:31 PM, Henri Verbeet wrote:
On 14 November 2014 16:21, Ilia Mirkin 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.
At this mome
On Fri, Nov 14, 2014 at 10:31 AM, Henri Verbeet wrote:
> On 14 November 2014 16:21, Ilia Mirkin 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'
> 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
Sent: 12 November 2014 18:16
To: Jose Fons
FYI, I've pushed these patches.
Marek
On Fri, Nov 14, 2014 at 3:51 PM, Jose Fonseca 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 of
> GLX/WGL_E
On 14/11/14 15:07, Erik Faye-Lund wrote:
> On Fri, Nov 14, 2014 at 3:39 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.
On 14 November 2014 16:36, Ilia Mirkin 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 (d3d9) devices, st
On 14/11/14 15:24, Ilia Mirkin wrote:
> On Fri, Nov 14, 2014 at 9:39 AM, 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
On Fri, Nov 14, 2014 at 11:15 AM, Henri Verbeet wrote:
> On 14 November 2014 16:36, Ilia Mirkin 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-
Hi,
On 14 November 2014 15:07, Erik Faye-Lund wrote:
> On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov
> 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 days,
> > and based on it I'll tag the fir
> [...] 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 wrote:
> On 14/11/14 15:24, Ilia Mirkin wrote:
>> On Fri, Nov 14, 2014 at 9:39 AM, 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 develo
On 14/11/2014 17:15, Henri Verbeet wrote :
On 14 November 2014 16:36, Ilia Mirkin 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. [.
From: José Fonseca
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
b/src/gallium/state_trackers/glx/xlib/glx_api.c
ind
From: José Fonseca
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 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 otherwise you'd
On 14 November 2014 17:42, Jose Fonseca 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 has always
On Thu, Nov 13, 2014 at 07:05:51PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> 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 drm_mode_create_dum
On 14 November 2014 17:52, Axel Davy 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 backbuffer asked by t
Le 14/11/2014 18:40, Henri Verbeet a écrit :
On 14 November 2014 17:52, Axel Davy 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:
. Resp
Signed-off-by: Aaron Watry
CC: Ilia Mirkin
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
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c
[changing subjects not to derail original discussion]
On Fri, Nov 14, 2014 at 12:25 PM, Henri Verbeet wrote:
>> I strongly doubt that the performance increases are due
>> to better d3d9 bytecode -> TGSI conversion than -> glsl -> tgsi
>> conversion -- most serious backends (r600, radeonsi, nouvea
On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry wrote:
> Signed-off-by: Aaron Watry
> CC: Ilia Mirkin
>
> 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
Just one minor comment below. Otherwise looks fine.
Reviewed-by: Brian Paul
On 11/14/2014 10:20 AM, jfons...@vmware.com wrote:
From: José Fonseca
Derived from st/glx's GLX_EXT_create_context_es/es2_profile implementation.
Tested with an OpenGL ES 2.0 ApiTrace.
---
src/gallium/state_track
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 a/
On Fri, Nov 14, 2014 at 12:04 PM, Ilia Mirkin wrote:
> On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry wrote:
>> Signed-off-by: Aaron Watry
>> CC: Ilia Mirkin
>>
>> v4: Call dlerror() twice instead of freeing glibc's memory.
>> Prevents issues on C Libraries that don't malloc the error string
On Fri, Nov 14, 2014 at 1:31 PM, Aaron Watry wrote:
> On Fri, Nov 14, 2014 at 12:04 PM, Ilia Mirkin wrote:
>> On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry wrote:
>>> Signed-off-by: Aaron Watry
>>> CC: Ilia Mirkin
>>>
>>> v4: Call dlerror() twice instead of freeing glibc's memory.
>>> Prev
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 m
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
> ...
>
On 14 November 2014 18:50, Ilia Mirkin 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 take care of it, a
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 wrote:
> Fixes build process failure when providing -mno-sse4.1 CFLAGS:
> vbo_exec_array.c:(.text+0x9bb): undefine
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 wro
On Thu, Nov 13, 2014 at 11:22 PM, Kenneth Graunke wrote:
> Saves a tiny bit of CPU overhead.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 +-
> src/mesa/drivers/dri/i965/gen6_vs_state.c| 12 ++--
> 2 files changed, 11 in
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
LIB
> 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 TG
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 actual
On Fri, Nov 14, 2014 at 1:38 PM, Henri Verbeet wrote:
> On 14 November 2014 18:50, Ilia Mirkin 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
Am 14.11.2014 um 19:38 schrieb Henri Verbeet:
> On 14 November 2014 18:50, Ilia Mirkin 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 simpl
> 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 leas
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
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 src/mesa/m
On Fri, Nov 14, 2014 at 9:39 AM, 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 10.
Reviewed-by: Grigori Goronzy
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
>
> Using the asynchronous DMA engine
On 14 November 2014 20:41, Roland Scheidegger 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.)
> I suspect th
From: José Fonseca
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, wrote:
> From: José Fonseca
>
> 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 +++--
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 inte
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 performan
All four Tested-by: Nick Sarnie using Gallium
Nine.
On Sun, Nov 9, 2014 at 6:08 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/auxiliary/tgsi/tgsi_ureg.c| 153
> ++
> src/gallium/auxiliary/tgsi/tgsi_ureg.h| 35 +-
> src/gallium/au
Tested-by: Nick Sarnie using Gallium Nine.
On Sun, Nov 9, 2014 at 6:09 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Required by Nine.
> ---
> src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
> src/gallium/drivers/radeonsi/si_state.c | 1 -
> src/gallium/drivers/radeonsi/si_state_
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]
http://lists.fre
On 15 November 2014 03:25, Henri Verbeet wrote:
> On 14 November 2014 17:37, Ilia Mirkin 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
For patches 1, 5, 7:
Reviewed-by: Marek Olšák
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 wrote:
> v2: moved in in same order as in p_shader_tokens (thanks Brian)
> Signed-off-by: David H
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 r
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
> ---
> src/mesa/drivers/dri/i965/brw_fs.
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
> ---
> src/mesa/drivers/dri/i965/brw_fs.
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
