On 12/06/2011 07:58 PM, Eric Anholt wrote:
On Tue, 6 Dec 2011 16:44:30 +, Dave Airlieairl...@gmail.com 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).
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 thellst...@vmware.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 41 ++--
1 files changed, 38
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
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 value of
- 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 ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
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,
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 thellst...@vmware.com
Reviewed-by: 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
would need to be able to handle the case
2011/12/7 Michel Dänzer mic...@daenzer.net:
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 09:20 +, Dave Airlie wrote:
2011/12/7 Michel Dänzer mic...@daenzer.net:
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 mic...@daenzer.net:
On Mit, 2011-12-07 at 09:20 +, Dave Airlie wrote:
2011/12/7 Michel Dänzer mic...@daenzer.net:
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
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.
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 way
From: Dave Airlie airl...@redhat.com
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 mic...@daenzer.net
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/glx/glx_pbuffer.c |
From: Dave Airlie airl...@redhat.com
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
On Mit, 2011-12-07 at 10:24 +, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
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
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
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
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_BACK -
- 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 -
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 of
picparm,
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 kenn...@whitecape.org
---
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:
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
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
On Wed, 7 Dec 2011 12:34:28 -0800, Kenneth Graunke kenn...@whitecape.org
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
On Wed, 7 Dec 2011 02:21:37 -0800, Kenneth Graunke kenn...@whitecape.org
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:
On 6 December 2011 23:31, Kenneth Graunke kenn...@whitecape.org 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
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 to render incorrect
On Wed, 7 Dec 2011 10:24:09 +, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
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
On 6 December 2011 23:54, Kenneth Graunke kenn...@whitecape.org 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
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
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
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
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.
From: Kenneth Graunke kenn...@whitecape.org
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
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
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
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
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
On Wed, 7 Dec 2011 11:09:09 -0800, Paul Berry stereotype...@gmail.com 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
On Wed, 7 Dec 2011 11:09:11 -0800, Paul Berry stereotype...@gmail.com 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
On 7 December 2011 13:03, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:11 -0800, Paul Berry stereotype...@gmail.com
wrote:
- assert(!p-single_program_flow);
+ /* In principle, we shouldn't be patching IF and ELSE instructions in
+* single program flow mode when gen
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
On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry stereotype...@gmail.com wrote:
From: Kenneth Graunke kenn...@whitecape.org
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
On 12/07/2011 09:34 AM, Eric Anholt wrote:
On Wed, 7 Dec 2011 12:34:28 -0800, Kenneth Graunke kenn...@whitecape.org
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.
On 7 December 2011 13:32, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:16 -0800, Paul Berry stereotype...@gmail.com
wrote:
In Gen6, transform feedback is accomplished by having the geometry
shader send vertex data to the data port using Streamed Vertex Buffer
Write
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 12/06/2011 11:11 AM, Anuj Phogat wrote:
From: Anuj Phogatanuj@aphogat.(none)
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
On 7 December 2011 13:16, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry stereotype...@gmail.com
wrote:
From: Kenneth Graunke kenn...@whitecape.org
We never filled this in before because we didn't care.
I'm skeptical these are correct; my sources
On 7 December 2011 15:02, Paul Berry stereotype...@gmail.com wrote:
On 7 December 2011 13:16, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry stereotype...@gmail.com
wrote:
From: Kenneth Graunke kenn...@whitecape.org
We never filled this in before
https://bugs.freedesktop.org/show_bug.cgi?id=39588
Jin Yang jin.a.y...@intel.com changed:
What|Removed |Added
Status|NEW |RESOLVED
51 matches
Mail list logo
