Signed-off-by: Timothy Arceri
---
docs/devinfo.html | 5 +
1 file changed, 5 insertions(+)
diff --git a/docs/devinfo.html b/docs/devinfo.html
index d4a6dfb..67c1f34 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -56,6 +56,11 @@ To add a new GL extension to Mesa you have to do at l
On Tue, Apr 1, 2014 at 11:18 PM, Tapani Pälli wrote:
> On GEN6 math operations require destination writemask to be WRITEMASK_XYZW.
That's not really it. Gen6 doesn't support the math in align16 mode,
which is the mode required for writemasking and swizzling.
> Bugzilla: https://bugs.freedesktop.
On GEN6 math operations require destination writemask to be WRITEMASK_XYZW.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76883
Signed-off-by: Tapani Pälli
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/src
On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:
> Hello Ian, hello Timothy,
>
> does this fix the regression introduced with commit fb78fa58?
>
> [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
> initTexture2D (bisected)
> http://lists.freedesktop.org/archives/mesa-dev/2
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
This is to avoid running out of query buffer space due to winsys
limitations. Instead of a fixed size per screen pool of query buffers,
use a slab allocator that allocates a new slab if we run out of space
in the first one.
v2: Correct email addresses.
v3: s/8192/VMW_QUERY_POOL_SIZE/. Improve docu
From: Ian Romanick
The OpenGL ES 1.1 conformance tests expect this function to be
statically available form libGLESv1_CM.so. The comment "required for
es1.1" in the XML file should have been a clue.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76926
Cc: hu
OpenBSD does not have DT_NEEDED entries for libc by design,
over concerns how the symbols would be referenced after
changing the major version of the library.
So avoid -no-undefined checks on OpenBSD as they will fail.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856
Signed-off-by: Jo
On 04/01/2014 03:56 PM, Dieter Nützel wrote:
> Hello Ian, hello Timothy,
>
> does this fix the regression introduced with commit fb78fa58?
I wouldn't think so... this just fixes a test run by 'make check' in
certain configurations.
> [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION
https://bugs.freedesktop.org/show_bug.cgi?id=76856
--- Comment #7 from Jonathan Gray ---
Created attachment 96753
--> https://bugs.freedesktop.org/attachment.cgi?id=96753&action=edit
patch to disable no-undefined on OpenBSD
--
You are receiving this mail because:
You are the assignee for the
http://bitly.com/1ibsC0y
What debugging steps are next?
There is no BT because the application exits cleanly.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hello Ian, hello Timothy,
does this fix the regression introduced with commit fb78fa58?
[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
initTexture2D (bisected)
http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html
Thanks,
Dieter
Am 01.04.2014 22:15, schri
On Mon, Mar 31, 2014 at 10:44 AM, Eric Anholt wrote:
> Matt Turner writes:
>
>> Previously we'd ignore the sources of instructions with non-GRF
>> destinations when calculating calculating the dead channels. This would
>> lead to us incorrectly removing the first instruction in this sequence:
>>
Previously we'd ignore the sources of instructions with non-GRF
destinations when calculating calculating the dead channels. This would
lead to us incorrectly removing the first instruction in this sequence:
mov vgrf11, ...
cmp.ne.f0 null, vgrf11, 1.0
mov vgrf11, ...
Bugzilla: https://bu
On Wed, 2014-04-02 at 08:25 +1100, Timothy Arceri wrote:
> Thanks Ian,
>
> Reviewed-by: Timothy Arceri
>
> I wasn't aware of this test. I guess the other KHR_debug functions
> should be added here also? If so I can create a patch for this later
> today unless you just want to do it.
>
> When I
Thanks Ian,
Reviewed-by: Timothy Arceri
I wasn't aware of this test. I guess the other KHR_debug functions
should be added here also? If so I can create a patch for this later
today unless you just want to do it.
When I get some time I might also add another dot point to the 'Adding
Extensions'
On 04/01/2014 02:15 PM, Ian Romanick wrote:
From: Ian Romanick
C89 has a fairly short minimum-maximum string length. To support
compilers limited by the C89 limits, this script had a mode where it
would generate a character array instead of a giant string. These were
functionally the same, bu
From: Ian Romanick
This reverts commit 526e49290cd2d83fb931708a786c27647972a00c.
The original build problem should be fixed by the previous commit.
Signed-off-by: Ian Romanick
---
src/mapi/glapi/gen/gl_and_es_API.xml | 129 ---
1 file changed, 43 insertions(+),
From: Ian Romanick
C89 has a fairly short minimum-maximum string length. To support
compilers limited by the C89 limits, this script had a mode where it
would generate a character array instead of a giant string. These were
functionally the same, but the code generated for the character array i
From: Ian Romanick
Ages ago Chia-I added an ES compatibility flag to several of the various
generator scripts. The intention was to bridge differences between ES
and desktop in Mesa builds without ES. It doesn't appear that it has
ever been used. Recent changes to static_dispatch status of sev
From: Ian Romanick
Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
GL_KHR_debug output functions. As a result, the function names in
struct _glapi_table also changed. The table in check_table.cpp used the
ARB names.
Signed-off-by: Ian Romanick
Cc: Vinson Lee
Cc: Timothy
Am 27.03.2014 22:00, schrieb Emil Velikov:
Cc: Christian König
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/Automake.inc | 6 ++
src/gallium/targets/r600/omx/Makefile.am | 5 +
src/gallium/targets/radeonsi/omx/Makefile.am | 5
Am 27.03.2014 22:00, schrieb Emil Velikov:
Otherwise the omx drivers are explicitly linked but never wrapped in
order to use it.
On the other hand I'm not sure if we really need the tracer linked in
here, referencing it was just to make drm_target.c happy.
Christian.
Cc: Christian König
S
Am 28.03.2014 11:32, schrieb Emil Velikov:
On 28/03/14 09:40, Christian König wrote:
Am 27.03.2014 22:00, schrieb Emil Velikov:
Otherwise the omx drivers are explicitly linked but never wrapped in
order to use it.
On the other hand I'm not sure if we really need the tracer linked in here,
refe
Am 27.03.2014 22:00, schrieb Emil Velikov:
Cc: Christian König
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/Automake.inc | 6 ++
src/gallium/targets/r600/omx/Makefile.am | 10 +++---
src/gallium/targets/radeonsi/omx/Makefile.
On Tue, Apr 1, 2014 at 10:26 AM, Emil Velikov wrote:
> On 23/03/14 04:53, Jonathan Gray wrote:
>> Don't hardcode /dev/dri/card0 but instead use the drm
>> macros which allows the correct /dev/drm0 device to be
>> opened on OpenBSD.
>>
>> v2: use snprintf and fallback to /dev/dri/card0
>> suggested
On 23/03/14 04:53, Jonathan Gray wrote:
> Don't hardcode /dev/dri/card0 but instead use the drm
> macros which allows the correct /dev/drm0 device to be
> opened on OpenBSD.
>
> v2: use snprintf and fallback to /dev/dri/card0
> suggested by Emil Velikov.
>
> Signed-off-by: Jonathan Gray
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=76856
--- Comment #6 from Emil Velikov ---
Seems like a lovely case. There is a very nice 10+ old topic wrt this behaviour
and libtool [1]. To make things even better sometimes the linking rules differ
between versions (FreeBSD 5 vs 4)[2].
Most annoyi
On Tue, Apr 1, 2014 at 12:39 PM, Emil Velikov wrote:
> On 01/04/14 16:04, Rob Clark wrote:
>> From: Rob Clark
>>
>> Otherwise it will trick the gallium driver into thinking that the render
>> target has actually changed (due to different pipe_surface pointing to
>> same underlying pipe_resource).
On Tue, Apr 1, 2014 at 12:37 PM, Thomas Hellstrom wrote:
> On 04/01/2014 06:18 PM, Rob Clark wrote:
>> On Tue, Apr 1, 2014 at 12:14 PM, Zack Rusin wrote:
>>> - Original Message -
From: Rob Clark
While still more of a stop-gap solution (until glamor) for freedreno,
wit
In all fairness we allow the gallium tests to be build with --disable-dri
which will result in the approapriate winsys to not be build, thus the
build will fail.
./configure --disable-dri --with-gallium-drivers=svga --enable-gallium-tests
Cc: Brian Paul
Signed-off-by: Emil Velikov
---
src/ga
Rather than defining our own set of variables, use NEED_WINSYS_XLIB
and based on it include the sw/xlib winsys.
Signed-off-by: Emil Velikov
---
configure.ac | 5 +
src/gallium/targets/gbm/Makefile.am| 2 +-
src/gallium/targets/opencl/Makefile.am | 2 +-
src/gall
The function relies on the sw/dri winsys which is build only when --enable-dri
is set. Fixes build issues with the following config
./configure --disable-dri --with-gallium-drivers=svga --enable-xa
Issue can be reproduced with any hw gallium driver + st that uses the
pipe-loader.
Cc: Brian Pau
On 01/04/14 16:04, Rob Clark wrote:
> From: Rob Clark
>
> Otherwise it will trick the gallium driver into thinking that the render
> target has actually changed (due to different pipe_surface pointing to
> same underlying pipe_resource). This is really badness for tiling GPUs
> like adreno.
>
H
On 04/01/2014 06:18 PM, Rob Clark wrote:
> On Tue, Apr 1, 2014 at 12:14 PM, Zack Rusin wrote:
>> - Original Message -
>>> From: Rob Clark
>>>
>>> While still more of a stop-gap solution (until glamor) for freedreno,
>>> with these few relatively simple changes I get a pretty big performan
On Tue, Apr 1, 2014 at 12:14 PM, Zack Rusin wrote:
> - Original Message -
>> From: Rob Clark
>>
>> While still more of a stop-gap solution (until glamor) for freedreno,
>> with these few relatively simple changes I get a pretty big performance
>> boost (~40%) for xf86-video-freedreno.
>
>
- Original Message -
> From: Rob Clark
>
> While still more of a stop-gap solution (until glamor) for freedreno,
> with these few relatively simple changes I get a pretty big performance
> boost (~40%) for xf86-video-freedreno.
That looks great to me. Nice work.
But to be honest the only
From: Rob Clark
While still more of a stop-gap solution (until glamor) for freedreno,
with these few relatively simple changes I get a pretty big performance
boost (~40%) for xf86-video-freedreno.
Rob Clark (4):
xa: handle solid-fill src/mask
xa: remove unneeded args
xa: scissor to help ti
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/state_trackers/xa/xa_composite.c | 3 +--
src/gallium/state_trackers/xa/xa_context.c | 5 +
src/gallium/state_trackers/xa/xa_priv.h | 3 +--
src/gallium/state_trackers/xa/xa_renderer.c | 7 ---
src/gallium/state_trackers/x
From: Rob Clark
Keep track of the maximal bounds of all the operations and set scissor
accordingly. For tiling GPU's this can be a big win by reducing the
memory bandwidth spent moving pixels from system memory to tile buffer
and back.
You could imagine being more sophisticated and splitting up
From: Rob Clark
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling GPUs
like adreno.
Signed-off-by: Rob Clark
---
src/gallium/state_tr
From: Rob Clark
Add support to property handle solid-fill src and/or mask. Without this
we fallback to sw a lot for common things like text rendering.
Signed-off-by: Rob Clark
---
src/gallium/state_trackers/xa/xa_composite.c | 88
src/gallium/state_trackers/xa/xa_priv.h | 7 +
On Tue, Apr 1, 2014 at 4:45 PM, Ilia Mirkin wrote:
> On Tue, Apr 1, 2014 at 10:14 AM, Marek Olšák wrote:
>> 1) Adding functions to cso_context only makes sense for features which
>> need to be disabled or changed for meta ops (e.g. clear_with_quad,
>> glBitmap, glDrawPixels). I don't see you usin
On Tue, Apr 1, 2014 at 10:14 AM, Marek Olšák wrote:
> 1) Adding functions to cso_context only makes sense for features which
> need to be disabled or changed for meta ops (e.g. clear_with_quad,
> glBitmap, glDrawPixels). I don't see you using
> cso_save_sample_shading, which clearly shows it's use
On Tue, Apr 1, 2014 at 10:25 AM, Roland Scheidegger wrote:
>> guidance. Also FWIW, gl_NumSamples gets converted to a constbuf lookup
>> somewhere upstream of mesa/st (I was a bit surprised by that). Perhaps
>> the sample position should be as well? Or is nvidia hardware unusual
>> in not having an
Am 01.04.2014 02:13, schrieb Ilia Mirkin:
> On Mon, Mar 31, 2014 at 7:42 PM, Roland Scheidegger
> wrote:
>> I've got some ideas but I'm not sure the design would be really better -
>> I'd like to hear some other opinions.
>>
>> Am 31.03.2014 02:52, schrieb Ilia Mirkin:
>>> ---
>>> src/gallium/au
https://bugs.freedesktop.org/show_bug.cgi?id=76252
--- Comment #8 from José Fonseca ---
(In reply to comment #7)
> A colleaque had another idea:
> We export stw_cleanup and call it before unloading the dll. This seems to
> work very well and shuts down the threads as expected.
>
> If you don't s
1) Adding functions to cso_context only makes sense for features which
need to be disabled or changed for meta ops (e.g. clear_with_quad,
glBitmap, glDrawPixels). I don't see you using
cso_save_sample_shading, which clearly shows it's useless. Does sample
shading need to be set differently for meta
From: Leo Liu
This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
Signed-off-by: Leo Liu
---
src/gallium/drivers/radeon/r600_texture.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_
https://bugs.freedesktop.org/show_bug.cgi?id=76869
José Fonseca changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
|o
On 04/01/2014 12:58 AM, Jordan Justen wrote:
From:
http://www.khronos.org/registry/gles/api/GLES3/gl31.h
http://www.khronos.org/registry/gles/api/GLES2/gl2ext.h
http://www.khronos.org/registry/gles/api/GLES3/gl3platform.h
Signed-off-by: Jordan Justen
---
include/GLES2/gl2ext.h | 91 +++
On 03/31/2014 04:43 PM, Ilia Mirkin wrote:
After getting the docs to build at gallium.rtfd.org, I noticed a lot of
issues. This fixes many of them. the first patch is kind of big, but it was
just a lot of deindenting + Alt-q in emacs. I later realized that that patch
could have been less drastic
On Tue, Apr 1, 2014 at 7:08 AM, Benjamin Bellec wrote:
> As Alex said, this is more like : R600/R700* support GL3.3.
>
> * except original R600 (Radeon HD 2900 series).
>
> I don't know if this can be easily added in your tool or it's even
> important to say here. But I think this information shou
Splitting up the column is a waste of time in my opinion.
Marek
On Mon, Mar 31, 2014 at 8:43 PM, Ilia Mirkin wrote:
> On Mon, Mar 31, 2014 at 2:39 PM, Benjamin Bellec wrote:
>> Hi,
>>
>> Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is
>> not enabled on Radeon HD2900 (R6
As Alex said, this is more like : R600/R700* support GL3.3.
* except original R600 (Radeon HD 2900 series).
I don't know if this can be easily added in your tool or it's even
important to say here. But I think this information should be mentioned
somewhere (on the RadeonFeature web page at least)
According to the spec:
must be RENDERBUFFER and
should be set to the name of the renderbuffer object to be
attached to the framebuffer. must be either
zero or the name of an existing renderbuffer object of type
, otherwise an INVALID_OPERATION error is
https://bugs.freedesktop.org/show_bug.cgi?id=76894
--- Comment #1 from Samuel Iglesias ---
Created attachment 96707
--> https://bugs.freedesktop.org/attachment.cgi?id=96707&action=edit
Patch
This is the patch that changes the returned error value to GL_INVALID_OPERATION
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=76894
Priority: medium
Bug ID: 76894
Assignee: mesa-dev@lists.freedesktop.org
Summary: Piglit/spec/EXT_framebuffer_object/fbo-bind-renderbuff
er failed
Severity: normal
Classif
On 31.03.2014 22:54, Ian Romanick wrote:
Patches 1, 2, and 4 through 9 are
Reviewed-by: Ian Romanick
I sent a comment on patch 3.
The comment on patch 2 is more FYI than anything.
Hi,
I just updated patch 3.
For patch 2, i will squash that commit in future works
and include it with extensio
v2: Add check for desktop gl and ARB_query_buffer_object extension
when returning QueryBuffer in get_buffer_target
Add QueryBuffer and initialise it to NullBufferObj
on start
---
src/mesa/main/bufferobj.c | 8
src/mesa/main/mtypes.h| 2 ++
2 files changed, 10 insertions(+)
diff
v2: Remove c++ comment style
Just return and do nothing if query result is not yet available
---
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..63b2c20 100644
--- a/src/mesa/main/que
62 matches
Mail list logo
