On Mon, Mar 10, 2014 at 05:36:17PM +0100, Gwenole Beauchesne wrote:
> Fix eglCreateImage() from a packed dma_buf surface with a non-zero offset
> to pixels data. In particular, this fixes support for planar YUV surfaces
> when they are individually mapped on a per-plane basis, i.e. when the
> OES_E
On 03/10/2014 06:05 PM, Chia-I Wu wrote:
> On Fri, Mar 7, 2014 at 6:56 PM, Tapani Pälli wrote:
>> Remove GL_OES_EGL_image_external usage, this would work with current
>> Mesa only if image was created with EGL_EXT_image_dma_buf_import, this
>> makes test work again also if GL_OES_EGL_image_externa
2014-03-10 17:35 GMT+01:00 Gwenole Beauchesne :
> I want to be able to map each individual pane of a planar YUV surface (VA-API)
> as a separate image. Either for customizing the shader code for YUV-to-RGB
> conversion, or for directly exposing a single plane to third-party API like
> OpenCL.
>
> T
On Fre, 2014-03-07 at 19:54 +0100, Marek Olšák wrote:
> From: Marek Olšák
This series is
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
__
Hi Michel, and thanks for the quick feedback.
This is why it's tagged RFC :)
After thinking about it a bit more, I'm not convinced it's the right
thing either.
You're right, the spec is very careful not to say anything about the
memory layout. The 4.2 core profile spec, section 3.9.20 defines
re
On Mon, 2014-03-10 at 10:11 +0100, Christian Zigotzky wrote:
> On 10.03.2014 02:49, Michel Dänzer wrote:
> >
> > Congratulations, you just broke llvmpipe again on big endian systems. ;)
> I'm sorry but Mesa classic works very well on Debian Sid and Lubuntu
> 14.04 with these changes. ;) Why does M
On Mon, 2014-03-10 at 22:20 +1300, Chris Forbes wrote:
> If prefer_no_swizzle is set, try:
> - The exact matching format
> - Formats with the required components in the correct order, plus a junk
> component
How are 'exact matching' and 'correct order' defined? My understanding
of GL internal fo
Am 11.03.2014 01:23, schrieb Ian Romanick:
> I had a pretty similar patch on the top of my pow-optimization branch.
> I also expand x**3 and x**4. I had hoped that would enable some cases
> to expand then merge to MADs. It should also be faster on older GENs
> where POW perf sucks. I didn't send
I had a pretty similar patch on the top of my pow-optimization branch.
I also expand x**3 and x**4. I had hoped that would enable some cases
to expand then merge to MADs. It should also be faster on older GENs
where POW perf sucks. I didn't send it out because I wanted to add a
similar optimizat
On Mon, Mar 10, 2014 at 3:27 PM, Ian Romanick wrote:
> On 03/10/2014 11:19 AM, Anuj Phogat wrote:
> > Currently overlapping locations of input variables are not allowed for
> all
> > the shader types in OpenGL and OpenGL ES.
> >
> >>From OpenGL ES 3.0 spec, page 56:
> >"Binding more than one
total instructions in shared programs: 1667088 -> 1667055 (-0.00%)
instructions in affected programs: 3362 -> 3329 (-0.98%)
---
src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cp
Will be used in the next commit.
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/ir_optimization.h | 3 ++-
src/glsl/opt_algebraic.cpp | 10 +++---
src/glsl/test_optpass.cpp | 2 +-
4 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/glsl/glsl_parser_ext
In all uses of dotlike() we're writing generic code that operates on 1-4
component vectors. That our IR requires ir_binop_dot expressions'
operands to be 2+ component vectors is an implementation detail that's
not important when implementing built-in functions with dot(), which is
defined for scala
Cuts five instructions out of SynMark's Gl32VSInstancing benchmark.
---
Could be made more general, but I don't see any cases we could optimize
in our existing shader collection.
src/glsl/opt_algebraic.cpp | 35 +++
1 file changed, 35 insertions(+)
diff --git a/sr
The intention of this pass was to give us better instruction scheduling
opportunities, but it unexpectedly reduced some instruction counts as
well:
total instructions in shared programs: 139 -> 1666073 (-0.03%)
instructions in affected programs: 54612 -> 54046 (-1.04%)
(and trades 4 SIMD16
Cuts two instructions out of SynMark's Gl32VSInstancing benchmark.
---
src/glsl/opt_algebraic.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 5c49a78..8494bd9 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_al
On Mon, Mar 10, 2014 at 6:07 PM, Brian Paul wrote:
> On 03/09/2014 01:03 PM, Marek Olšák wrote:
>>
>> Do you have any opinion on this patch, anyone?
>>
>> Marek
>>
>> On Tue, Mar 4, 2014 at 12:32 PM, Marek Olšák wrote:
>>>
>>> From: Marek Olšák
>>>
>>> There is no API for returning the number of
On 03/10/2014 11:19 AM, Anuj Phogat wrote:
> Currently overlapping locations of input variables are not allowed for all
> the shader types in OpenGL and OpenGL ES.
>
>>From OpenGL ES 3.0 spec, page 56:
>"Binding more than one attribute name to the same location is referred
> to as aliasing
On Mon, Mar 10, 2014 at 5:44 PM, Ian Romanick wrote:
> On 03/04/2014 10:31 AM, Ilia Mirkin wrote:
>> On Tue, Mar 4, 2014 at 2:14 AM, Ian Romanick wrote:
>>> On 03/02/2014 12:09 AM, Ilia Mirkin wrote:
Thought I'd give this a shot. Am I on the right track here? Is the dd API
reasonable? I
- Original Message -
> On 03/10/2014 02:52 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On 03/10/2014 03:09 PM, Ian Romanick wrote:
> >>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
> No way. This will break existing applications on Linux.
> >>
> >> How so?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/2014 09:04 PM, Kenneth Graunke wrote:
> On 03/04/2014 02:17 PM, Eric Anholt wrote:
>> The flag wasn't getting updated correctly when the
>> ctx->DrawBuffer or ctx->ReadBuffer changed. It usually ended up
>> working out because most apps only
I only read the compatibility spec.
Marek
On Mon, Mar 10, 2014 at 11:04 PM, Ian Romanick wrote:
> On 03/04/2014 03:32 AM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> There is no API for returning the number of luminance and intensity bits and
>> the 3.3 spec doesn't seem to specify any behavi
On 03/04/2014 03:32 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> There is no API for returning the number of luminance and intensity bits and
> the 3.3 spec doesn't seem to specify any behavior for the queries if the
> format
> is one of L, LA, I. It seems to be a spec bug.
Even the compatibi
Regardless of the other discussion, patches 1 & 2 are
Reviewed-by: Ian Romanick
On 03/08/2014 05:10 PM, Brian Paul wrote:
> The GL specs say the parameter is GLuint, not GLhandleARB.
> ---
> src/mapi/glapi/gen/ARB_robustness.xml |8
> src/mesa/main/uniform_query.cpp |6 ++
On 03/10/2014 02:52 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On 03/10/2014 03:09 PM, Ian Romanick wrote:
>>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
No way. This will break existing applications on Linux.
>>
>> How so? Before, for example, we had glCompileShaderARB
On 03/10/2014 02:39 PM, Brian Paul wrote:
> On 03/10/2014 03:09 PM, Ian Romanick wrote:
>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
>>> No way. This will break existing applications on Linux.
>
> How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and
> glCompileShader(GLuint)
- Original Message -
> On 03/10/2014 03:09 PM, Ian Romanick wrote:
> > On 03/10/2014 02:06 PM, Ian Romanick wrote:
> >> No way. This will break existing applications on Linux.
>
> How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and
> glCompileShader(GLuint) libGL en
On 03/04/2014 10:31 AM, Ilia Mirkin wrote:
> On Tue, Mar 4, 2014 at 2:14 AM, Ian Romanick wrote:
>> On 03/02/2014 12:09 AM, Ilia Mirkin wrote:
>>>
>>> This adds enough code to let drivers implement texture clearing, but
>>> doesn't actually do that for any of them.
>>
>>
>> There's always the usua
How come? GLhandleARB is still a GLuint on Linux. And calling one vs the other
works just as well.
How does merely un-aliasing the entrypoints break anything?
Jose
- Original Message -
> No way. This will break existing applications on Linux.
>
> On 03/08/2014 05:10 PM, Brian Paul wr
On 03/10/2014 03:09 PM, Ian Romanick wrote:
On 03/10/2014 02:06 PM, Ian Romanick wrote:
No way. This will break existing applications on Linux.
How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and
glCompileShader(GLuint) libGL entrypoints and GLhandleARB=GLuint. After
t
On 03/10/2014 02:06 PM, Ian Romanick wrote:
> No way. This will break existing applications on Linux.
This also breaks the libGL <-> DRI driver ABI. These function entry
points have been aliased for... a decade? I can't understand why we'd
break our own ABI because of something silly that Apple
No way. This will break existing applications on Linux.
On 03/08/2014 05:10 PM, Brian Paul wrote:
> For example, we now we have separate dispatch functions for
> glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
>
> With this change and the previous ones we should be able to build/run
Anuj Phogat writes:
> Signed-off-by: Anuj Phogat
Reviewed-by: Eric Anholt
pgppxRbxQFLrd.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sun, Mar 09, 2014 at 12:28:01AM +0530, ANUJ SHARMA wrote:
> Hello Sir ,
> I am Anuj Sharma from India. I am pursuing my M.Tech Degree at Indian
> Institute of Technology, Kanpur, India.
> Sir Where Can i get the more detail on what should we need to implement for
> the "OpenCL Image Support".
On 10/03/14 14:50, Brian Paul wrote:
On 03/09/2014 02:30 PM, Emil Velikov wrote:
On 09/03/14 01:10, Brian Paul wrote:
For example, we now we have separate dispatch functions for
glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
With this change and the previous ones we should be abl
On 10/03/14 07:42, Kenneth Graunke wrote:
On 03/08/2014 12:29 PM, Emil Velikov wrote:
This helper script will be used to minimise the duplication
during link generation across all gallium targets.
v2:
- Handle vdpau_LTLIBRARIES. Requested by Christian König.
Signed-off-by: Emil Velikov
Revi
Signed-off-by: Anuj Phogat
---
src/glsl/linker.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index f6b2661..a619bc8 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -297,7 +297,7 @@ linker_warning(gl_shader_program *
Currently overlapping locations of input variables are not allowed for all
the shader types in OpenGL and OpenGL ES.
>From OpenGL ES 3.0 spec, page 56:
"Binding more than one attribute name to the same location is referred
to as aliasing, and is not permitted in OpenGL ES Shading Language
https://bugs.freedesktop.org/show_bug.cgi?id=75980
Benjamin Bellec changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Juha-Pekka Heikkila writes:
> I think these patches create functionality which Kenneth, Eric and Matt
> talk about in this discussion:
> http://lists.freedesktop.org/archives/mesa-dev/2014-February/054991.html
>
> I ran piglit quick set with these changes on Ironlake and Ivybridge and I did
> no
https://bugs.freedesktop.org/show_bug.cgi?id=75980
--- Comment #4 from funkydude ---
Thank you, sorry for wasting your time. Please close this.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-de
https://bugs.freedesktop.org/show_bug.cgi?id=75980
--- Comment #3 from Benjamin Bellec ---
Did you tried this?
https://github.com/ValveSoftware/portal2
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
On 03/10/2014 08:50 AM, Brian Paul wrote:
On 03/09/2014 02:30 PM, Emil Velikov wrote:
On 09/03/14 01:10, Brian Paul wrote:
For example, we now we have separate dispatch functions for
glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
With this change and the previous ones we should b
I'd probably split this into two patches:
i965/vec4: Add and use writes_accumulator flag.
i965/vec4: Add and use MAC instruction.
(or drop the /vec4 prefixes and implement it for both vec4 and fs backends! :)
The first patch also needs to update the instruction scheduling code
in brw_schedule_in
https://bugs.freedesktop.org/show_bug.cgi?id=75980
--- Comment #2 from funkydude ---
I only just installed it yesterday and its barely been out that long so it was
probably always broken.
I launched it with Steam running in the terminal. I'm not sure this is mesa
related...
Game update: AppID 6
---
src/mesa/main/tests/dispatch_sanity.cpp | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index d1b0011..de71445 100644
--- a/src/mesa/main/tests/dispatch_sanity.cp
On 03/09/2014 01:03 PM, Marek Olšák wrote:
Do you have any opinion on this patch, anyone?
Marek
On Tue, Mar 4, 2014 at 12:32 PM, Marek Olšák wrote:
From: Marek Olšák
There is no API for returning the number of luminance and intensity bits and
the 3.3 spec doesn't seem to specify any behavio
https://bugs.freedesktop.org/show_bug.cgi?id=75989
Alex Deucher changed:
What|Removed |Added
Attachment #95518|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=75989
Priority: medium
Bug ID: 75989
Assignee: mesa-dev@lists.freedesktop.org
Summary: Darkness in Portal 2
Severity: normal
Classification: Unclassified
OS: All
Reporter
Hi all,
I'm Vidudaya Neranjan Bandara , Currently I'm an undergraduate from
University of Moratuwa , Department of Computer Science and Engineering,
Sri Lanka. I'm very much interested in open source software development and
thought to contribute to the society because I know the value of it.
I wou
Fix eglCreateImage() from a packed dma_buf surface with a non-zero offset
to pixels data. In particular, this fixes support for planar YUV surfaces
when they are individually mapped on a per-plane basis, i.e. when the
OES_EGL_image_external is not used and user application wants to use its
own shad
Signed-off-by: Gwenole Beauchesne
---
src/mesa/drivers/dri/i965/intel_screen.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 464cebf..05cf6b1 100644
--- a/src/mesa/drivers/dr
In order to support mapping of planar YUV surfaces on a per-plane basis,
it looks convenient to consider those planes as a buffer of red (8-bit),
resp. red/green (16-bit), components.
Signed-off-by: Gwenole Beauchesne
---
include/GL/internal/dri_interface.h |4
src/egl/drivers/dri2/egl_
I want to be able to map each individual pane of a planar YUV surface (VA-API)
as a separate image. Either for customizing the shader code for YUV-to-RGB
conversion, or for directly exposing a single plane to third-party API like
OpenCL.
This patch series adds support for mapping a surface plane t
Hello Jonathan,
On 10.03.2014 16:04, Jonathan Gray wrote:
> On Thu, Jul 18, 2013 at 01:59:37PM -0700, Matt Turner wrote:
>> On Mon, Apr 15, 2013 at 1:46 PM, Andreas Oberritter wrote:
>>> This is required in case a wrapper or symlink is used. This patch
>>> has also been sent upstream, awaiting mo
Brian Paul writes:
> There's no real reason to list all the formats in the comments.
Patch 1 and 3 are:
Reviewed-by: Eric Anholt
Patch 2 is just:
Acked-by: Eric Anholt
because I like the format.h order but I haven't cross-checked things.
pgpaQa9XNbyTO.pgp
Description: PGP signature
_
Brian Paul writes:
> The GL specs say the parameter is GLuint, not GLhandleARB.
This series is:
Reviewed-by: Eric Anholt
pgpFoiwICKFFa.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.
On Fri, Mar 7, 2014 at 6:56 PM, Tapani Pälli wrote:
> Remove GL_OES_EGL_image_external usage, this would work with current
> Mesa only if image was created with EGL_EXT_image_dma_buf_import, this
> makes test work again also if GL_OES_EGL_image_external is present.
Can we make the use of GL_OES_EG
https://bugs.freedesktop.org/show_bug.cgi?id=75980
Benjamin Bellec changed:
What|Removed |Added
CC||b.bel...@gmail.com
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=75980
--- Comment #1 from Benjamin Bellec ---
Did you successfully loaded it before?
Could you launch steam in a terminal and post the log here.
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Thu, Jul 18, 2013 at 01:59:37PM -0700, Matt Turner wrote:
> On Mon, Apr 15, 2013 at 1:46 PM, Andreas Oberritter wrote:
> > This is required in case a wrapper or symlink is used. This patch
> > has also been sent upstream, awaiting moderation.
> >
> > Signed-off-by: Andreas Oberritter
> > ---
>
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index dc58457..4e4
This change MACH, ADDC and SUBB opcodes to use added accumulator
flag and add new opcode MAC which use accumulator flag.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_eu.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4.cpp | 10 ++
src/mesa/driv
I think these patches create functionality which Kenneth, Eric and Matt
talk about in this discussion:
http://lists.freedesktop.org/archives/mesa-dev/2014-February/054991.html
I ran piglit quick set with these changes on Ironlake and Ivybridge and I did
not see any regression. If this seems ok I
https://bugs.freedesktop.org/show_bug.cgi?id=75980
Priority: medium
Bug ID: 75980
Assignee: mesa-dev@lists.freedesktop.org
Summary: Portal 2 (beta) fails to launch
Severity: major
Classification: Unclassified
OS: Linux (All)
On 03/09/2014 02:30 PM, Emil Velikov wrote:
On 09/03/14 01:10, Brian Paul wrote:
For example, we now we have separate dispatch functions for
glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
With this change and the previous ones we should be able to build/run
on MacOS again (where G
On Mon, Mar 10, 2014 at 08:27:17AM -0600, Brian Paul wrote:
> On 03/10/2014 06:20 AM, Jonathan Gray wrote:
> >Still looking to have this merged...
> >
> >On Thu, Aug 15, 2013 at 12:17:27AM +1000, Jonathan Gray wrote:
> >>Signed-off-by: Jonathan Gray
> >>---
> >> src/gallium/include/pipe/p_config.
On 03/10/2014 06:20 AM, Jonathan Gray wrote:
Still looking to have this merged...
On Thu, Aug 15, 2013 at 12:17:27AM +1000, Jonathan Gray wrote:
Signed-off-by: Jonathan Gray
---
src/gallium/include/pipe/p_config.h | 10 ++
1 file changed, 10 insertions(+)
diff --git src/gallium/inc
On 03/10/2014 07:27 AM, Jonathan Gray wrote:
Fixes the following build error on OpenBSD:
./.libs/libglsl.a(builtin_functions.o)(.text+0x973): In function `mtx_lock':
../../include/c11/threads_posix.h:195: undefined reference to
`pthread_mutex_lock'
./.libs/libglsl.a(builtin_functions.o)(.text+0
Fixes the following build error on OpenBSD:
./.libs/libglsl.a(builtin_functions.o)(.text+0x973): In function `mtx_lock':
../../include/c11/threads_posix.h:195: undefined reference to
`pthread_mutex_lock'
./.libs/libglsl.a(builtin_functions.o)(.text+0x9a5): In function `mtx_unlock':
../../include/
Still looking to have this merged...
On Thu, Aug 15, 2013 at 12:17:27AM +1000, Jonathan Gray wrote:
> Signed-off-by: Jonathan Gray
> ---
> src/gallium/include/pipe/p_config.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git src/gallium/include/pipe/p_config.h
> src/gallium/in
On Wed, Mar 05, 2014 at 11:40:40PM -0800, Eric Anholt wrote:
> I know this code has confused others, and it confused me 3 years later,
> too.
> ---
> src/glsl/opt_dead_code_local.cpp | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/src/glsl/o
There are good reasons for wanting alternative component orderings for some
surfaces, but this complicates views, which need the components to be in a
consistent order across whole view classes.
This series alters texture format selection to prefer unswizzled formats in
TexStorage* and TextureV
Now this is the preferred format for GL_SRGB8_ALPHA8 with
prefer_no_swizzle.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surfac
This is a hint that we want components ordered as they are in the
internalformat name.
We want this for views (and so also for
immutable-format textures from which views might be created).
In other cases we might want to prefer ARGB or BGRA component order
to avoid reswizzling uploads, or for int
If prefer_no_swizzle is set, try:
- The exact matching format
- Formats with the required components in the correct order, plus a junk
component
- finally, swizzled formats (BGRA etc)
Signed-off-by: Chris Forbes
---
src/mesa/main/texformat.c | 35 +++
1 file cha
Future patches will pass this to where it is needed. For now, just
drop it on the floor.
TexStorage* and TextureView pass GL_TRUE; all other callers pass
GL_FALSE.
Signed-off-by: Chris Forbes
---
src/mesa/main/teximage.c | 11 +++
src/mesa/main/teximage.h |
On Thu, Mar 06, 2014 at 04:29:39PM -0800, Kenneth Graunke wrote:
> From: Eric Anholt
>
> This keeps us from needing to reemit all the other stage state just
> because a surface changed.
>
> Improves unoptimized glamor x11perf -f8text by 1.10201% +/- 0.489869%
> (n=296). [v1]
>
> v2: (by Kenneth
Am 09.03.2014 12:55, schrieb Emil Velikov:
The primary users of these are linux developers, although
it can be extended for *BSD and others if needed.
Fixes make install for Cygwin and OpenBSD at least.
v2:
- Wrap vdpau targets as well.
v3:
- Fold HAVE_COMPAT_SYMLINKS checks within install*
On 03/08/2014 12:29 PM, Emil Velikov wrote:
> This helper script will be used to minimise the duplication
> during link generation across all gallium targets.
>
> v2:
> - Handle vdpau_LTLIBRARIES. Requested by Christian König.
>
> Signed-off-by: Emil Velikov
> Reviewed-by: Jon TURNEY
> ---
>
On 03/07/2014 04:05 PM, Ian Romanick wrote:
On 03/07/2014 12:55 PM, Tapani Pälli wrote:
Patch adds a remap table for uniforms that is used to provide a mapping
from application specified uniform location to actual location in the
UniformStorage. Existing UniformLocationBaseScale usage is removed
On 03/07/2014 09:13 PM, Eric Anholt wrote:
Tapani Pälli writes:
I think the way I'd write this comment is "Mapping from GL uniform
locations returned by glUniformLocation to UniformStorage entries.
Arrays will have multiple contiguous slots in the UniformRemapTable, all
pointing to the same Uni
On 03/04/2014 02:17 PM, Eric Anholt wrote:
> We have to be a little careful here, because BlitFB itself has a fallback
> path that calls CopyTexSubImage(), so we reach over into its state to tell
> it to skip that case.
Right...to expand on this...
Mesa enables GL_EXT_framebuffer_blit universally
On 03/04/2014 02:17 PM, Eric Anholt wrote:
> There's already code for them due to the GenerateMipmap path, so we just
> need to make sure we've got our coordinates present.
> ---
> src/mesa/drivers/common/meta_blit.c | 17 +++--
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> d
84 matches
Mail list logo
