libdl does not exist on many platforms which have dlopen in libc.
Signed-off-by: Jonathan Gray
---
src/gallium/drivers/nouveau/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git src/gallium/drivers/nouveau/Makefile.am
src/gallium/drivers/nouveau/Makefile.am
index ac4f
drm headers may be installed in a different directory
Signed-off-by: Jonathan Gray
---
src/gallium/drivers/nouveau/nouveau_context.h | 2 +-
src/gallium/drivers/nouveau/nouveau_screen.c| 2 +-
src/gallium/drivers/nouveau/nouveau_vp3_video.h | 2 +-
src/gallium/drivers/nouveau/nouveau_winsy
On Wed, Mar 19, 2014 at 2:30 PM, Rafal Mielniczuk
wrote:
> +
Please use the same style that all of the other comments use... except
the 142-143 one that I missed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/ma
https://bugs.freedesktop.org/show_bug.cgi?id=76377
Priority: medium
Bug ID: 76377
Assignee: mesa-dev@lists.freedesktop.org
Summary: DRI3 should only be enabled on Linux due to a udev
dependency
Severity: normal
Classifica
On Wed, 2014-03-19 at 22:30 +0100, Rafal Mielniczuk wrote:
> Signed-off-by: Rafal Mielniczuk
> ---
> src/mapi/glapi/gen/ARB_query_buffer_object.xml | 18 ++
> src/mapi/glapi/gen/Makefile.am | 1 +
> src/mapi/glapi/gen/gl_API.xml | 4
> 3 fil
Ok thank you for your input, I see the problem now,
I will take a deeper look into this extension,
maybe I will try to enable it for software drivers first..
Thanks,
Rafal
On 20.03.2014 00:19, Marek Olšák wrote:
The extension specifically mentions that it allows storing a query
result into a b
The extension specifically mentions that it allows storing a query
result into a buffer without the GPU->CPU->GPU round-trip, but your
patch series contains that round-trip. If a driver cannot do it
without the round-trip, I don't think the extension should be exposed.
Adding an extension and only
Hello,
I have been playing around this extensions for a couple of days now,
I got something working so I decided to send it for review :)
I backed it up by piglit tests as well.
Rafal
Rafal Mielniczuk (8):
glapi: Add xml infrastructure for ARB_query_buffer_object
mesa: Add QueryBuffer to con
Signed-off-by: Rafal Mielniczuk
---
src/mesa/main/get.c | 4
src/mesa/main/get_hash_params.py | 3 +++
2 files changed, 7 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index b190851..f2e6eba 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -9
Just return and do nothing if query result is not yet available
Signed-off-by: Rafal Mielniczuk
---
src/mesa/main/queryobj.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 86e7c3a..66250b6 100644
--- a/src/mesa/main
Signed-off-by: Rafal Mielniczuk
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 9758dcc..c021eed 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -174,7 +174,7 @@ GL 4.4:
GL_ARB_clear_texture
Signed-off-by: Rafal Mielniczuk
---
src/mesa/main/queryobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 88e80c4..70a4bb8 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -752,7 +752,7 @@
Signed-off-by: Rafal Mielniczuk
---
src/mesa/main/extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index a72284c..18710a6 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -123,6 +123,7 @@ static con
If QueryBuffer is bound, store query result in it at given offset,
otherwise store query result in client memory pointer
Signed-off-by: Rafal Mielniczuk
---
src/mesa/main/queryobj.c | 88 ++--
1 file changed, 71 insertions(+), 17 deletions(-)
diff --g
Signed-off-by: Rafal Mielniczuk
---
src/mapi/glapi/gen/ARB_query_buffer_object.xml | 18 ++
src/mapi/glapi/gen/Makefile.am | 1 +
src/mapi/glapi/gen/gl_API.xml | 4
3 files changed, 23 insertions(+)
create mode 100644 src/mapi/glapi/gen/ARB
Add QueryBuffer and initialise it to NullBufferObj
on start
Signed-off-by: Rafal Mielniczuk
---
src/mesa/main/bufferobj.c | 5 +
src/mesa/main/mtypes.h| 2 ++
2 files changed, 7 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 2e9e059..8d6e1ee 10064
On Wed, Mar 19, 2014 at 7:27 AM, Mike Stroyan wrote:
> Ken,
>
> The defect depends on details of the shader compiler reusing registers.
> Old register values are sometimes left in some channels when the
> write-after-write hints are used.
> Further reducing the GLSL test case would be tricky bec
On 03/16/2014 01:52 PM, Alexander von Gluck IV wrote:
> On 01/10/2014 07:40 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> No driver uses them. They will just be annoying in future patches.
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/mesa/drivers/dri/i915/intel_context.c | 15 ++--
Signed-off-by: Gwenole Beauchesne
---
src/mesa/drivers/dri/i965/intel_screen.c | 32 +-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 4e9a775..5223c9d 100644
--
Allow an application to specify the layout of dma_buf immported images
with standard GL|GLES texture internal formats, instead of DRM fourcc
values.
This allows for the application to map each individual plane of a YUV
planar surface separately for additional processing or customized
composition k
Hi,
In order to constrain the expansion of DRM fourcc values to support non
presentable formats like arrays of integers, or allowing per-plane imports of
YUV surfaces, I am proposing the following change to the EXT_image_dma_buf
specification.
The idea here is to allow the application to specify
FWIW, I'm on a pure 32 bit system.
Dieter
Am 18.03.2014 04:24, schrieb Dieter Nützel:
Am 17.03.2014 21:55, schrieb Dieter Nützel:
Am 17.03.2014 18:59, schrieb Benjamin Bellec:
Hi,
Could you bisect?
It's under way...
Here we go:
/opt/mesa> git bisect good
Bisecting: 0 revisions left to t
On Mon, Mar 17, 2014 at 09:43:42AM -0400, Ilia Mirkin wrote:
> This reverts commit d9b983519c63b9072677364a6e399d213a1855e5.
>
> Unfortunately it seems like rpath is evaluated before LD_LIBRARY_PATH,
> so this breaks e.g. stream, as well as any other user of that env var,
> if the llvm path happen
The AoS version of ld_build_blend_factor was assuming that if the first
channel was alpha, there were no rgb components.
Fixes glean/blendFunc on System z. No piglit regressions on x86_64.
The shortcut is still used in tests like spec/ARB_framebuffer_object/
fbo-alpha.
Signed-off-by: Richard San
Looks good.
This is yet another thing that would benefit if we moved things like
u_debug.h's assert to a place it can be used everywhere -- the "shared runtime"
idea.
Jose
- Original Message -
> In the gallium code, the assert() macro could come from either the
> system's assert.h file
Rather than iterate over format.channels and format.swizzles directly,
use Python subfunctions that take the channel and swizzle lists as
arguments. This allow the channel and swizzle lists to depend on
endianness.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sand
https://bugs.freedesktop.org/show_bug.cgi?id=74717
--- Comment #15 from Dieter Nützel ---
FWIW, I'm on a pure 32 bit system.
Dieter
--
You are receiving this mail because:
You are on the CC list for the bug.
___
mesa-dev mailing list
mesa-dev@lists.f
With the big-endian changes, there can be two swizzle orders for each format.
This patch turns Format.inv_swizzle() into a global function that takes the
swizzle list as a parameter.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary
Splits out the code that parses the channel list, so that we
can have different lists for little and big endian.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_parse.py | 96 +++-
1 file chan
The old python code used sys.is_big_endian to select between little-endian
and big-endian formats, which meant that the build and host endiannesses
needed to be the same. This patch instead generates both big- and little-
endian layouts, using PIPE_ARCH_BIG_ENDIAN to select between them.
Signed-o
The main aim is to reduce the number of places that access channels[0],
swizzles[0] and swizzles[1] directly.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_pack.py | 27 ++-
src/gallium/auxiliary/util/
This is a refresh of:
http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
At the moment the python code uses sys.byteorder to decide whether
u_format_table.c should be for big or little endian. With this series
it instead generates both forms, using blocks like:
#ifdef PIPE_
Am 19.03.2014 10:44, schrieb Kenneth Graunke:
> Traditionally, we've implemented fragment color clamping by emitting
> "mov.sat" in the fragment shader's final color write code, clamping
> the output to [0, 1] prior to blending. (When clamping is off, we
> use a regular "mov".) This means we have
ping? should be fairly straight-forward... looks like gentoo moved
llvm back to /usr/lib for llvm-3.4 (while it was in /usr/lib/llvm for
llvm-3.1, current stable), so the original issue will disappear for me
as well.
On Mon, Mar 17, 2014 at 9:43 AM, Ilia Mirkin wrote:
> This reverts commit d9b983
On Wed, Mar 19, 2014 at 11:30:54AM -0400, Aditya Avinash wrote:
> Hi Tom,
> Do I need to have an AMD GPU for compute images to R600?
> Thank you!
>
Yes, you will need an evergreen or new AMD GPU (see the decoder ring
http://xorg.freedesktop.org/wiki/RadeonFeature/#index5h2 for specific
model numb
Ken,
The defect depends on details of the shader compiler reusing registers.
Old register values are sometimes left in some channels when the
write-after-write hints are used.
Further reducing the GLSL test case would be tricky because the reuse of g8
would be likely to be changed.
I did already
https://bugs.freedesktop.org/show_bug.cgi?id=76188
--- Comment #2 from Gwenole Beauchesne ---
According to SVN log, the most approaching constant that could be checked would
be EGL_EGLEXT_VERSION >= 20140114. i.e. r20692 for the EXT_image_dma_buf_import
spec, and r24760 for the earliest version b
On 03/18/2014 06:56 PM, Alexander von Gluck IV wrote:
On 03/17/2014 10:15 AM, Brian Paul wrote:
On 03/16/2014 02:52 PM, Alexander von Gluck IV wrote:
On 01/10/2014 07:40 PM, Ian Romanick wrote:
From: Ian Romanick
No driver uses them. They will just be annoying in future patches.
Signed-off
I'd be fine with removing/reducing the comments.
-Brian
On 03/19/2014 05:45 AM, Marek Olšák wrote:
Are these comments really needed considering the format names are
self-explanatory?
Marek
On Wed, Mar 19, 2014 at 10:34 AM, Chris Forbes wrote:
The comments for the actual formats were fixed a
Are these comments really needed considering the format names are
self-explanatory?
Marek
On Wed, Mar 19, 2014 at 10:34 AM, Chris Forbes wrote:
> The comments for the actual formats were fixed a while ago,
> but the examples at the top were not, which was confusing.
>
> Signed-off-by: Chris Forb
On Wed, Mar 19, 2014 at 7:30 AM, Gwenole Beauchesne wrote:
> 2014-03-15 12:28 GMT+01:00 Daniel Vetter :
>> On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
>>> Hi,
>>>
>>> 2014-03-14 22:52 GMT+01:00 Daniel Vetter :
>>> > On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauches
On Thu, Mar 13, 2014 at 11:07 PM, Francisco Jerez wrote:
> Oh... That's right... But doesn't that mean that your choice is
> backwards on BE machines?
That's true. How much does that matter, though? Most other drivers
which are close to supporting these features already have a
ChooseTextureForm
Traditionally, we've implemented fragment color clamping by emitting
"mov.sat" in the fragment shader's final color write code, clamping
the output to [0, 1] prior to blending. (When clamping is off, we
use a regular "mov".) This means we have to recompile based on the
GL_CLAMP_FRAGMENT_COLOR sta
The comments for the actual formats were fixed a while ago,
but the examples at the top were not, which was confusing.
Signed-off-by: Chris Forbes
---
src/mesa/main/formats.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats
This series follows on from the ARB_texture_view support +
`prefer_no_swizzle` patches I sent out a while ago and fixes a few
things which I had previously overlooked:
- CopyTexSubImage didn't account for MinLayer or MinLevel when copying into a
view.
- GetTexImage handling of SNORM formats would
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/intel_tex_copy.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c
b/src/mesa/drivers/dri/i965/intel_tex_copy.c
index ca0b5b9..c2b6c35 100644
--- a/src/mesa/drivers/dri
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 22a4a07..9194c06 100644
--- a/src/mesa/drive
This is supported by all generations, and is required for memory layout
consistency for texture_view.
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/dr
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
Previously, we would unpack the texels to floats using *_TO_FLOAT_TEX,
and then pack them into the desired format using FLOAT_TO_*. Unfortunately,
this isn't quite the inverse operation, and so some texel values would
end up off-by-one.
This fixes the GL_RGB8_SNORM and GL_RGB16_SNORM subcases in p
50 matches
Mail list logo
