On 08/28/2013 05:22 PM, Matt Turner wrote:
Existed since the initial import, but appear to never have actually
existed.
---
Rotate?
src/mesa/drivers/dri/i965/brw_defines.h | 2 --
src/mesa/drivers/dri/i965/brw_eu.h | 2 --
src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 --
src/mesa/dri
On 08/26/2013 03:12 PM, Paul Berry wrote:
[snip]
[PATCH 01/22] i965: rename legacy gs structs and functions to ff_gs.
[PATCH 02/22] i965: Rename user-defined gs structs from vec4_gs to gs.
[PATCH 03/22] i965: Move vec4 register allocation data structures to brw->vec4.
[PATCH 04/22] i965/gs: Updat
On 08/26/2013 03:12 PM, Paul Berry wrote:
Previously, we gave all of the URB space (other than the small amount
that is used for push constants) to the vertex shader. However, when
a geometry shader is active, we need to divide it up between the
vertex and geometry shaders.
The size of the URB
On 08/26/2013 03:12 PM, Paul Berry wrote:
---
src/mesa/drivers/dri/i965/brw_state.h | 41 ++
src/mesa/drivers/dri/i965/gen7_vs_state.c | 123 --
2 files changed, 122 insertions(+), 42 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/
On 08/26/2013 03:12 PM, Paul Berry wrote:
Dword 2 of all 3DSTATE commands is the same, so there's no need tohave
Well, not -all- 3DSTATE commands...just these :)
It's weird that you decided to share the bits for 3DSTATE_VS,
3DSTATE_GS, and 3DSTATE_WM on SNB, but not GEN7_PS_* for 3DSTATE_PS o
On 08/26/2013 03:12 PM, Paul Berry wrote:
This patch implements pull constant upload, binding table upload, and
surface setup for geometry shaders, by re-using vertex shader code
that was generalized in previous patches.
Based on work by Eric Anholt .
This looks a lot better than the previous
On 08/26/2013 03:12 PM, Paul Berry wrote:
---
src/mesa/drivers/dri/i965/brw_state.h| 8 +++
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 66 +++-
2 files changed, 50 insertions(+), 24 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/sr
On 08/26/2013 03:12 PM, Paul Berry wrote:
Previously, we would always use the same push constant allocation
regardless of what shader programs were being run: the available push
constant space was split into 2 equal size partitions, one for the
vertex shader, and one for the fragment shader.
Now
On 08/26/2013 03:12 PM, Paul Berry wrote:
The hardware requires that after constant buffers for a stage are
allocated using a 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS}
command, and prior to execution of a 3DPRIMITIVE, the corresponding
stage's constant buffers must be reprogrammed using a
3DST
Am Dienstag, den 13.08.2013, 20:14 +0200 schrieb Christoph Bumiller:
> On 13.08.2013 19:04, srol...@vmware.com wrote:
> > From: Roland Scheidegger
> >
> > untested.
>
> Looks like it should work though, thanks.
> nv50 only supported u32 result all along and on nvc0 both cases are
> already handle
Existed since the initial import, but appears to never have actually
existed.
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 7e5be2a..21c8baa 100644
--- a/src/me
Existed since the initial import, but appear to never have actually
existed.
---
Rotate?
src/mesa/drivers/dri/i965/brw_defines.h | 2 --
src/mesa/drivers/dri/i965/brw_eu.h | 2 --
src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 --
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 --
4 files chan
On 08/26/2013 03:12 PM, Paul Berry wrote:
This paves the way for sharing the code that will set up the vertex
and geometry shader pipeline state.
---
src/mesa/drivers/dri/i965/brw_context.h | 47 ++--
src/mesa/drivers/dri/i965/brw_draw.c | 3 +-
src/m
On 08/27/2013 12:52 PM, Anuj Phogat wrote:
> On Tue, Aug 27, 2013 at 11:53 AM, Ian Romanick wrote:
>> On 08/27/2013 10:45 AM, Anuj Phogat wrote:
>>>
>>> GLSL 1.30 doesn't allow precision qualifiers on sampler types,
>>> but in GLSL ES, sampler types are also allowed. This seems like
>>> an oversig
The main GL context's swtnl_im field is the VBO module's vbo_context
structure. Using the name "swtnl" in the name is confusing since
some drivers use hardware texturing and lighting, but still rely on the
VBO module for drawing.
v2: Forward declare the type and use that instead of void *
(su
Some drawing functions take a single _mesa_prim object, while others
take an array of primitives. Both kinds of functions used a parameter
called "prim" (the singular form), which was confusing.
Using the plural form, "prims," clearly communicates that the parameter
is an array of primitives.
Si
can_cut_index_handle_prims() was passed an array of _mesa_prim objects
and a count, and runs a loop for that many iterations. However, it
treats the array like a pointer, repeatedly checking the first element.
This is wasteful and bizarre.
The VBO module will never call us with multiple primitiv
The VBO module actually calls us with an array of _mesa_prim objects.
For example, it may break up a DrawArrays() call into multiple
primitives when primitive restart is enabled.
Previously, we treated prim like a pointer, always accessing element 0.
This worked because all of the primitive object
These functions have almost identical code; the only difference is that
a few of the bits moved around. Adding a few trivial conditionals
allows the same function to work on all generations, and the resulting
code is still quite readable.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/
---
src/mesa/drivers/dri/i965/brw_context.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index c456e61..3cb6dc6 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_c
From: Roland Scheidegger
Since we can have per-pixel lod we should also honor the filter per-pixel
(in fact we didn't honor it per quad neither in the multiple quad case).
Do this by running the linear path and simply beating the weights into shape
(the sample with the higher weight is the one wh
Am 29.08.2013 01:14, schrieb Brian Paul:
> The previous point/line/triangle() functions didn't handle GS primitives.
> ---
> src/gallium/auxiliary/draw/draw_pipe_validate.c | 31
> +--
> 1 file changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/src/gallium/auxiliary
Kenneth Graunke writes:
> It is incorrect to assume that src[0] of a SEND-from-GRF opcode is the GRF.
> VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 uses an IMM as src[0], and stores the
> GRF as src[1].
>
> To be safe, loop over all the source registers and mark any GRFs. We
> probably won't ever have mor
The previous point/line/triangle() functions didn't handle GS primitives.
---
src/gallium/auxiliary/draw/draw_pipe_validate.c | 31 +--
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_validate.c
b/src/gallium/auxiliary/draw
On 08/28/2013 03:27 PM, Eric Anholt wrote:
This avoids the need to get the inter- and intra-tile offset and adjust
our miptree info based on them.
---
src/mesa/drivers/dri/i965/gen7_sampler_state.c| 19 +--
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 14 +++-
Paul Berry writes:
> On 27 August 2013 15:21, Eric Anholt wrote:
>
>> This brings over the batch-wrap-prevention and aperture space checking
>> code from the normal brw_draw.c path, so that we don't need to flush the
>> batch every time.
>>
>> There's a risk here if the intel_emit_post_sync_nonz
Thanks to Ken for trawling through my neglected public branches and
finding the bug in this change (inside a megacommit) that made me abandon
this work.
---
src/mesa/drivers/dri/i965/brw_wm_sampler_state.c | 19 +--
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 +++-
This avoids the need to get the inter- and intra-tile offset and adjust
our miptree info based on them.
---
src/mesa/drivers/dri/i965/gen7_sampler_state.c| 19 +--
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 14 +++---
2 files changed, 12 insertions(+), 21 delet
LGTM.
Jose
- Original Message -
> From: Roland Scheidegger
>
> This is just preparation for per-pixel (or per-quad in case of multiple
> quads)
> min/mag filter since some assumptions about number of miplevels being equal
> to number of lods no longer holds true.
> This change does not
Fixes a bug where if an uniform array is passed to a function the accesses
to the array are not propagated so later all but the first vector of the
uniform array are removed in parcel_out_uniform_storage resulting in
broken shaders and out of bounds access to arrays in
brw::vec4_visitor::pack_unifo
The changes look good to me... That seems to be a much more sane way
to add the item to the beginning of the linked list.
I've tested this on CEDAR (Radeon 5400) without any OpenCL
regressions, and the only piglit change was that the new piglit test
created for this bug now passes.
--Aaron
On T
It is incorrect to assume that src[0] of a SEND-from-GRF opcode is the
GRF. For example, FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD uses src[1] for
the GRF.
To be safe, loop over all the source registers and mark any GRFs. We
probably won't ever have more than one, but it's simpler to just check
all t
It is incorrect to assume that src[0] of a SEND-from-GRF opcode is the GRF.
VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 uses an IMM as src[0], and stores the
GRF as src[1].
To be safe, loop over all the source registers and mark any GRFs. We
probably won't ever have more than one, but it's simpler to just
On Wed, Aug 28, 2013 at 7:56 PM, Vadim Girlin wrote:
> On 08/28/2013 01:15 PM, Christian König wrote:
>>
>> Well, for this discussion let's just assume that we fixed the delay in
>> the upper layers of the stack and the driver sees the shader code as
>> soon as the application (if I understood it
It looks like this patch got stuck in the moderation queue. You can
also find it here:
http://cgit.freedesktop.org/~mareko/mesa/commit/?h=radeonsi-stuff&id=13bb26b24e738da6a8c51ee33876dc541fcde9da
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedeskt
On 08/28/2013 01:15 PM, Christian König wrote:
Well, for this discussion let's just assume that we fixed the delay in
the upper layers of the stack and the driver sees the shader code as
soon as the application (if I understood it correctly Vadim has just
volunteered for the job).
No, I'm not r
---
src/mesa/vbo/vbo_exec.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index 9c20bde..aa2c7b0 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -149,6 +149,18 @@ vbo_count_tessellated_primitives(GLenum mod
On 26 August 2013 15:12, Paul Berry wrote:
> This patch implements pull constant upload, binding table upload, and
> surface setup for geometry shaders, by re-using vertex shader code
> that was generalized in previous patches.
>
> Based on work by Eric Anholt .
> ---
> src/mesa/drivers/dri/i965
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 28, 2013 at 6:42 PM, Niels Ole Salscheider
wrote:
> Signed-off-by: Niels Ole Salscheider
> ---
> src/gallium/drivers/radeonsi/r600.h| 1 +
> src/gallium/drivers/radeonsi/r600_hw_context.c | 28
> ++
> src/gallium
There is a new "class" si_buffer_resources, which should be good enough for
implementing any kind of buffer bindings (constant buffers, vertex buffers,
streamout buffers, shader storage buffers, etc.)
I don't even keep a copy of pipe_constant_buffer - we don't need it.
The main motivation behind
This series contains the changes my transform feedback work depends on, but
there are some useful fixes too, making it worth comitting earlier.
The last patch is the most important one, because it fixes the issues we had
with the emission of resource descriptors that we had to use 256 resource
This mimics r600g. The R600_CONTEXT_xxx flags are added to rctx->b.flags
and si_emit_cache_flush emits the packets. That's it. The shared radeon code
tells us when the streamout cache should be flushed, so we have to check
the flags anyway.
There is a new atom "cache_flush", because caches must be
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 32 +++---
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 2b1928a..13bc92c 100644
--- a/src/gallium/drive
---
src/gallium/drivers/r600/r600_pipe.h | 3 ---
src/gallium/drivers/radeonsi/radeonsi_pipe.h | 5 -
2 files changed, 8 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 21d68c9..1564cc3 100644
--- a/src/gallium/drivers/r600/
From: Christian König
Otherwise the first few frames have an incorrect reference index.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/d
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/radeonsi/r600.h| 1 +
src/gallium/drivers/radeonsi/r600_hw_context.c | 28 ++
src/gallium/drivers/radeonsi/r600_query.c | 7 +--
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 +-
src/
On 27 August 2013 15:21, Eric Anholt wrote:
> This brings over the batch-wrap-prevention and aperture space checking
> code from the normal brw_draw.c path, so that we don't need to flush the
> batch every time.
>
> There's a risk here if the intel_emit_post_sync_nonzero_flush() call isn't
> high
Yes, if we change the representation, we should keep backwards compatability in
tgsi text parsing
Jose
- Original Message -
> There are some TGSI shaders parsed by tgsi_text_translate which
> declare floating-point immediates. Any incompatible change to the
> parser would break them.
>
There are some TGSI shaders parsed by tgsi_text_translate which
declare floating-point immediates. Any incompatible change to the
parser would break them.
Marek
On Wed, Aug 28, 2013 at 3:57 PM, Jose Fonseca wrote:
> - Original Message -
>> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie wr
Last September, Andy Ritger proposed updating the Linux OpenGL ABI to allow for
multiple vendors to co-exist within a single process and OpenGL applications to
dispatch commands to different vendors with per-context granularity. The current
proposal [1] calls for a vendor-neutral "API library" whic
- Original Message -
> There are drivers not using these optional stages.
>
> Broken by a3ae5dc7dd5c2f8893f86a920247e690e550ebd4.
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/gallium/auxiliary/draw/draw_context.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
On 08/27/2013 11:34 PM, Liu Xin wrote:
Hi, Mesa community,
I am not familiar with S-expression or other forms of lisp languages.
That's OK - the IR has no resemblance to actual Scheme or Lisp
programming. We just print and read the () syntax because it's simple.
I am working on GLSL IR tr
From: Roland Scheidegger
While a sqrt here and there shouldn't hurt much (depending on the cpu) it is
possible to completely omit it since rho is only used for calculating lod and
there log2(x) == 0.5*log2(x^2). Depending on the exact path taken for
calculating lod this means we get a simple mul
From: Roland Scheidegger
This is just preparation for per-pixel (or per-quad in case of multiple quads)
min/mag filter since some assumptions about number of miplevels being equal
to number of lods no longer holds true.
This change does not change behavior yet (though theoretically when forcing
p
On 28 August 2013 12:17, Marek Olšák wrote:
> Yeah, st/mesa also compiles shaders on the first use, so we've got 3
> places to fix: Wine, st/mesa, the driver.
>
For what it's worth, while Wine definitely has some room for
improvement in this regard, in some cases we don't get the shaders any
earli
- Original Message -
From: Brian Paul
>On 08/27/2013 08:39 PM, Timothy Arceri wrote:
>> V2: const qualify table parameter
>>
>> Signed-off-by: Timothy Arceri
>> ---
>> src/mesa/main/hash.c | 28
>> src/mesa/main/hash.h | 3 +++
>> 2 files changed, 3
On 08/27/2013 08:39 PM, Timothy Arceri wrote:
V2: const qualify table parameter
Signed-off-by: Timothy Arceri
---
src/mesa/main/hash.c | 28
src/mesa/main/hash.h |3 +++
2 files changed, 31 insertions(+)
Reviewed-by: Brian Paul
Do you need someone to
- Original Message -
> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie wrote:
> >>> IMM[0] FLT32 { 0x, 0x, 0x, 0x } # 1.0, 3.0, 2.0, 4.0
> >>
> >> If you use "%.9g" instead of "%.4f" then floating point numbers will be
> >> preserved without loss of precision.
> >>
> >
> > I
Well, for this discussion let's just assume that we fixed the delay in
the upper layers of the stack and the driver sees the shader code as
soon as the application (if I understood it correctly Vadim has just
volunteered for the job).
Also let's assume that shaders are small and having allot o
Hi, Mesa community,
I am not familiar with S-expression or other forms of lisp languages. I
am working on GLSL IR transformation. for example, i want to change a
variable to a array of same type.
By now , i can find the definition of a variable. How can i update all
uses of this variable in
Hi,
Looking at the code, is there a potential memory leak in GLSL parser wrt
extension statements?
glsl_lexer.ll has:
[_a-zA-Z][_a-zA-Z0-9]* {
yylval->identifier = strdup(yytext);
return IDENTIFIER;
}
i.e. calls strdup on the token (there's one other place that calls strdup;
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 28, 2013 at 6:14 AM, Chia-I Wu wrote:
> LIBGL_SHOW_FPS=1 makes GLX print FPS every second while other values do
> nothing. Extend it so that LIBGL_SHOW_FPS=N will print the FPS every N
> seconds.
> ---
> src/glx/dri2_glx.c | 12
> 1 file
Yeah, st/mesa also compiles shaders on the first use, so we've got 3
places to fix: Wine, st/mesa, the driver.
Marek
On Wed, Aug 28, 2013 at 2:07 AM, Vadim Girlin wrote:
> On 08/28/2013 02:59 AM, Marek Olšák wrote:
>>
>> First, you won't really see any significant continual difference in
>> fram
Ah it is by design. Sentinels are special nodes with no payload.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
64 matches
Mail list logo
