Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.cpp| 5 +++--
src/mesa/drivers/dri/i965/brw_vec4.h | 14 +++---
src/mesa/drivers/dri/i965/brw_vec4_gs.c | 2 +-
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index df38dab..511b080 100644
---
Second attempt at fixing
https://bugs.freedesktop.org/show_bug.cgi?id=71254
vec4_visitor::uniform_size and vec4_visitor::uniform_vector_size are
now allocated dynamically based on param_count from do_vs_prog.
I also made vec4_visitor noncopyable. It is not copied currently, and
to my
The canary is basically just to give a better debugging message when you
ralloc_free() something that wasn't rallocated. Reduces maximum memory
usage of apitrace replay of the dota2 demo by 60MB on my 64-bit system (so
half that on a real 32-bit dota2 environment).
---
src/glsl/ralloc.c | 6
On 11/22/2013 12:21 AM, Eric Anholt wrote:
The canary is basically just to give a better debugging message when you
ralloc_free() something that wasn't rallocated. Reduces maximum memory
usage of apitrace replay of the dota2 demo by 60MB on my 64-bit system (so
half that on a real 32-bit
On 11/22/2013 12:21 AM, Eric Anholt wrote:
The canary is basically just to give a better debugging message when you
ralloc_free() something that wasn't rallocated. Reduces maximum memory
usage of apitrace replay of the dota2 demo by 60MB on my 64-bit system (so
half that on a real 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=50754
--- Comment #26 from Tapani Pälli lem...@gmail.com ---
(In reply to comment #25)
Created attachment 89621 [details] [review]
Move LT_INIT where it should so it can test correctly (AM_)C(XX)FLAGS and
others
Updated patch against latest git
https://bugs.freedesktop.org/show_bug.cgi?id=71591
Eero Tamminen eero.t.tammi...@intel.com changed:
What|Removed |Added
Summary|Second Life shaders fail to |Second Life
On Thu, Nov 21, 2013 at 08:12:04PM -0800, Keith Packard wrote:
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
https://bugs.freedesktop.org/show_bug.cgi?id=71912
--- Comment #1 from Kevin Rogovin kevin.rogo...@intel.com ---
Created attachment 89626
-- https://bugs.freedesktop.org/attachment.cgi?id=89626action=edit
paired fragment shader
--
You are receiving this mail because:
You are the assignee for
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the kernel as drm_fourcc.h, and that
one is part of the userspace ABI since we use it to pass around
framebuffer formats and format lists.
I
https://bugs.freedesktop.org/show_bug.cgi?id=71912
Priority: medium
Bug ID: 71912
Assignee: mesa-dev@lists.freedesktop.org
Summary: Compounded macros in shaders: huge memory consumption
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=71912
--- Comment #2 from Kenneth Graunke kenn...@whitecape.org ---
Nice find. Are you planning to try and fix this bug?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=71912
Kenneth Graunke kenn...@whitecape.org changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop.
On 11/22/2013 05:29 AM, Zack Rusin wrote:
For me too, other than the fixed_position members, looks good. Thanks for
your perseverance on this Zack!
Thanks! ok, attached is a version that makes position and dx/dy 32bit again, it
seems to work great. I have a question for you guys if you run
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.
Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Fri, Nov 22, 2013 at 5:20 AM, Keith Packard kei...@keithp.com wrote:
Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv-lastStamp. Those two,
along with
While debugging the libdrm duplicate buffer object adventure, I managed to
temporarily understand object lifetimes in the __DRIimage getBuffers path, and
also to compare that to the DRI2 getBuffers path. Here are a couple of small
fixes.
I haven't looked at the i915 code, but I suspect the first
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.
Just copying code from the dri2 path to set up the fast color clear state.
This also removes a couple of bogus intel_region_reference calls.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
1 file changed, 7 insertions(+), 3
On 22 November 2013 05:52, Keith Packard kei...@keithp.com wrote:
While debugging the libdrm duplicate buffer object adventure, I managed to
temporarily understand object lifetimes in the __DRIimage getBuffers path,
and
also to compare that to the DRI2 getBuffers path. Here are a couple of
Thanks for reviewing.
- Original Message -
On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
- Original Message -
On 11/22/2013 05:29 AM, Zack Rusin wrote:
For me too, other than the fixed_position members, looks good. Thanks for
your perseverance on this Zack!
Thanks! ok, attached is a version that makes position and dx/dy 32bit
again, it seems to work great. I have
On 11/22/2013 03:03 PM, Jose Fonseca wrote:
Thanks for reviewing.
- Original Message -
On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the kernel as drm_fourcc.h, and that
one is part of the userspace ABI
On 19 November 2013 20:47, Paul Berry stereotype...@gmail.com wrote:
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch
Hi Courtney,
The VIEW_CLASS_S3TC_* classes should be added too. See the section
Dependencies on EXT_texture_compression_s3tc.
Marek
On Wed, Nov 20, 2013 at 12:16 AM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view
Kenneth Graunke kenn...@whitecape.org writes:
On 11/22/2013 12:21 AM, Eric Anholt wrote:
The canary is basically just to give a better debugging message when you
ralloc_free() something that wasn't rallocated. Reduces maximum memory
usage of apitrace replay of the dota2 demo by 60MB on my
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the
Commits should be prefixed with the name of the component they're
changing. This one should be egl:
Marek
On Thu, Nov 7, 2013 at 5:13 PM, Axel Davy axel.d...@ens.fr wrote:
We must send to the compositor buffer it is able to read.
Since tiling modes are different on graphic cards, we have
Petri Latvala petri.latv...@intel.com writes:
[...]
@@ -325,8 +326,9 @@ public:
*/
dst_reg output_reg[BRW_VARYING_SLOT_COUNT];
const char *output_reg_annotation[BRW_VARYING_SLOT_COUNT];
- int uniform_size[MAX_UNIFORMS];
- int uniform_vector_size[MAX_UNIFORMS];
+ unsigned
I've posted a wiki with some project suggestions for people wanting to
get into Mesa development:
http://wiki.freedesktop.org/dri/NewbieProjects/
These projects are a little bit larger than the one I previously posted
to the mailing list
On 11/22/2013 12:09 AM, Petri Latvala wrote:
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.cpp| 5 +++--
src/mesa/drivers/dri/i965/brw_vec4.h | 14 +++---
src/mesa/drivers/dri/i965/brw_vec4_gs.c | 2 +-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/22/2013 10:05 AM, Francisco Jerez wrote:
Petri Latvala petri.latv...@intel.com writes:
[...] @@ -325,8 +326,9 @@ public: */ dst_reg
output_reg[BRW_VARYING_SLOT_COUNT]; const char
*output_reg_annotation[BRW_VARYING_SLOT_COUNT]; - int
Ian Romanick i...@freedesktop.org writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/22/2013 10:05 AM, Francisco Jerez wrote:
[...]
With the upcoming ARB_shader_image_load_store changes we might get
more than 4 * MAX_UNIFORM uniform allocations in some cases because
image uniforms
On 11/22/2013 11:27 AM, Ian Romanick wrote:
On 11/22/2013 12:09 AM, Petri Latvala wrote:
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.cpp| 5 +++--
src/mesa/drivers/dri/i965/brw_vec4.h | 14 +++---
Ian Romanick i...@freedesktop.org writes:
On 11/22/2013 12:09 AM, Petri Latvala wrote:
[...]
@@ -546,6 +548,12 @@ private:
* If true, then register allocation should fail instead of spilling.
*/
const bool no_spills;
+
+ /*
+* Make noncopyable.
+*/
+
Kenneth Graunke kenn...@whitecape.org writes:
On 11/22/2013 11:27 AM, Ian Romanick wrote:
On 11/22/2013 12:09 AM, Petri Latvala wrote:
[...]
@@ -546,6 +548,12 @@ private:
* If true, then register allocation should fail instead of spilling.
*/
const bool no_spills;
+
+ /*
On 11/22/2013 12:23 PM, Francisco Jerez wrote:
Kenneth Graunke kenn...@whitecape.org writes:
On 11/22/2013 11:27 AM, Ian Romanick wrote:
On 11/22/2013 12:09 AM, Petri Latvala wrote:
[...]
@@ -546,6 +548,12 @@ private:
* If true, then register allocation should fail instead of
On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller markkmuel...@gmail.com wrote:
On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák mar...@gmail.com wrote:
I don't understand this and I don't think this is the right way to
implement hw-accelerated TexImage. Some of the formats are unsupported
by all
Hi Chris,
I'm using this version of the spec:
http://www.opengl.org/registry/specs/ARB/viewport_array.txt
On Thu, Nov 21, 2013 at 4:41 PM, Chris Forbes chr...@ijw.co.nz wrote:
I was just comparing to the list in the ARB_viewport_array spec.
On Fri, Nov 22, 2013 at 11:33 AM, Courtney
+ void *loaderPrivate)
+{
+ __DRIimage *img;
+ struct gl_context *ctx = ((struct st_context *)dri_context(context))-ctx;
+ struct gl_texture_object *obj;
+ struct pipe_resource *tex;
+ GLuint face = 0;
This part doesn't work.
A dri_context can be converted to a
+size = lseek(whandle-handle, SEEK_END, 0);
+/*
+ * Could check errno to determine whether the kernel is new enough, but
+ * it doesn't really matter why this failed, just that it failed.
+ */
+if (size == (off_t)-1) {
+FREE(bo);
+
A dri_context can be converted to a st_context.
Sorry for the typo. It should be A dri_context can't be converted to a
st_context.
Axel Davy
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an
ir_rvalue_visitor), we failed to notice that since
lower_clip_distance_visitor overrides visit_leave(ir_assignment *),
ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called.
As a result, clip distance
If reparent_ir() is called on invalid IR, then there's a danger that
it will fail to reparent all of the necessary nodes. For example, if
the IR contains an ir_dereference_variable which refers to an
ir_variable that's not in the tree, that ir_variable won't get
reparented, resulting in subtle
On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller markkmuel...@gmail.com
wrote:
On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák mar...@gmail.com wrote:
I don't understand this and I don't think this is the right way to
It's just that last block that were messed up -- rest was context.
Sorry for any confusion.
On Sat, Nov 23, 2013 at 10:06 AM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
Hi Chris,
I'm using this version of the spec:
http://www.opengl.org/registry/specs/ARB/viewport_array.txt
On
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the
Got it.
On Fri, Nov 22, 2013 at 2:55 PM, Chris Forbes chr...@ijw.co.nz wrote:
It's just that last block that were messed up -- rest was context.
Sorry for any confusion.
On Sat, Nov 23, 2013 at 10:06 AM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
Hi Chris,
I'm using this
On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian Høgsberg wrote:
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for
On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller markkmuel...@gmail.com wrote:
On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller markkmuel...@gmail.com
wrote:
On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák
The ARB_geometry_shader4 spec says, in the list of conditions necessary for
framebuffer completeness:
* If any framebuffer attachment is layered, all attachments must have
the same layer count. For three-dimensional textures, the layer
count
is the depth of the attached
Hi,
I believe geometry shaders are all we would have to implement for Sandy
Bridge. Unfortunately, geometry shaders work pretty differently on Sandy
Bridge, so getting them to work won't be a slam dunk. Here's roughly what
would have to be done:
This is too sad - I had the impression
The number of layers can be specified for each framebuffer attachment
independently in Gallium, Direct3D, and also our hardware. OpenGL
seems to be the only weirdo here. ;) I think our hardware handles
writes to non-existent layers independently of other attachments. It
either clamps the layer
From: Tom Stellard thomas.stell...@amd.com
NOTE: This is a candidate for the 3.4 branch.
---
lib/Target/R600/AMDGPUISelLowering.cpp | 1 +
test/CodeGen/R600/fabs.ll | 36 --
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git
Kristian Høgsberg hoegsb...@gmail.com writes:
I already explained to Keith why we use different sets of format codes
in the DRI interface, but it's always fun to slam other peoples code.
As we discussed, my complaint isn't so much about __DRI_IMAGE_FOURCC,
but the fact that the __DRIimage
Ville Syrjälä ville.syrj...@linux.intel.com writes:
What is this format anyway? -ENODOCS
Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
If its just an srgb version of ARGB, then I wouldn't really want it
in drm_fourcc.h. I expect colorspacy stuff will be handled by various
It is however illegal in d3d10 to have multiple render targets with
different dimensions (including array size):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb205131%28v=vs.85%29.aspx
I don't know what happens if you try to bind such rendertargets.
FWIW when I implemented layered
On 11/22/2013 03:15 PM, Clemens Eisserer wrote:
Hi,
I believe geometry shaders are all we would have to implement for Sandy
Bridge. Unfortunately, geometry shaders work pretty differently on Sandy
Bridge, so getting them to work won't be a slam dunk. Here's roughly what
would have to be
Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS.
LT_INIT needs them as they are expected to be used all along
the compilation when the macro runs its tests to determine among other
things the host type.
For info, see
On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote:
Ville Syrjälä ville.syrj...@linux.intel.com writes:
What is this format anyway? -ENODOCS
Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
If its just an srgb version of ARGB, then I wouldn't really want it
Paul Berry stereotype...@gmail.com writes:
Ivy Bridge hardware doesn't support primitve restart under all
circumstances--when it doesn't, we emulate it in software by splitting
up each logical draw operation into multiple 3DPRIMITIVE commands.
This causes the hardware's primitive ID counter
On Fri, Nov 22, 2013 at 3:06 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller markkmuel...@gmail.com
wrote:
On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller
On 11/22/2013 01:16 AM, Kristian Høgsberg wrote:
I'm not sold on the nested compositor for this use case. It
introduces another context switch between the game and the main
compositor and more input and output lag. Instead I think we need to
consider whether we want a new __DRIimage entry
65 matches
Mail list logo
