On 11/15/2011 05:55 PM, Eric Anholt wrote:
> This will be used to drive chosing formats and determining framebuffer
> completeness, instead of the bunch of ad-hoc checks we have had until
> now.
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 204
> ++
> 1 files ch
Dear devs,
I am getting segmentation faults when running piglit r600.tests with latest
mesa build from git:
Nov 16 09:21:33 spoc kernel: [74538.198983] radeon :05:00.0: object_init
failed for (1431699456, 0x0006)
Nov 16 09:21:33 spoc kernel: [74538.198987] [drm:radeon_gem_object_create]
On 11/15/2011 05:55 PM, Eric Anholt wrote:
> This is currently duplicated with intel_context.c's setup of the
> formats table, and sets true for exactly the same set of formats on
> gen6.
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 13 -
> 1 files changed, 12 insertion
On 11/15/2011 05:55 PM, Eric Anholt wrote:
> There are a couple of core mesa fixes tucked in this series.
I like this! Great work.
For the series:
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freed
On 11/16/2011 12:52 AM, Kenneth Graunke wrote:
> On 11/15/2011 05:55 PM, Eric Anholt wrote:
>> This is currently duplicated with intel_context.c's setup of the
>> formats table, and sets true for exactly the same set of formats on
>> gen6.
>> ---
>> src/mesa/drivers/dri/i965/brw_wm_surface_state.c
Neither DX9 or DX10 expose equivalent to GL_RGB16F_ARB:
- http://msdn.microsoft.com/en-us/library/bb172558.aspx (D3D9)
- http://msdn.microsoft.com/en-us/library/bb173059.aspx (D3D10)
So probably no hardware ever will support them.
Even for software rendering it is a very nasty format to support,
- Original Message -
> On 11/14/2011 10:13 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On 11/14/2011 09:48 PM, Christoph Bumiller wrote:
> >>> On 11/14/2011 09:24 PM, Jose Fonseca wrote:
>
>
> - Original Message -
> > On 11/14/2011 08
Signed-off-by: Maarten Lankhorst
---
src/gallium/include/pipe/p_video_state.h |3 +++
src/gallium/state_trackers/vdpau/decode.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/include/pipe/p_video_state.h
b/src/gallium/include/pipe/p_video_state.h
inde
Doesn't break nouveau_video, apparently a check already causes it to use
vl_video_buffer for vdpau.
Signed-off-by: Maarten Lankhorst
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 15 +++--
src/gallium/auxiliary/vl/vl_video_buffer.c | 92 +-
src/gallium/auxiliar
You won't be missed, functionality folded into picture_desc and
decode..
Signed-off-by: Maarten Lankhorst
---
src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c |4 +-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 68 ---
src/gallium/drivers/nouveau/nouveau_video.c| 26
There should be no way for endframe to ever need recursion..
Signed-off-by: Maarten Lankhorst
---
src/gallium/state_trackers/xorg/xvmc/surface.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xvmc/surface.c
b/src/
This requires some special care, vl_mpeg12_decoder was dumping some state
in the decode_buffer, and we can no longer control the order in which
decode_buffer/decoder is freed. As such, vl_idct cannot be used in cleanup.
Fortunately it's not needed. Also, flush will have to be called before
destroyi
Signed-off-by: Maarten Lankhorst
---
src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c |4 +-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 12 +-
src/gallium/drivers/nouveau/nouveau_video.c| 25 +--
src/gallium/include/pipe/p_video_decoder.h |9 +-
src/gallium/state_trackers
This is no longer used with the removal of decoder buffers.
Signed-off-by: Maarten Lankhorst
---
src/gallium/auxiliary/vl/vl_decoder.c| 13 -
src/gallium/auxiliary/vl/vl_decoder.h|6 --
src/gallium/drivers/nouveau/nouveau_video.c |2 --
src/
On 15.11.2011 17:52, Maarten Lankhorst wrote:
Deleted:
- begin_frame/end_frame: Was only useful for XvMC, should be folded into flush..
I'm not completely happy with the current interface also, but if you
remove the state tracker ability to control how many buffers are used,
which in turn let
Brian Paul vmware.com> writes:
>
> On 03/10/2011 08:30 PM, tom fogal wrote:
> > Kenneth Graunke whitecape.org> writes:
> >> On Thursday, March 10, 2011 01:17:04 PM Alexander Neundorf wrote:
> >>> While at it (sorry for newbie questions), do I need gallium (maybe
> >>> swrast) when I want only o
Hey,
On 11/16/2011 02:47 PM, Christian König wrote:
> On 15.11.2011 17:52, Maarten Lankhorst wrote:
>> Deleted:
>> - begin_frame/end_frame: Was only useful for XvMC, should be folded into
>> flush..
>
> I'm not completely happy with the current interface also, but if you remove
> the state track
On 11/15/2011 08:18 PM, Yuanhan Liu wrote:
On Tue, Nov 15, 2011 at 07:26:52AM -0700, Brian Paul wrote:
On 11/15/2011 12:51 AM, Yuanhan Liu wrote:
Make sure all lighting tables are updated before using the table to
calculate something, say using _SpotExpTable to calculate
_VP_inf_spot_attenuatio
In slow_read_depth_stencil_pixels_separate() we might have separate
depth and stencil buffers or a combined buffer. In the later case,
don't map the buffer twice. This function is used when the depth
scale/bias pixel transfer values are not the defaults.
Fixes http://bugs.freedesktop.org/show_bu
On 11/16/2011 01:38 AM, Theiss, Ingo wrote:
Dear devs,
I am getting segmentation faults when running piglit r600.tests with latest
mesa build from git:
Nov 16 09:21:33 spoc kernel: [74538.198983] radeon :05:00.0: object_init
failed for (1431699456, 0x0006)
Nov 16 09:21:33 spoc kernel:
On 11/15/2011 11:16 AM, vlj wrote:
blinking-teapot is an UBO demo.
I think you missed a bunch of other comments I made on the first
version. Can you go back and re-read my reply? Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freede
Looks good Brian.
BTW, we should probably be more defensive about map failures on this code. This
is not a regression, as st_cb_readpixels.c also did a poor job.
Jose
- Original Message -
> In slow_read_depth_stencil_pixels_separate() we might have separate
> depth and stencil buffers o
On 11/16/2011 08:43 AM, Jose Fonseca wrote:
Looks good Brian.
BTW, we should probably be more defensive about map failures on this code. This
is not a regression, as st_cb_readpixels.c also did a poor job.
Yeah, it's only a matter of time until we find a case where
MapRenderbuffer (or MapTex
On Wed, 2011-11-16 at 07:53 -0700, Brian Paul wrote:
> In slow_read_depth_stencil_pixels_separate() we might have separate
> depth and stencil buffers or a combined buffer. In the later case,
> don't map the buffer twice. This function is used when the depth
> scale/bias pixel transfer values are
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/mesa/main/readpix.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 8550618..582adc3 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@
On Wed, 2011-11-16 at 20:41 +0400, Vadim Girlin wrote:
> On Wed, 2011-11-16 at 07:53 -0700, Brian Paul wrote:
> > In slow_read_depth_stencil_pixels_separate() we might have separate
> > depth and stencil buffers or a combined buffer. In the later case,
> > don't map the buffer twice. This functio
On 11/16/2011 09:54 AM, Vadim Girlin wrote:
On Wed, 2011-11-16 at 20:41 +0400, Vadim Girlin wrote:
On Wed, 2011-11-16 at 07:53 -0700, Brian Paul wrote:
In slow_read_depth_stencil_pixels_separate() we might have separate
depth and stencil buffers or a combined buffer. In the later case,
don't m
---
src/mesa/main/readpix.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 0b41de6..86b8753 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -412,6 +412,10 @@ slow_read_depth_stencil_pixels_se
Am Mittwoch, 16. November 2011 15:58 CET, Brian Paul
schrieb:
> On 11/16/2011 01:38 AM, Theiss, Ingo wrote:
> > Dear devs,
> >
> > I am getting segmentation faults when running piglit r600.tests with latest
> > mesa build from git:
> >
> > Nov 16 09:21:33 spoc kernel: [74538.198983] radeon
Vadim Girlin [2011-11-13 22:08]:
> Emit MOVA* instruction only when AR is used.
>
> Signed-off-by: Vadim Girlin
> ---
>
> Tested on evergreen: no regressions, fixes some variable-indexing tests.
On my rv730 this patch causes broken rendering in the game Heroes of
Newerth. I have an apitrace fil
On Wed, 2011-11-16 at 18:57 +0100, Tilman Sauerbeck wrote:
> Vadim Girlin [2011-11-13 22:08]:
> > Emit MOVA* instruction only when AR is used.
> >
> > Signed-off-by: Vadim Girlin
> > ---
> >
> > Tested on evergreen: no regressions, fixes some variable-indexing tests.
>
> On my rv730 this patch
On 11/16/2011 10:09 AM, Theiss, Ingo wrote:
Am Mittwoch, 16. November 2011 15:58 CET, Brian Paul
schrieb:
On 11/16/2011 01:38 AM, Theiss, Ingo wrote:
Dear devs,
I am getting segmentation faults when running piglit r600.tests with latest
mesa build from git:
Nov 16 09:21:33 spoc kernel: [
In order to implement transform feedback on Gen6, we need to create a
geometry shader program that will stream out the transformed vertices.
It makes sense to re-use parts of the vec4_visitor infrastructure to
do this, because (a) VS and GS handle data very similarly, (b) it
allows us to take advan
This patch removes two unused functions from vec4_visitor:
implied_mrf_writes() and emit_bool_comparison(). implied_mrf_writes()
is part of instruction scheduling, which has not been implemented for
vec4_visitor yet. emit_bool_comparison() has never been used.
It also removes two declarations th
Previously, reg_allocate() (and reg_allocate_trivial()) stored the
total number of registers allocated (including payload registers) in
vec4_visitor::total_grf. Now, it returns this value to
vec4_visitor::run(), which stores it in total_grf.
This helps pave the way for separating the IR visiting
Previously, vec4_visitor::move_grf_array_access_to_scratch() stored
the value of last_scratch in the brw_vs_compile structure directly.
Now it returns it to vec4_visitor::run(), which stores it.
This helps pave the way for sharing vec4 code between the GS and the
VS, by making move_grf_array_acces
Previously, vec4_visitor::setup_payload() stored the location of the
first non-payload GRF in vec4_visitor::first_non_payload_grf, where it
was later picked up by the register allocator. Now setup_payload()
returns the location to the caller (vec4_visitor::run()), which passes
it directly to the r
Previously, vec4_visitor::run() called brw_set_access_mode() right
before calling vec4_visitor::generate_code(). It seems clearer to put
the call inside generate_code(), since the purpose of
brw_set_access_mode() is to set up the proper state for code
generation.
This helps pave the way for separ
Previously, vec4_visitor::run() was responsible for calling
reg_allocate() right before generate_code(). However, since there is
no reason for run() to do any further manipulation of the instructions
between calling reg_allocate() and generate_code(), it's just as
simple to have generate_code() ca
Previously, vec4_visitor flagged a failure by setting the "failed"
boolean and storing a string in "fail_msg" (which, up until the point
of failure, was undefined). This is redundant--it's just as easy to
have fail_msg be NULL when there is no failure, and a string pointer
when there is a failure.
To determine whether a debug dump should be performed, vec4_visitor
checks the DEBUG_VS bit in INTEL_DEBUG. This patch moves that check
into a single common function, get_debug_flag().
This helps pave the way for sharing code between VS and GS code
generation, by creating a function that can be m
Previously, vec4_visitor contained several explicit references to
vertex shading in debug messages. This patch moves all of those
references into a single function, get_debug_name(), which returns a
human-readable description of the shader being compiled.
This helps pave the way for sharing code
This patch moves vec4_visitor::run()'s optimization loop to its own
method.
This helps pave the way for separating the IR visiting parts of
vec4_visitor from the code generation parts, by reducing the number of
function calls between the two parts.
---
src/mesa/drivers/dri/i965/brw_vec4.h
Previously, get_assignment_lhs() was a static function. But it makes
just as much sense to make it a private member functions of
vec4_visitor, because it is one of vec4_visitor's implementation
details, just like the other functions in brw_vec4_visitor.cpp.
This will allow the implementation deta
This patch separates vec4_visitor into a base class, vec4_generator,
and a derived class, vec4_visitor. vec4_generator is responsible for
code generation, register allocation, and optimization; it is
independent of GLSL IR (with one trivial exception), and mostly
independent of the type of shader
This patch rearranges the class declarations for vec4_generator and
vec4_visitor, and adds "private" and "protected" modifiers, to clarify
how the code is organized and how the two classes relate to each
other. There is no functional change.
---
src/mesa/drivers/dri/i965/brw_vec4.h | 310 +++
From: Ian Romanick
Poking directly at the backing resources works only by luck. Core
Mesa code should only know about the gl_uniform_storage structure.
Soon other code that looks at samplers will use the gl_uniform_storage
structures instead of the data in the gl_program.
Signed-off-by: Ian Rom
From: Ian Romanick
Signed-off-by: Ian Romanick
Cc: Eric Anholt
---
src/mesa/main/ff_fragment_shader.cpp |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 1806adc..4808855 100644
---
From: Ian Romanick
Previously the fixed-function fragment shader was tracked as a
gl_program. This means that it shows up in the driver as a Mesa IR
program instead of as a GLSL IR program. If a driver doesn't generate
Mesa IR from the GLSL IR, that program is empty. If the program is
empty th
From: Ian Romanick
If glUniform1i and friends are going to dump data directly in
driver-allocated, the pointers have to be updated when the storage
moves. This should fix the regressions seen with commit 7199096.
I'm not sure if this is the only place that needs this treatment. I'm
a little un
On 16 November 2011 11:07, Paul Berry wrote:
> In order to implement transform feedback on Gen6, we need to create a
> geometry shader program that will stream out the transformed vertices.
> It makes sense to re-use parts of the vec4_visitor infrastructure to
> do this, because (a) VS and GS han
blinking-teapot is an UBO demo.
---
src/glsl/CMakeLists.txt |1 +
src/glsl/Makefile.am |2 +
src/glsl/blinking-teapot.c| 177 +
src/glsl/blinking-teapot.frag | 31 +++
src/glsl/blinking-teapot.vert | 16
5 files ch
This patch fixes memory corruption, thanks.
Also there is another regression with Ligthsmark - incorrect rendering.
I've bisected it and came to the same commit again. Most noticeable
difference is in the very last scene - it should fade away, but it
doesn't. I can make the screenshots of good and
>
> See the second patch I posted (mesa: initialize stencilMap, Stride if
> stencilRb==depthRb)
>
> -Brian
>
>
Hi Brian,
the second patch did it. No more segfaults.
Great. Thanks!
Regards,
Ingo
___
mesa-dev mailing list
mesa-dev@lists.freedes
On 11/16/2011 12:38 PM, Vadim Girlin wrote:
This patch fixes memory corruption, thanks.
Also there is another regression with Ligthsmark - incorrect rendering.
I've bisected it and came to the same commit again. Most noticeable
difference is in the very last scene - it should fade away, but it
d
Hi there,
running piglit test 'shader_runner
tests/spec/glsl-1.10/execution/samplers/in-parameter-struct.shader_test -auto
-fbo' the program terminated with signal 6, aborted.
glxinfo:
OpenGL renderer string: Gallium 0.4 on AMD BARTS
OpenGL version string: 2.1 Mesa 7.12-devel (git-010dc29)
Ope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/2011 06:16 PM, Eric Anholt wrote:
> On Sun, 13 Nov 2011 22:32:15 -0800, Chad Versace
> wrote:
>> In intel_map_renderbuffer_s8(), detile and copy the stencil buffer into
>> the temporary buffer only if the renderbuffer is mapped in read mode.
On 11/16/2011 01:42 PM, Theiss, Ingo wrote:
See the second patch I posted (mesa: initialize stencilMap, Stride if
stencilRb==depthRb)
-Brian
Hi Brian,
the second patch did it. No more segfaults.
Great. Thanks!
OK, I'll push the patch.
-Brian
_
Vadim Girlin [2011-11-16 22:28]:
> On Wed, 2011-11-16 at 18:57 +0100, Tilman Sauerbeck wrote:
> > Vadim Girlin [2011-11-13 22:08]:
> > > Emit MOVA* instruction only when AR is used.
> > >
> > > Signed-off-by: Vadim Girlin
> > > ---
> > >
> > > Tested on evergreen: no regressions, fixes some vari
On 11/16/2011 09:44 AM, Michel Dänzer wrote:
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/mesa/main/readpix.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 8550618..582adc3 100644
--- a/src/mesa/m
Previously we were mapping/unmapping the index buffer each time we
found the restart index in the buffer. This is bad when the restart
index is frequently used. Now just map the index buffer once, scan
it to produce a list of sub-primitives, unmap the buffer, then draw
the sub-primitives.
Also,
On 11/16/2011 12:45 PM, vlj wrote:
blinking-teapot is an UBO demo.
---
src/glsl/CMakeLists.txt |1 +
src/glsl/Makefile.am |2 +
src/glsl/blinking-teapot.c| 177 +
src/glsl/blinking-teapot.frag | 31 +++
src/glsl/b
Merge may produce incorrect order of operations for r600-eg:
x: inst1 R0.x, ... ; //from current group
...
t: inst0 R0.x, ... ; //from previous group, same destination
Result of inst1 will be lost.
So compare destinations and don't allow this.
Signed-off-by: Vadim Girl
On 11/11/2011 10:07 AM, Mathias Fröhlich wrote:
Hi all,
following a patch series to make gl_array_object use a VERT_ATTRIB_*
indexed array of gl_client_array structs.
Since we have already 33 client arrays in an array object the VERT_BIT_* and
for vertex shader inputs bitmaps are extended to 64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/2011 06:17 PM, Eric Anholt wrote:
> On Tue, 15 Nov 2011 08:06:34 -0800, Chad Versace
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/14/2011 04:03 PM, Eric Anholt wrote:
>>> On Mon, 14 Nov 2011 14:29:51 -0800, Chad Ve
From: Anuj Phogat
Hi,
Here is a patch to allow glTexImage2D and glCopyTexImage2D with depth component
cubemap.
It is listed in mesa work queue with a label "CUBE1". I've tested the patch and
output looks visually correct.
Please review the fix and let me know if i'm missing something.
Thanks
Hi,
On Thursday, November 17, 2011 00:47:22 Brian Paul wrote:
> I did a quick read of these patches and they look pretty good. I'd
> like to go over them again though. Another set of eyes would be good
> too. I'll try to finish reviewing by the end of the week.
Thanks, I have a busy week too,
It's unfortunately been a while since I've done anything with
glsl_to_tgsi. What are the "various functions that modify the TGSI IR
and try to propagate changes about that up to the gl_program"? If I can
see where it is in the code, I can probably remember if there's a reason
it was done that way
68 matches
Mail list logo
