Am 27.08.2014 um 05:09 schrieb Alex Deucher:
It doesn't seem to support field based decode after testing.
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
src/gallium/drivers/radeon/radeon_video.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/
Hi,
This one liner should apply on top of master and the two release branches. It
fixes 'black windows' when importing prime fds on gpus using the i915 driver
paths.
regards
Andreas
Andreas Pokorny (1):
i915: Fix black buffers when importing prime fds
src/mesa/drivers/dri/i915/intel_screen.
Width and Height of the imported image was never initialized from the
imported bo.
Signed-off-by: Andreas Pokorny
---
src/mesa/drivers/dri/i915/intel_screen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.
Hi,
This one liner should apply on top of master and the two release branches. It
fixes 'black windows' when importing prime fds on gpus using the i915 driver
paths.
PS: Sorry for sending again I missed the 10.3 tag
regards
Andreas
Andreas Pokorny (1):
i915: Fix black buffers when importing
From: Michel Dänzer
Not all of these are used in every context, so this can make a
significant difference for short-lived contexts such as in piglit tests.
Signed-off-by: Michel Dänzer
---
src/gallium/auxiliary/util/u_blitter.c | 147 +++--
1 file changed, 104 inser
From: Michel Dänzer
It's never used under normal circumstances.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_pipe.c | 7 ---
src/gallium/drivers/radeonsi/si_state.c | 11 ++-
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/r
These two patches reduce the runtime of piglit gpu.py from around 12
minutes to around 8 minutes for me with radeonsi.
[PATCH 1/2] u_blitter: Create all shaders on demand
[PATCH 2/2] radeonsi: Compile dummy pixel shader on demand
___
mesa-dev mailing lis
Patch fixes the slot count used by vector types and adds 1 slot
to be used by image and sampler types.
Signed-off-by: Tapani Pälli
https://bugs.freedesktop.org/show_bug.cgi?id=82921
---
src/glsl/glsl_types.cpp | 18 +-
src/glsl/glsl_types.h | 3 +++
2 files changed, 12 inserti
On 08/26/2014 10:37 PM, Ian Romanick wrote:
> On 08/23/2014 07:51 AM, Micael wrote:
>> On second thought, the glsl_type::uniform_locations() method comment in
>> the header file says:
>> /**
>> * Calculate the number of unique values from glGetUniformLocation for the
>> * elements of the type.
>>
On 27/08/14 03:01, Michel Dänzer wrote:
> On 27.08.2014 05:57, Emil Velikov wrote:
>> On 18/08/14 22:52, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>> Hi Marek,
>>
>> Going through the mesa 10.2 patches queue and I cannot see this one ever
>> making to the list despite the Cc tag. Are you sendin
On 27/08/14 07:05, Dave Airlie wrote:
> I think Tom cc'ed the wrong stable maybe, not sure,
>
> 10.2 doesn't have PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE, so this
> doesn't even build.
>
> You might want to get a build system that builds all the drivers
> before applying and fixing up patches.
>
T
On 08/08/14 15:16, Tom Stellard wrote:
> There is a hard limit in older kernels of 256 MB for buffer allocations,
> so report this value as MAX_MEM_ALLOC_SIZE and adjust MAX_GLOBAL_SIZE
> to statisfy requirements of OpenCL.
>
Hi Tom,
Following Dave's report I've gone through the series and pulled
If I wanted to send my email to mesa-stable, I would send it to
mesa-stable. If I want to mark a commit as a candidate for stable, I
add the Cc line, which doesn't have to be done for emails sent to
mesa-stable.
I set up git to ignore email addresses in my commit messages.
Marek
On Tue, Aug 26,
On Tue, 2014-08-26 at 15:44 -0700, Kenneth Graunke wrote:
> On Friday, August 22, 2014 12:59:57 PM Samuel Iglesias Gonsálvez wrote:
> > On Thu, 2014-08-14 at 14:28 +0200, Iago Toral Quiroga wrote:
> > [...]
> > > At this point I'd like to hear suggestions for things we could try next
> > > to confi
https://bugs.freedesktop.org/show_bug.cgi?id=83149
Priority: medium
Bug ID: 83149
Assignee: mesa-dev@lists.freedesktop.org
Summary: Syntax error in setup_glsl_blit_framebuffer() with
VS2012
Severity: critical
Classificati
* IEEE Std 1003.1-2001 placed strcasecmp() in strings.h.
* On a lot of platforms, strcasecmp is in strings.h and string.h
* Technically strcasecmp should be only in strings.h
* Haiku decided to stop providing strcasecmp in string.h as it
is a crutch to code looking in the wrong place.
---
src/gl
On 26/08/14 18:59, Matt Turner wrote:
On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca wrote:
If LLVM was a useless piece of junk, we wouldn't have any trouble adding it
as a dependency, as we would be the sole user. But precisely because LLVM
is successful in so many use cases, hence several pac
On Wednesday, August 27, 2014 11:35:06 AM Alexander von Gluck IV wrote:
> * IEEE Std 1003.1-2001 placed strcasecmp() in strings.h.
> * On a lot of platforms, strcasecmp is in strings.h and string.h
> * Technically strcasecmp should be only in strings.h
> * Haiku decided to stop providing strcasecmp
On , Kenneth Graunke wrote:
On Wednesday, August 27, 2014 11:35:06 AM Alexander von Gluck IV wrote:
* IEEE Std 1003.1-2001 placed strcasecmp() in strings.h.
* On a lot of platforms, strcasecmp is in strings.h and string.h
* Technically strcasecmp should be only in strings.h
* Haiku decided to st
Any comments on this patch from the gallium devs?
On Tue, 2014-08-19 at 22:14 -1000, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri
> ---
> Note: I have only compile tested this patch with ilo.
>
> src/gallium/docs/source/screen.rst | 1 +
> src/gallium/drivers/freedreno/f
Hi,
If Mesa used an LLVM IR for it's shader compiler stack, it would most likely
- Pick a specific shipped version. Shipped versions are stable and
unchanging. Upgrading to a newer version would be done only by choice, on
Mesa's schedule.
- Not bring the source into mesa: it works p
Note that it is easy to add swizzle, saturate, clamp, etc. intrinsics to
LLVM IR. Going a step further, LunarGLASS adds these, and then asks the
current back end what it would like to see (back-end queries).
If a back end says it likes a particular form, then LunarGLASS can
transform the LLVM IR
On Wed, Aug 27, 2014 at 2:26 PM, John Kessenich wrote:
> Hi,
>
> If Mesa used an LLVM IR for it's shader compiler stack, it would most likely
>
> Pick a specific shipped version. Shipped versions are stable and
> unchanging. Upgrading to a newer version would be done only by choice, on
> Mesa's
On Wednesday, August 27, 2014 01:00:08 PM Alexander von Gluck IV wrote:
> On , Kenneth Graunke wrote:
> > On Wednesday, August 27, 2014 11:35:06 AM Alexander von Gluck IV wrote:
> >> * IEEE Std 1003.1-2001 placed strcasecmp() in strings.h.
> >> * On a lot of platforms, strcasecmp is in strings.h an
Interesting points Jose. It turns LLVM IR is an IR that works well for
both uses. Slicing it a bit differently, if you were to look at just a
"binary language" (that is, not a "binary representation"), it is
a) the *language* is good for communicating between different layers
b) the *representa
Hi Connor,
Lots of good work in defining a new IR.
I would like to address the LLVM issues: LunarG's LunarGLASS conventions
on LLVM IR generally solve these problems: It has algorithms to re-deduce
structured control flow, and if you just want to use LLVM IR as an
intermediate language, it could
On Wed, Aug 27, 2014 at 2:26 PM, John Kessenich wrote:
> Hi,
>
> If Mesa used an LLVM IR for it's shader compiler stack, it would most likely
>
> Pick a specific shipped version. Shipped versions are stable and
> unchanging. Upgrading to a newer version would be done only by choice, on
> Mesa's
Reviewed-by: Roland Scheidegger
Though I think most drivers can probably support a lot more (everything
draw based should be able to support virtually unlimited strides I
believe, up to max_int32 probably though this doesn't make much sense,
and I suspect that's true for all d3d10-level hw).
It i
* IEEE Std 1003.1-2001 placed strcasecmp() in strings.h.
* ISO C99 doesn't mention strcase* in string.h
* On all platforms I could find, strcasecmp is in strings.h and string.h
as a compatibility layer for software written pre-2001 POSIX
* Technically strcasecmp should be only in strings.h and th
From: Paul Berry
This will make it easier to extend dirty bit handling to support
compute shaders.
Reviewed-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_context.h | 11 +++
src/mesa/drivers/dri/i965/brw_state_cache.c
From: Paul Berry
Also add code to brw_upload_state to set it when the compute program
changes.
Reviewed-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.h | 3 +++
src/mesa/drivers/dri/i965/brw_state_upload.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/src/mesa/d
These are mostly from Paul's cs branch, rebased, and all of Paul's
patches are r-b me. (Leaving only patch 6 needing an r-b.)
No piglit changes seen on gen7.
git://people.freedesktop.org/~jljusten/mesa cs-for-upstream
Jordan Justen (1):
i965: Convert brw state dirty bits to 64-bits
Paul Berry
From: Paul Berry
The set of state atoms for compute shaders is currently empty; it will
be filled in by future patches.
Reviewed-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.h | 4 +--
src/mesa/drivers/dri/i965/brw_state_upload.c | 53
2 files
From: Paul Berry
The hardware state for compute shaders is almost entirely orthogonal
to the hardware state for 3D rendering. To avoid sending unnecessary
state to the hardware, we'll need to have a separate set of state
atoms for the compute pipeline and the 3D pipeline. That means we
need to
We will have more that 32 bits when COMPUTE_PROGRAM is added.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_context.h | 16 +++-
src/mesa/drivers/dri/i965/brw_state_cache.c | 2 +-
src/mesa/drivers/dri/i965
From: Paul Berry
Reviewed-by: Jordan Justen
---
src/mesa/main/mtypes.h | 20
1 file changed, 20 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index cb2a4df..13cdf73 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2351,6 +23
From: Paul Berry
This will make it easier to extend dirty bit handling to support
compute shaders.
Reviewed-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_binding_tables.c| 2 +-
src/mesa/drivers/dri/i965/brw_cc.c| 4 ++--
src/mesa/drivers/dri/i965/brw_clip_state.c
From: Paul Berry
This will make it easier to extend dirty bit handling to support
compute shaders.
Reviewed-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.h | 6 ++
src/mesa/drivers/dri/i965/brw_vec4_gs.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/sr
Our plan is to always require the latest released version of LLVM
because of new features in our LLVM backend that the radeonsi driver
depends on to advertise all GL features. Some new features listed for
the radeonsi driver in Mesa release notes are only enabled if you have
latest LLVM from git/sv
Signed-off-by: Jordan Justen
---
docs/GL3.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 0d884c6..c7dd62a 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -149,7 +149,7 @@ GL 4.3, GLSL 4.30:
GL_ARB_arrays_of_arrays
On 08/27/2014 02:55 PM, Marek Olšák wrote:
> Our plan is to always require the latest released version of LLVM
> because of new features in our LLVM backend that the radeonsi driver
> depends on to advertise all GL features. Some new features listed for
> the radeonsi driver in Mesa release notes a
On 08/27/2014 02:30 PM, Jordan Justen wrote:
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 602275c..7475135 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -241,6 +241,13 @@ str
On 08/27/2014 02:30 PM, Jordan Justen wrote:
> From: Paul Berry
>
> The hardware state for compute shaders is almost entirely orthogonal
> to the hardware state for 3D rendering. To avoid sending unnecessary
> state to the hardware, we'll need to have a separate set of state
> atoms for the comp
On 08/27/2014 02:30 PM, Jordan Justen wrote:
> We will have more that 32 bits when COMPUTE_PROGRAM is added.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 +-
> src/mesa/drivers/dri/i965/brw_context.h | 16 +++-
> src/mesa/drivers/dri
On 08/27/2014 02:30 PM, Jordan Justen wrote:
> From: Paul Berry
>
> Reviewed-by: Jordan Justen
> ---
> src/mesa/main/mtypes.h | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index cb2a4df..13cdf73 100644
> --- a/s
On 2014-07-30 10:03:56, Topi Pohjolainen wrote:
> First five patches refactor common decision making found in depth,
> texture and renderbuffer surface setup logic.
>
> In principle, there is opportunity to share code between texture and
> renderbuffer setup logic (Kenneth has experimented with th
I am getting another error regarding explicit locations, which I believe
has a one-line fix. If I only have a single uniform in my shader, and that
uniform is explicitely given location 1 (or anything above zero), my
program will crash if I attempt to give the unnassigned locs a value with
glProgra
On Wed, 2014-08-27 at 22:00 +0200, Roland Scheidegger wrote:
> Reviewed-by: Roland Scheidegger
>
> Though I think most drivers can probably support a lot more
Yeah I figure driver maintainers can just adjust it later on if they are
not happy with the default.
> (everything
> draw based should
From: Roland Scheidegger
Just handle as ordinary 2d / 2d array resources. Prevents an assertion failure
with softpipe and piglit glsl-resource-not-bound 2DMS/2DMSArray tests.
While here also fix TXD shadowCube similarly, which fixes the crash with piglit
tex-miplevel-selection textureGrad CubeSha
From: Roland Scheidegger
piglit tex-miplevel-selection nowadays doesn't use repeat wrap mode due to
sampler objects any longer, however at the time of the clear the wrap mode
is still illegal and at this point we get to verify the state, including
samplers (even though they won't get used), and b
From: Roland Scheidegger
This was meant for softpipe to not crash at some point if vertex texturing
was used. It is, however, fishy because it uses values from
draw_set_samplers/draw_set_sampler_views and not from the shader key. Albeit
we should still in all cases actually generate a new shader
From: Roland Scheidegger
Not sure why it was there but it is definitely not an error if gs outputs are
infs/nans. Besides, the outputs can be ints, in which case any small negative
number asserted.
This fixes piglit's texelFetch gs isamplerXX crashes with softpipe (down from
14 to 2).
Bug https:
On Wednesday, August 27, 2014 04:55:37 PM Alexander von Gluck IV wrote:
> * IEEE Std 1003.1-2001 placed strcasecmp() in strings.h.
> * ISO C99 doesn't mention strcase* in string.h
> * On all platforms I could find, strcasecmp is in strings.h and string.h
> as a compatibility layer for software wr
> So, I don't suppose it is possible to have multiple side-by-side llvm's?
They each go in their own subdirectory, with the version number in the path.
> I don't really look forward to having to recompile llvm when switching
between branches.
LLVM would sit next to mesa, fully compiled, as many
On Wed, Aug 27, 2014 at 3:10 PM, Ian Romanick wrote:
> On 08/27/2014 02:30 PM, Jordan Justen wrote:
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
>> b/src/mesa/drivers/dri/i965/brw_context.h
>> index 602275c..7475135 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.h
>> +++ b/src/m
r-b with these changes?
By the way, chrisf pointed out on irc that we should extend
ctx->NewDriverState to 64-bit as well. I'll look into that, but I
don't think it needs to block this change. Although, I'd be willing to
pull that in here as well if anyone prefers it.
-Jordan
On Wed, Aug 27, 201
* Check for back left attachment as well
* Set and act on pipe format none
---
.../targets/haiku-softpipe/GalliumFramebuffer.cpp | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
b/src/gallium/ta
---
src/gallium/SConscript |1 +
src/gallium/state_trackers/hgl/SConscript | 23 +++
src/gallium/state_trackers/hgl/bitmap_wrapper.cpp | 146 +++
src/gallium/state_trackers/hgl/bitmap_wrapper.h| 62 +++
src/gallium/state_trackers/h
On Wednesday, August 27, 2014 05:10:36 PM Jordan Justen wrote:
> r-b with these changes?
>
> By the way, chrisf pointed out on irc that we should extend
> ctx->NewDriverState to 64-bit as well. I'll look into that, but I
> don't think it needs to block this change. Although, I'd be willing to
> pu
On Wed, Aug 27, 2014 at 5:41 PM, Kenneth Graunke wrote:
> On Wednesday, August 27, 2014 05:10:36 PM Jordan Justen wrote:
>> r-b with these changes?
>>
>> By the way, chrisf pointed out on irc that we should extend
>> ctx->NewDriverState to 64-bit as well. I'll look into that, but I
>> don't think
From: Roland Scheidegger
mesa was creating a cube map array texture with just one layer, which is
not legal. This caused an assertion failure when using that texture later
in llvmpipe (when enabling cube map arrays) since it verifies the number
of layers in the view is divisible by 6 (the samplin
On 27.08.2014 20:30, Emil Velikov wrote:
On 27/08/14 03:01, Michel Dänzer wrote:
On 27.08.2014 05:57, Emil Velikov wrote:
On 18/08/14 22:52, Marek Olšák wrote:
From: Marek Olšák
Hi Marek,
Going through the mesa 10.2 patches queue and I cannot see this one ever
making to the list despite th
Reviewed-by: Ian Romanick
On 08/27/2014 06:00 PM, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> mesa was creating a cube map array texture with just one layer, which is
> not legal. This caused an assertion failure when using that texture later
> in llvmpipe (when enabling cube map a
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index d351bc5..7bca0
From: Roland Scheidegger
The code is all in place now so enable it.
Seems to pass all relevant piglit tests (just like cube maps, some of the
cube map array tests need GALLIVM_DEBUG=no_quad_lod,no_rho_approx)
---
docs/GL3.txt | 2 +-
src/gallium/drivers/llvmpipe/lp_sc
From: Roland Scheidegger
Pretty trivial, just fill in the offsets and such. The implementation
is near 100% copy and paste from llvmpipe. Should be useful for debugging.
No piglit change when not using SOFTPIPE_USE_LLVM=1.
Now that it can do the same tests with and without using llvm for vs/gs,
From: Roland Scheidegger
Pretty easy, just make sure that all paths testing for PIPE_TEXTURE_CUBE
also recognize PIPE_TEXTURE_CUBE_ARRAY, and add the layer * 6 calculation
to the calculated face.
Also handle it for texture size query, looks like OpenGL wants the number
of cubes, not layers (so ne
On 21.08.2014 18:10, Henri Verbeet wrote:
On 21 August 2014 04:56, Michel Dänzer wrote:
On 21.08.2014 04:29, Henri Verbeet wrote:
For whatever it's worth, I have been avoiding radeonsi in part because
of the LLVM dependency. Some of the other issues already mentioned
aside, I also think it mak
On Wednesday, August 27, 2014 02:30:16 PM Jordan Justen wrote:
> From: Paul Berry
>
> Reviewed-by: Jordan Justen
> ---
> src/mesa/main/mtypes.h | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index cb2a4df..13cdf7
i965 will have more than 32 bits when BRW_STATE_COMPUTE_PROGRAM is added.
Signed-off-by: Jordan Justen
---
Ken,
How about this to replace "i965: Convert brw state dirty bits to
64-bits"?
-Jordan
src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_context.h
From: Michel Dänzer
Pointed out by valgrind.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83148
Signed-off-by: Michel Dänzer
---
src/gallium/auxiliary/util/u_vbuf.c | 40 +++--
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/src/gallium
Michel Dänzer writes:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/
From: Michel Dänzer
Putting those in VRAM seems to cause (worse) stutter in Unigine Valley on
some systems.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82050
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeon/r600_buffer_common.c | 4 +++-
1 file changed, 3 insertions(+), 1
On 08/28/2014 01:50 AM, Micael wrote:
> I am getting another error regarding explicit locations, which I
> believe has a one-line fix. If I only have a single uniform in my
> shader, and that uniform is explicitely given location 1 (or anything
> above zero), my program will crash if I attempt to g
From: Michel Dänzer
This allows the kernel to prevent such BOs from ever being stored in the
CPU inaccessible part of VRAM.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeon/r600_buffer_common.c | 23 ++-
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 8 ++
From: Michel Dänzer
This flag is a hint that userspace expects the BO to be accessed by the
CPU. We can use that hint to prevent such BOs from ever being stored in
the CPU inaccessible part of VRAM.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 11 +--
inclu
76 matches
Mail list logo
