Ivybridge doesn't appear to have the same errata as Sandybridge; no
corruption was observed by setting it to more than the minimal correct
value. It's possible that we were simply lucky, since the URB entries
are 1024-bit on Ivybridge vs. 512-bit Sandybridge. Or perhaps the
underlying hardware is
(This commit message was primarily written by Paul Berry, who explained
what's going on far better than I would have.)
Previous to this patch, we thought that the only restrictions on
3DSTATE_SF's URB read length were (a) it needs to be large enough to
read all the VUE data that the SF needs, and
The next patch will benefit from easy access to the source attribute
number and whether or not we're swizzling. It doesn't want the final
attr_override DWord form, however.
NOTE: This is a candidate for all stable branches.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_sf_st
The maximum SF source attribute is necessary to compute the Vertex URB
read length properly, which will be done in the next commit.
NOTE: This is a candidate for all stable branches.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_state.h | 2 +-
src/mesa/drivers/dri/i965/g
On 02/02/2013 10:28 AM, Paul Berry wrote:
On 2 February 2013 03:44, Kenneth Graunke mailto:kenn...@whitecape.org>> wrote:
The old calculation was off by one in certain cases. The documentation
contains a precise formula for how to calculate it, so just use that.
Wow, thank you for put
https://bugs.freedesktop.org/show_bug.cgi?id=39821
--- Comment #1 from Quentin Glidic ---
Also, EGL users which are including EGL/eglplatform.h are highly unlikely to
define MESA_EGL_NO_X11_HEADERS either, so we need to define it in a way that
users will have the definition too.
Maybe putting a
Am Samstag, 2. Februar 2013 schrieb Kenneth Graunke:
> On 02/02/2013 04:50 AM, Martin Steigerwald wrote:
> > Am Samstag, 2. Februar 2013 schrieb Kenneth Graunke:
> >> The old calculation was off by one in certain cases. The
> >> documentation contains a precise formula for how to calculate it, so
On 02/02/2013 04:50 AM, Martin Steigerwald wrote:
Am Samstag, 2. Februar 2013 schrieb Kenneth Graunke:
The old calculation was off by one in certain cases. The documentation
contains a precise formula for how to calculate it, so just use that.
Fixes random corruption in Steam's Big Picture Mod
On Sat, Feb 2, 2013 at 3:44 AM, Kenneth Graunke wrote:
> The old calculation was off by one in certain cases. The documentation
> contains a precise formula for how to calculate it, so just use that.
>
> Fixes random corruption in Steam's Big Picture Mode, random corruption
> in PlaneShift (since
On 2 February 2013 03:44, Kenneth Graunke wrote:
> The old calculation was off by one in certain cases. The documentation
> contains a precise formula for how to calculate it, so just use that.
>
Wow, thank you for putting in the time and effort to track this down, Ken.
I spent a fair amount of
https://bugs.freedesktop.org/show_bug.cgi?id=60197
--- Comment #2 from Quentin Glidic ---
Created attachment 74099
--> https://bugs.freedesktop.org/attachment.cgi?id=74099&action=edit
Second patch for gallium/egl with Wayland
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=60197
--- Comment #1 from Quentin Glidic ---
Created attachment 74098
--> https://bugs.freedesktop.org/attachment.cgi?id=74098&action=edit
First patch to fix gallium/auxiliary
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=60197
Priority: medium
Bug ID: 60197
Assignee: mesa-dev@lists.freedesktop.org
Summary: Mesa Gallium VPATH build is broken
Severity: normal
Classification: Unclassified
OS: All
On Thu, Jan 31, 2013 at 4:34 PM, Paul Berry wrote:
> Since transform feedback needs to be able to access individual fields
> of varying structs, we can no longer match up the arguments to
> glTransformFeedbackVaryings() with variables in the vertex shader.
>
> Instead, we build up a hashtable whic
https://bugs.freedesktop.org/show_bug.cgi?id=59737
--- Comment #11 from Alexandre Demers ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > (In reply to comment #6)
> > > > > (In reply to comment #5)
> > > > > > Patch sent.
Intend to merge this into the previous ARB_draw_indirect patches.
Just in case there's any complaints ...
Needed to add this so the DRAW_INDIRECT_BUFFER doesn't get placed
into a non-GPU accessible domain. Besides, this seems reasonable,
and D3D11 has it, too (albeit a specialized version, called
Am Samstag, 2. Februar 2013 schrieb Kenneth Graunke:
> The old calculation was off by one in certain cases. The documentation
> contains a precise formula for how to calculate it, so just use that.
>
> Fixes random corruption in Steam's Big Picture Mode, random corruption
> in PlaneShift (since t
The old calculation was off by one in certain cases. The documentation
contains a precise formula for how to calculate it, so just use that.
Fixes random corruption in Steam's Big Picture Mode, random corruption
in PlaneShift (since the varying reordering code landed), and Piglit
test .
On 02.02.2013 08:32, Adrian M Negreanu wrote:
> On Fri, Feb 1, 2013 at 11:50 PM, Christoph Bumiller
> wrote:
>> I have 1 piglit test to check drawing with several combinations of
>> parameters (using transform feedback to write the commands), but
>> will make some more tests for various things lik
19 matches
Mail list logo
