It turns out the MI_LOAD_REGISTER_IMM approach doesn't work on Haswell,
and regressed essentially all the transform feedback Piglit tests.
This morally reverts eaa6fbe6d54dc99efac4ab8e800edef65ce8220d. However,
the code is still simpler than it was. On BeginTransformFeedback, we
simply flush the
https://bugs.freedesktop.org/show_bug.cgi?id=64791
Peter Åstrand changed:
What|Removed |Added
CC||astr...@lysator.liu.se
--
You are recei
On Thu, May 23, 2013 at 2:24 PM, Vinson Lee wrote:
> need_flush was uninitialized if hw3d->new_batch was true.
>
> Fixes "Uninitialized scalar variable" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
Applied, thanks. Now I wonder why gcc did not give me any warning...
> ---
> src/ga
Bump .. could someone please help me with this? Possibly I am missing
something small but can't seem to figure out.
Any help is appreciated.
Divick
On Thu, May 16, 2013 at 12:58 PM, Divick Kishore
wrote:
> Hi,
> I am trying to compile mesa 9.1.1 on my debian wheezy machine but
> I get compil
On 05/23/2013 12:41 AM, Chia-I Wu wrote:
TGSI_TEXTURE_BUFFER is one-dimensional. Assert that exec_tex() is never
called with TGSI_TEXTURE_BUFFER.
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/tgsi/tgsi_exec.c |1 +
src/gallium/auxiliary/tgsi/tgsi_util.c |2 ++
2 files changed,
Hi,
I have written a simple program which shares data like texture and
shaders across two different GLContexts but it doesn't seem to work.
Is sharing of texture and shaders supported in Mesa EGL backend?
I first bind the first context and do the drawing and then I bind the
second context to c
On Thu, May 23, 2013 at 3:39 AM, Divick Kishore
wrote:
> Bump .. could someone please help me with this? Possibly I am missing
> something small but can't seem to figure out.
>
> Any help is appreciated.
> Divick
>
> On Thu, May 16, 2013 at 12:58 PM, Divick Kishore
> wrote:
>> Hi,
>> I am try
busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buffer.
Reported-by: Ilja Van Sprundel
Signed-off-b
The X.Org security team has been notified by a security researcher of bugs in
the protocol handling code across libX11 & many of its extension libraries.
These could be exploited in X clients that are setuid or otherwise running
with raised privileges, if a user could run them with their display se
clientDriverNameLength is a CARD32 and needs to be bounds checked before
adding one to it to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.
Reported-by: Ilja Van Sprundel
Signed-
On 22 May 2013 12:18, Ian Romanick wrote:
> On 05/21/2013 04:52 PM, Paul Berry wrote:
>
>> This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915
>> (pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there
>> is no need for this field in the i915 driver). This should
https://bugs.freedesktop.org/show_bug.cgi?id=64877
--- Comment #6 from Tom Stellard ---
Created attachment 79716
--> https://bugs.freedesktop.org/attachment.cgi?id=79716&action=edit
Possible fix
This patch should fix the bug.
--
You are receiving this mail because:
You are the assignee for t
On 05/23/2013 09:44 AM, Alan Coopersmith wrote:
The X.Org security team has been notified by a security researcher of bugs in
the protocol handling code across libX11 & many of its extension libraries.
These could be exploited in X clients that are setuid or otherwise running
with raised privileg
Paul Berry writes:
> With the advent of fast color clears, it will no longer be safe for
> the driver to access the data stored in a miptree with impunity. For
> example, sometimes a resolve will need to be performed first (to
> ensure that deferred writes due to a fast clear are performed befor
https://bugs.freedesktop.org/show_bug.cgi?id=64877
Aaron Watry changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Tom Stellard
---
generic/include/clc/clc.h | 1 +
generic/include/clc/relational/bitselect.h | 1 +
2 files changed, 2 insertions(+)
create mode 100644 generic/include/clc/relational/bitselect.h
diff --git a/generic/include/clc/clc.h b/generic/include/clc/clc.h
index d28
On 05/23/2013 08:44 AM, Alan Coopersmith wrote:
busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buf
On 23 May 2013 09:57, Eric Anholt wrote:
> Paul Berry writes:
>
> > With the advent of fast color clears, it will no longer be safe for
> > the driver to access the data stored in a miptree with impunity. For
> > example, sometimes a resolve will need to be performed first (to
> > ensure that d
On 22 May 2013 12:21, Ian Romanick wrote:
> On 05/21/2013 04:52 PM, Paul Berry wrote:
>
>> diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
>> b/src/mesa/drivers/dri/i915/i830_vtbl.c
>> index b30f45e..a35f58b 100644
>> --- a/src/mesa/drivers/dri/i915/**i830_vtbl.c
>> +++ b/src/mesa/drivers/dri/
From: Rob Clark
Currently, es2gears, ioquake, xonotic, compiz, etc. work. The
shader compiler is quite sub-optimal, but despite that most things
seem to be ~2-3x faster compared (and at higher resolution) with
the a320 on my nexus4 compared to a220 on my HP touchpad.
Since the patches will prob
On 22 May 2013 12:30, Ian Romanick wrote:
> On 05/21/2013 04:52 PM, Paul Berry wrote:
>
>> Since we defer allocation of the MCS miptree until the time of the
>> fast clear operation, this patch also implements creation of the MCS
>> miptree.
>>
>> In addition, this patch adds the field
>> intel_m
On 22 May 2013 16:32, Eric Anholt wrote:
> Paul Berry writes:
> > diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> > index 9d1b91a..657532f 100644
> > --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/d
On 05/23/2013 09:33 AM, Paul Berry wrote:
On 22 May 2013 12:18, Ian Romanick wrote:
On 05/21/2013 04:52 PM, Paul Berry wrote:
This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915
(pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there
is no need for this field
On 05/23/13 11:07 AM, Ian Romanick wrote:
On 05/23/2013 08:44 AM, Alan Coopersmith wrote:
if (rep.length) {
- if (!(*busIdString = calloc(rep.busIdStringLength + 1, 1))) {
+ if (rep.busIdStringLength < INT_MAX)
+ *busIdString = calloc(rep.busIdStringLength + 1, 1);
But c
On Thu, May 23, 2013 at 11:48 AM, Rob Clark wrote:
> From: Rob Clark
>
> Currently, es2gears, ioquake, xonotic, compiz, etc. work. The
> shader compiler is quite sub-optimal, but despite that most things
> seem to be ~2-3x faster compared (and at higher resolution) with
> the a320 on my nexus4 c
On Thu, May 23, 2013 at 11:48 AM, Rob Clark wrote:
> From: Rob Clark
>
> Currently, es2gears, ioquake, xonotic, compiz, etc. work. The
> shader compiler is quite sub-optimal, but despite that most things
> seem to be ~2-3x faster compared (and at higher resolution) with
> the a320 on my nexus4 c
On Thu, May 23, 2013 at 4:21 PM, Matt Turner wrote:
> On Thu, May 23, 2013 at 11:48 AM, Rob Clark wrote:
>> From: Rob Clark
>>
>> Currently, es2gears, ioquake, xonotic, compiz, etc. work. The
>> shader compiler is quite sub-optimal, but despite that most things
>> seem to be ~2-3x faster compar
This series adds support for multiple viewports/scissors
to gallium and implements it in llvmpipe. All the other
drivers still support just a single viewport/scissor
combo and their behavior should be exactly the same as
it was.
Zack Rusin (4):
gallium: Add support for multiple viewports
draw:
This adds support for multiple viewports to the draw module.
Multiple viewports depend on the presence of geometry shaders
which can write the viewport index.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_cliptest_tmp.h | 10 -
src/gallium/auxiliary/draw/draw_context.c
in case a driver supports multiple viewports the blitter needs
to be able to restore all of them and not just the first one.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/util/u_blitter.c |6 +++--
src/gallium/auxiliary/util/u_blitter.h | 24 +-
Largely related to making sure the rasterizer can correctly
pick out the correct scissor box for the current viewport.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_context.h |9 --
src/gallium/drivers/llvmpipe/lp_screen.c|2 +-
src/gallium/drivers/llvmp
Am 23.05.2013 22:33, schrieb Zack Rusin:
> Gallium supported only a single viewport/scissor combination. This
> commit changes the interface to allow us to add support for multiple
> viewports/scissors.
>
> Signed-off-by: Zack Rusin
> ---
> diff --git a/src/gallium/include/pipe/p_context.h
> b/s
1) I prefer this interface instead:
void (*set_scissor_states)( struct pipe_context *,
unsigned start_slot, unsigned count,
const struct pipe_scissor_state * );
void (*set_viewport_states)( struct pipe_context *,
Am 23.05.2013 22:33, schrieb Zack Rusin:
> Largely related to making sure the rasterizer can correctly
> pick out the correct scissor box for the current viewport.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/drivers/llvmpipe/lp_context.h |9 --
> src/gallium/drivers/llvmpipe/
Same as the the first patch: u_blitter doesn't really need to change
more than one scissor and viewport. With the start_slot parameter in
set_viewport_states and set_scissor_states, you can just save, set,
and restore the first slot. Note that the same approach is also used
for the vertex buffer (o
> 1) I prefer this interface instead:
>
> void (*set_scissor_states)( struct pipe_context *,
>unsigned start_slot, unsigned count,
>const struct pipe_scissor_state * );
>
> void (*set_viewport_states)( struct pipe_context *,
>
> Same as the the first patch: u_blitter doesn't really need to change
> more than one scissor and viewport. With the start_slot parameter in
> set_viewport_states and set_scissor_states, you can just save, set,
> and restore the first slot. Note that the same approach is also used
> for the vertex
Reviewed-by: Aaron Watry
Please also send the attached test patch (or an expanded version of
it) to the piglit list.
On Thu, May 23, 2013 at 12:48 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> generic/include/clc/clc.h | 1 +
> generic/include/clc/relational/bitselec
On Thu, May 23, 2013 at 11:59 PM, Zack Rusin wrote:
>> 1) I prefer this interface instead:
>>
>> void (*set_scissor_states)( struct pipe_context *,
>>unsigned start_slot, unsigned count,
>>const struct pipe_scissor_state * );
>>
>> vo
According to the documentation: "The Cut Index is compared to the
fetched (and possibly-sign-extended) vertex index, and if these values
are equal, the current primitive topology is terminated. Note that,
for index buffers <32bpp, it is possible to set the Cut Index to a
(large) value that will ne
On Thu, May 23, 2013 at 3:46 PM, Kenneth Graunke wrote:
> According to the documentation: "The Cut Index is compared to the
> fetched (and possibly-sign-extended) vertex index, and if these values
> are equal, the current primitive topology is terminated. Note that,
> for index buffers <32bpp, it
On 23 May 2013 15:46, Kenneth Graunke wrote:
> According to the documentation: "The Cut Index is compared to the
> fetched (and possibly-sign-extended) vertex index, and if these values
> are equal, the current primitive topology is terminated. Note that,
> for index buffers <32bpp, it is possib
That wouldn't be an issue if there were the start_slot parameter in
the first place. The hardware viewport count is always 16, I don't
think that can be changed. (my radeon hardware docs seem to suggest it
really can't). OpenGL doesn't provide a way to specify the viewport
count either. (even the l
Paul Berry writes:
> On 22 May 2013 12:30, Ian Romanick wrote:
>
>> On 05/21/2013 04:52 PM, Paul Berry wrote:
>>
>>> Since we defer allocation of the MCS miptree until the time of the
>>> fast clear operation, this patch also implements creation of the MCS
>>> miptree.
>>>
>>> In addition, this
I've implemented the OpenCL vload/vstore builtin functions in two parts.
1) Pure CL C implementation. No Assembly
2) Add assembly optimizations for 32-bit int/uint loads/stores of 4+ component
vectors
Note: The vstore implementation assumes that the hardware back end supports
byte-addressable s
Should work for all targets and data types. Completely unoptimized.
---
generic/include/clc/clc.h | 1 +
generic/include/clc/shared/vload.h | 37 ++
generic/lib/SOURCES| 1 +
generic/lib/shared/vload.cl| 47 +++
Assumes that the target supports byte-addressable stores.
Completely unoptimized.
---
generic/include/clc/clc.h | 1 +
generic/include/clc/shared/vstore.h | 36
generic/lib/SOURCES | 1 +
generic/lib/shared/vstore.cl| 56 +++
The assembly should be generic, but at least currently R600 only supports
32-bit loads of int1/4, and I believe that only global is well-supported.
R600 lowers the 8/16 component vectors to multiple 4-bit loads.
The unoptimized C versions of the other stuff is left in place.
---
generic/lib/SOUR
The assembly should be generic, but at least currently R600 only supports
32-bit stores of [u]int1/4, and I believe that only global is well-supported.
R600 lowers the 8/16 component stores to multiple 4-component stores.
The unoptimized C versions of the other stuff is left in place.
---
generi
https://bugs.freedesktop.org/show_bug.cgi?id=64934
Priority: medium
Bug ID: 64934
Keywords: have-backtrace
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] SIGSEGV
src/gallium/state_trackers/glx/xlib/glx_api.c:136
https://bugs.freedesktop.org/show_bug.cgi?id=64935
Priority: medium
Bug ID: 64935
Keywords: have-backtrace, regression
CC: e...@anholt.net
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] s_texfetch.c:1335: set_fetch_fu
Hi Matt,
On Thu, May 23, 2013 at 8:38 PM, Matt Turner wrote:
> On Thu, May 23, 2013 at 3:39 AM, Divick Kishore
>>>
>>> Could someone please help me build mesa 9.1.1?
>
> I think this is a build system bug caused by not building any classic
> hardware DRI drivers. Try --with-dri-drivers=i965,swras
When touching the src/egl/drivers/dri2 directory, use a commit subject
that looks like "egl/dri2: STUFF", not "egl: dri2: STUFF".
On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
v2:
- upon success close the given file descriptors
v3:
- use specific entry for dma buffers instead of the b
On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
As specified in:
http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
Checking for the valid fourcc values is left for drivers avoiding
dependency to drm header files here.
v2:
- enforce EGL_NO_CONTEXT
v3:
On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
v2 (as advised by Eric):
- use ARRAY_SIZE
- re-use 'image_destroy' for cleaning up after failure
- check directly the region pointer instead of the buffer object
when determining if a region exists
Signed-off-by: Topi Pohjolainen
On 05/21/2013 11:17 PM, Pohjolainen, Topi wrote:
On Tue, May 21, 2013 at 10:11:17PM -0700, Chad Versace wrote:
On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
No functional change in preparation for supporting multiple planes
per image each having its own region.
Signed-off-by: Topi Pohjolaine
On Thu, May 23, 2013 at 8:04 PM, Divick Kishore
wrote:
> Hi Matt,
>
> On Thu, May 23, 2013 at 8:38 PM, Matt Turner wrote:
>> On Thu, May 23, 2013 at 3:39 AM, Divick Kishore
Could someone please help me build mesa 9.1.1?
>>
>> I think this is a build system bug caused by not building any
On Thu, May 23, 2013 at 09:39:30PM -0700, Chad Versace wrote:
> When touching the src/egl/drivers/dri2 directory, use a commit subject
> that looks like "egl/dri2: STUFF", not "egl: dri2: STUFF".
>
> On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
> >v2:
> >- upon success close the given file
On Thu, May 23, 2013 at 09:40:09PM -0700, Chad Versace wrote:
> On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
> >As specified in:
> >
> >http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> >
> >Checking for the valid fourcc values is left for drivers avoiding
> >
Fixes "Uninitialized pointer field" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/glsl/lower_named_interface_blocks.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/lower_named_interface_blocks.cpp
b/src/glsl/lower_named_interface_blocks.cpp
in
Hi Matt,
> From the "build" in your path, it looks like you might be trying to do
> an out-of-tree build. I don't remember if that completely worked with
> 9.1.
>
> I just untarred 9.1.3 and did
>
> libtoolize --force
> ./autogen.sh --with-dri-drivers=i965,swrast
> --with-gallium-drivers=swrast --
61 matches
Mail list logo
