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
On Fri, Nov 22, 2013 at 3:06 PM, Marek Olšák wrote:
> On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller
> wrote:
> >
> >
> >
> > On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák wrote:
> >>
> >> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, Nov 15, 201
Paul Berry 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 to be reset to 0,
> p
On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote:
> Ville Syrjälä 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
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
http://www.gnu.org/software/libtool/manual/html_node/LT_00
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 hav
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 render
Ville Syrjälä 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
> crtc/plane properties in
Kristian Høgsberg 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 interfaces use *both*
From: Tom Stellard
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 a/lib/Target/R600/AMDGPUISelLowering.c
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 inde
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 me
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 volu
On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller wrote:
>
>
>
> On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák wrote:
>>
>> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller
>> wrote:
>> >
>> >
>> >
>> > On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák wrote:
>> >>
>> >> I don't understand this and I don'
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 wrote:
> > > Daniel Vetter writes:
> > >
> > >> Hm, where do we have the canonical source for all these fourcc co
Got it.
On Fri, Nov 22, 2013 at 2:55 PM, Chris Forbes 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 ve
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
> On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> > Daniel Vetter 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
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 Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák wrote:
> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller
> wrote:
> >
> >
> >
> > On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák wrote:
> >>
> >> I don't understand this and I don't think this is the right way to
> >> implement hw-accelerated TexImage.
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 use
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 dereferences
>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
http://lists.freedesktop.org/mailman/listinfo/mes
+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);
+
+ 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
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 wrote:
> I was just comparing to the list in the ARB_viewport_array spec.
>
>
> On Fri, Nov 22, 2013 at 11:33 AM, Courtney Goeltzenleuchter <
>
On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller wrote:
>
>
>
> On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák 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 hardware I know, others jus
On 11/22/2013 12:23 PM, Francisco Jerez wrote:
> Kenneth Graunke 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.
>
Kenneth Graunke 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;
>>> +
>>> + /*
Ian Romanick 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.
>> +*/
>> + vec4_visito
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
>> ---
>> src/mesa/drivers/dri/i965/brw_vec4.cpp| 5 +++--
>> src/mesa/drivers/dri/i965/brw_vec4.h | 14 +++---
>> src/mesa/drivers/dri/i965
Ian Romanick 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 can take
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/22/2013 10:05 AM, Francisco Jerez wrote:
> Petri Latvala 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_
On 11/22/2013 12:09 AM, Petri Latvala wrote:
> Signed-off-by: Petri Latvala
> ---
> 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 +-
> src/mesa/driver
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
(http://lists.freedesktop.org/archives/mesa-dev/2013-Octobe
Petri Latvala 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 uniform_param_c
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 wrote:
> We must send to the compositor buffer it is able to read.
>
> Since tiling modes are different on graphic cards, we have
> to disabl
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
> On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> > Daniel Vetter 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
Kenneth Graunke 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 64-bit system (so
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
wrote:
> Add Mesa TextureView logic.
> Incorporate feedback on ARB_texture_view
>
> Signed-off-by: Co
On 19 November 2013 20:47, Paul Berry 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 fixes meta clears
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> Daniel Vetter 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 ar
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
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 g
Thanks for reviewing.
- Original Message -
> On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > These degenerate instructions can often be emitted by state trackers
> > when the semantics of instructions don't match precisely.
> > ---
> > src/gallium/auxil
On 22 November 2013 05:52, Keith Packard 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
> small
> fixes.
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 o
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
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --gi
Reviewed-by: Marek Olšák
Marek
On Fri, Nov 22, 2013 at 5:20 AM, Keith Packard 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 dri2.stamp, all get simultaneously inc
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.
Signed-off
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 th
https://bugs.freedesktop.org/show_bug.cgi?id=71912
Kenneth Graunke changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=71912
--- Comment #2 from Kenneth Graunke ---
Nice find. Are you planning to try and fix this bug?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-d
Daniel Vetter 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 think it's the
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 #1 from Kevin Rogovin ---
Created attachment 89626
--> https://bugs.freedesktop.org/attachment.cgi?id=89626&action=edit
paired fragment shader
--
You are receiving this mail because:
You are the assignee for the bug.
_
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=71591
Eero Tamminen changed:
What|Removed |Added
Summary|Second Life shaders fail to |Second Life shaders fail to
https://bugs.freedesktop.org/show_bug.cgi?id=50754
--- Comment #26 from Tapani Pälli ---
(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 code.
> Based
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 d
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 d
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 +
Signed-off-by: Petri Latvala
---
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
--- a/src/mesa/drivers/dri/i965/
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 understandin
Signed-off-by: Petri Latvala
---
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 +-
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 12 +++-
src
65 matches
Mail list logo
