https://bugs.freedesktop.org/show_bug.cgi?id=39588
Jin Yang changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 7 December 2011 15:02, Paul Berry wrote:
> On 7 December 2011 13:16, Eric Anholt wrote:
>
>> On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry
>> wrote:
>> > From: Kenneth Graunke
>> >
>> > We never filled this in before because we didn't care.
>> >
>> > I'm skeptical these are correct; my sou
On 7 December 2011 13:16, Eric Anholt wrote:
> On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry
> wrote:
> > From: Kenneth Graunke
> >
> > We never filled this in before because we didn't care.
> >
> > I'm skeptical these are correct; my sources indicate that both the VS
> > and GS # of entries a
On 12/06/2011 11:11 AM, Anuj Phogat wrote:
From: Anuj Phogat
This patch fixes the samplerCubeShadow support in GLSL shader compiler. shader
compiler was picking
the 'r' texture coordinate for shadow comparison when the expected behaviour is
to use 'q' texture coordinate
in case of cube shadow
On 12/06/2011 10:20 AM, Aaron Plattner wrote:
When driCreateScreen calls driConvertConfigs to try to convert the
configs for swrast, it fails and returns NULL. Instead of checking,
it just clobbers psc->base.configs. Then, when the application asks
for the FBconfigs, there aren't any.
Instead,
On 7 December 2011 13:32, Eric Anholt wrote:
> On Wed, 7 Dec 2011 11:09:16 -0800, Paul Berry
> wrote:
> > In Gen6, transform feedback is accomplished by having the geometry
> > shader send vertex data to the data port using "Streamed Vertex Buffer
> > Write" messages, while simultaneously passi
On 12/07/2011 09:34 AM, Eric Anholt wrote:
> On Wed, 7 Dec 2011 12:34:28 -0800, Kenneth Graunke
> wrote:
>> Fixes piglit tests fbo-array, fbo-depth-array, fbo-generatemipmap-array,
>> and array-texture, as well as the array variants of my new textureSize
>> and texelFetch tests.
>>
>> NOTE: This
On Wed, 7 Dec 2011 11:09:13 -0800, Paul Berry wrote:
> When the GS is not in use, the entire URB space is available for the
> VS. When the GS is in use, we split the URB space 50/50.
>
> The 50/50 split is probably not optimal--we'll probably want tune this
> for performance in a future patch.
On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry wrote:
> From: Kenneth Graunke
>
> We never filled this in before because we didn't care.
>
> I'm skeptical these are correct; my sources indicate that both the VS
> and GS # of entries are 256 on both GT1 and GT2.
>
> I'm also loathe to change it
On Wed, 7 Dec 2011 11:09:16 -0800, Paul Berry wrote:
> In Gen6, transform feedback is accomplished by having the geometry
> shader send vertex data to the data port using "Streamed Vertex Buffer
> Write" messages, while simultaneously passing vertices through to the
> rest of the graphics pipelin
Maarten Lankhorst wrote:
You might want to check with valgrind to see if it tosses any warning, too.
I tried valgrind and it does seem that r600 is leaking - below is from a
vanilla mesa with a working test stream and vdpau, xvmc leaks half as
much with the same stream. In the patched/crashi
On 7 December 2011 13:03, Eric Anholt wrote:
> On Wed, 7 Dec 2011 11:09:11 -0800, Paul Berry
> wrote:
> > - assert(!p->single_program_flow);
> > + /* In principle, we shouldn't be patching IF and ELSE instructions in
> > +* single program flow mode when gen < 6, because in single progra
On Wed, 7 Dec 2011 11:09:11 -0800, Paul Berry wrote:
> - assert(!p->single_program_flow);
> + /* In principle, we shouldn't be patching IF and ELSE instructions in
> +* single program flow mode when gen < 6, because in single program flow
> +* mode on those platforms, we convert flow
On Wed, 7 Dec 2011 11:09:09 -0800, Paul Berry wrote:
> This patch adds a new bit to the ctx->NewState bitfield,
> _NEW_TRANSFORM_FEEDBACK, to track state changes that affect
> ctx->TransformFeedback. This bit can be used by driver back-ends to
> avoid expensive recomputations when transform feed
This patch remove the 32bits limitation. As a side effect, it bring the support
for the GL_ARB_depth_buffer_float extension.
No regression have been found on piglit, and all tests for
GL_ARB_depth_buffer_float pass successfully.
---
src/gallium/auxiliary/util/u_tile.c | 28 +
In Gen6, transform feedback is accomplished by having the geometry
shader send vertex data to the data port using "Streamed Vertex Buffer
Write" messages, while simultaneously passing vertices through to the
rest of the graphics pipeline (if rendering is enabled).
This patch adds a geometry shader
R02_PRIM_END and R02_PRIM_START don't actually refer to bits in DWORD
2 of R0 (as the name, and comments in the code, would seem to
indicate). Actually they refer to bits in DWORD 2 of the header for
URB_WRITE messages.
This patch renames the defines to reflect what they actually mean. It
also a
Prior to this patch, in the Gen4 and Gen5 GS, we used GRF 0 (called
"R0" in the code) as a staging area to prepare the message header for
the FF_SYNC and URB_WRITE messages. This cleverly avoided an
unnecessary MOV operation (since the initial value of GRF 0 contains
data that needs to be included
When the GS is not in use, the entire URB space is available for the
VS. When the GS is in use, we split the URB space 50/50.
The 50/50 split is probably not optimal--we'll probably want tune this
for performance in a future patch. For example, in most situations,
it's probably worth allocating
From: Kenneth Graunke
We never filled this in before because we didn't care.
I'm skeptical these are correct; my sources indicate that both the VS
and GS # of entries are 256 on both GT1 and GT2.
I'm also loathe to change it and break stuff.
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i
Normally when outputting instructions in SPF (single program flow)
mode, we convert IF and ELSE instructions to conditional ADD
instructions applied to the IP register. On platforms prior to Gen6,
flow control instructions cause an implied thread switch, so this is a
significant savings.
However,
Previously, GS generation code contained a lookup table that mapped
primitive types POLYGON, TRISTRIP, and TRIFAN to TRILIST, mapped
LINESTRIP to LINELIST, and left all other primitives unchanged. This
was silly, because we never generate a GS program for those primitive
types anyhow.
This patch
This patch adds a new bit to the ctx->NewState bitfield,
_NEW_TRANSFORM_FEEDBACK, to track state changes that affect
ctx->TransformFeedback. This bit can be used by driver back-ends to
avoid expensive recomputations when transform feedback state has not
been modified.
Reviewed-by: Kenneth Graunke
Ok, I've cleaned up and made changes according to the suggestions made
on the mailing list. I believe all that needs review now is patch 5/8
(Allocate URB space for GS). On Eric's suggestion, I changed this
patch to only allocate URB space for the GS when the GS is actually in
use. The PRM indic
On 7 December 2011 00:50, Kenneth Graunke wrote:
> On 12/05/2011 09:40 AM, Paul Berry wrote:
> > This patch series introduces a geometry shader program for i965 Gen6
> > (Sandy Bridge) that does nothing--it simply passes vertices through to
> > later stages of the graphics pipeline. This is a pr
On 6 December 2011 23:54, Kenneth Graunke wrote:
> > + if (intel->gen == 6) {
> > + /* On Gen6, GS is used for transform feedback. */
> > + key->need_gs_prog = ctx->TransformFeedback.CurrentObject->Active;
> > + } else if (intel->gen >= 7) {
> > + /* On Gen7 and later, we don't
On Wed, 7 Dec 2011 10:24:09 +, Dave Airlie wrote:
> From: Dave Airlie
>
> This keeps track of the creation process and stores a drawable type,
> it then blocks DRI2 from getting called if the drawable is a pixmap.
>
> v2: check if we have a GLX drawable, which means we aren't a pbuffer,
>
Hey Andy,
On 12/07/2011 05:37 PM, Andy Furniss wrote:
> Maarten Lankhorst wrote:
>> Hey Andy,
>>
>> On 12/06/2011 10:45 PM, Andy Furniss wrote:
>>> Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough.
:-)
>>>
>>> This patch causes R600 xvmc
On 6 December 2011 23:31, Kenneth Graunke wrote:
> On 12/05/2011 09:40 AM, Paul Berry wrote:
> > R02_PRIM_END and R02_PRIM_START don't actually refer to bits in DWORD
> > 2 of R0 (as the name, and comments in the code, would seem to
> > indicate). Actually they refer to bits in DWORD 2 of the he
On 7 December 2011 00:41, Kenneth Graunke wrote:
> On 12/05/2011 09:40 AM, Paul Berry wrote:
> > Prior to this patch, in the Gen4 and Gen5 GS, we used GRF 0 (called
> > "R0" in the code) as a staging area to prepare the message header for
> > the FF_SYNC and URB_WRITE messages. This cleverly avo
On Wed, 7 Dec 2011 02:21:37 -0800, Kenneth Graunke
wrote:
> Fixes many crashes on Ivybridge due to upload_sf_state calling
> brw_depthbuffer_format without an actual depth buffer. This was a
> recent regression on master.
>
> +3992 piglits on Ivybridge.
>
> Signed-off-by: Kenneth Graunke
Re
On Wed, 7 Dec 2011 12:34:28 -0800, Kenneth Graunke
wrote:
> Fixes piglit tests fbo-array, fbo-depth-array, fbo-generatemipmap-array,
> and array-texture, as well as the array variants of my new textureSize
> and texelFetch tests.
>
> NOTE: This is a candidate for the 7.11 branch.
ARB_texture_a
On 12/7/11 4:16 AM, Michel Dänzer wrote:
On Mit, 2011-12-07 at 08:40 +, Dave Airlie wrote:
I have a feeling, since dri2 is not strictly restricted to GLX, whether this
should really be
implemented in the glx code before calling into dri2? Otoh that would mean
the server side
would need to b
Maarten Lankhorst wrote:
Hm, could you test with some added sanity checks?
mplayer: vl/vl_vlc.h:139: vl_vlc_eatbits: Assertion `vlc->valid_bits >
num_bits' failed.
If that works, maybe remove the vl_vlc_fillbits call I added in
vl_mpeg12_bs_decode
to see if that is what caused it. Unfortu
Maarten Lankhorst wrote:
Hey Andy,
On 12/06/2011 10:45 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough. :-)
This patch causes R600 xvmc to render incorrect chroma for me.
Thanks for testing! I plugged in my r600 and
On 12/07/2011 04:31 AM, Jose Fonseca wrote:
I wrote a testsuite for apitrace, and one of the tests checks the default GL
state against a reference, and it is failing on all Gallium DRI drivers because
{
parameters: {
GL_DRAW_BUFFER: "GL_BACK" -> "GL_BACK_LEFT",
GL_DRAW_BUFFER0: "G
Fixes piglit tests fbo-array, fbo-depth-array, fbo-generatemipmap-array,
and array-texture, as well as the array variants of my new textureSize
and texelFetch tests.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_wm_surface_state
Hey Andy,
On 12/06/2011 10:54 PM, Andy Furniss wrote:
> Maarten Lankhorst wrote:
>> create_buffer, destroy_buffer and set_buffer are a curiosity of
>> vl_mpeg12_decoder
>> and shouldn't be part of the api.
>>
>> set_quant_matrix and set_reference_frames shouldn't be separate calls, but
>> part o
- Original Message -
> I wrote a testsuite for apitrace, and one of the tests checks the
> default GL state against a reference, and it is failing on all
> Gallium DRI drivers because
>
> {
> parameters: {
> GL_DRAW_BUFFER: "GL_BACK" -> "GL_BACK_LEFT",
> GL_DRAW_BUFFER0: "GL_BACK
I wrote a testsuite for apitrace, and one of the tests checks the default GL
state against a reference, and it is failing on all Gallium DRI drivers because
{
parameters: {
GL_DRAW_BUFFER: "GL_BACK" -> "GL_BACK_LEFT",
GL_DRAW_BUFFER0: "GL_BACK" -> "GL_BACK_LEFT",
GL_READ_BUFFER: "GL
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorst
---
Changes since v1:
- increase nouveau_video_buffer sampler_view_planes array size to 3,
which is the only valid size, since all planes are tested against null
- Fixed vl_mc_render_re
Hey Andy,
On 12/06/2011 10:45 PM, Andy Furniss wrote:
> Maarten Lankhorst wrote:
>> No point in having it when just having sampler_view_planes is good enough.
>> :-)
>
> This patch causes R600 xvmc to render incorrect chroma for me.
>
Thanks for testing! I plugged in my r600 and confirmed the bug
On Mit, 2011-12-07 at 10:24 +, Dave Airlie wrote:
> From: Dave Airlie
>
> This keeps track of the creation process and stores a drawable type,
> it then blocks DRI2 from getting called if the drawable is a pixmap.
>
> v2: check if we have a GLX drawable, which means we aren't a pbuffer,
> a
From: Dave Airlie
This keeps track of the creation process and stores a drawable type,
it then blocks DRI2 from getting called if the drawable is a pixmap.
v2: check if we have a GLX drawable, which means we aren't a pbuffer,
avoid doing flush at all since its meant to be a no-op.
Suggested by
From: Dave Airlie
This keeps track of the creation process and stores a drawable type,
it then blocks DRI2 from getting called if the drawable is a pixmap.
Suggested by Michel Dänzer
Signed-off-by: Dave Airlie
---
src/glx/glx_pbuffer.c |3 ++-
src/glx/glxclient.h |3 ++-
src/glx/glx
On Mit, 2011-12-07 at 09:44 +, Dave Airlie wrote:
> > Indeed, but fixing it without invasive protocol work may be messy, but
> > I'm not really a GLX or DRI2 expert and its hard to fathom the
> > intentions of DRI2 original authors wrt this GLX case.
>
> Also client side fixing is not in any
> Indeed, but fixing it without invasive protocol work may be messy, but
> I'm not really a GLX or DRI2 expert and its hard to fathom the
> intentions of DRI2 original authors wrt this GLX case.
Also client side fixing is not in any way going to help broken clients
that exist in the field now. i.e
2011/12/7 Michel Dänzer :
> On Mit, 2011-12-07 at 09:20 +, Dave Airlie wrote:
>> 2011/12/7 Michel Dänzer :
>> > On Mit, 2011-12-07 at 08:40 +, Dave Airlie wrote:
>> >> >
>> >> > I have a feeling, since dri2 is not strictly restricted to GLX, whether
>> >> > this
>> >> > should really be
>>
On Mit, 2011-12-07 at 09:20 +, Dave Airlie wrote:
> 2011/12/7 Michel Dänzer :
> > On Mit, 2011-12-07 at 08:40 +, Dave Airlie wrote:
> >> >
> >> > I have a feeling, since dri2 is not strictly restricted to GLX, whether
> >> > this
> >> > should really be
> >> > implemented in the glx code
2011/12/7 Michel Dänzer :
> On Mit, 2011-12-07 at 08:40 +, Dave Airlie wrote:
>> >
>> > I have a feeling, since dri2 is not strictly restricted to GLX, whether
>> > this
>> > should really be
>> > implemented in the glx code before calling into dri2? Otoh that would mean
>> > the server side
>
On Mit, 2011-12-07 at 08:40 +, Dave Airlie wrote:
> >
> > I have a feeling, since dri2 is not strictly restricted to GLX, whether this
> > should really be
> > implemented in the glx code before calling into dri2? Otoh that would mean
> > the server side
> > would need to be able to handle the
On Mit, 2011-12-07 at 09:30 +0100, Thomas Hellstrom wrote:
> Some hardware can't reinterpret the format of hardware buffers and thus
> the X server needs to know the format when the buffer is created.
>
> Signed-off-by: Thomas Hellstrom
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer
On 12/05/2011 09:40 AM, Paul Berry wrote:
> This patch series introduces a geometry shader program for i965 Gen6
> (Sandy Bridge) that does nothing--it simply passes vertices through to
> later stages of the graphics pipeline. This is a preliminary step
> towards implementing transform feedback, s
- Original Message -
> Some hardware can't reinterpret the format of hardware buffers and
> thus the X server needs to know the format when the buffer is
> created.
Reviewed-by: Jakob Bornecrantz
>
> Signed-off-by: Thomas Hellstrom
> ---
> src/gallium/state_trackers/dri/drm/dri2.c |
>
> I have a feeling, since dri2 is not strictly restricted to GLX, whether this
> should really be
> implemented in the glx code before calling into dri2? Otoh that would mean
> the server side
> would need to be able to handle the case anyway.
The problem is that GLX doesn't get a chance, since
On 12/05/2011 09:40 AM, Paul Berry wrote:
> Prior to this patch, in the Gen4 and Gen5 GS, we used GRF 0 (called
> "R0" in the code) as a staging area to prepare the message header for
> the FF_SYNC and URB_WRITE messages. This cleverly avoided an
> unnecessary MOV operation (since the initial valu
On 12/06/2011 06:51 PM, Brian Paul wrote:
Hi Thomas,
Just a couple nit-picky things below:
OK, sent out a v3.
/Thomas
On 12/06/2011 10:32 AM, Thomas Hellstrom wrote:
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the bu
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the buffer is created.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/dri/drm/dri2.c | 41 ++--
1 files changed, 38 insertions(+), 3 deleti
On 12/06/2011 07:58 PM, Eric Anholt wrote:
On Tue, 6 Dec 2011 16:44:30 +, Dave Airlie wrote:
Hi,
So GLX has a rule about not swapping pixmaps, and I've been trying to
track down why with DRI2 my driver gets requests for swapping pixmaps
(piglit glx-swap-pixmap test).
So it appears in
59 matches
Mail list logo
