On 07/17/2012 03:16 PM, Ian Romanick wrote:
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits
of the extension that are causing some grief in designing the kernel /
user interface. I think I've settled on an inte
On Thu, 12 Jul 2012 12:45:22 -0700
Kenneth Graunke wrote:
> Since there is no getparam for hardware context support, Mesa always
> tries to obtain a context by calling drm_intel_gem_context_create and
> NULL-checking the result. On an older kernel without context support,
> this caused libdrm to
On Thu, 12 Jul 2012 12:45:22 -0700
Kenneth Graunke wrote:
> Since there is no getparam for hardware context support, Mesa always
> tries to obtain a context by calling drm_intel_gem_context_create and
> NULL-checking the result. On an older kernel without context support,
> this caused libdrm to
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits
of the extension that are causing some grief in designing the kernel /
user interface. I think I've settled on an interface that should meet
all of the requirem
A second attempt is now online. If I got my grepping correct, only the
xaa specific routines are in i810_xaa.c and not built with
--disable-xaa.
Some XAA code still waits for a sudden death:
[ 35756.654] (EE) Failed to load
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
/hom
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
undefined symbol: XAAGetPatternROP
That's... surprising. That should only be fatal if you have LD_BIND_NOW
semantics turned on, which is not the default. What OS are you running? Any
special security or compiler options?
- a
On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen
wrote:
> Am 17.07.2012 22:41, schrieb Chris Wilson:
> > On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
> > wrote:
> >> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
> >> wrote:
> >>> Current Xorg tree builds without problems but fails to
On 7/17/12 4:54 PM, Knut Petersen wrote:
Am 17.07.2012 22:41, schrieb Chris Wilson:
On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
wrote:
On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
wrote:
Current Xorg tree builds without problems but fails to
load intel_drv.so. Xorg log and build sc
Am 17.07.2012 22:41, schrieb Chris Wilson:
On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
wrote:
On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
wrote:
Current Xorg tree builds without problems but fails to
load intel_drv.so. Xorg log and build script attached.
Ok, looks like the xaa r
From: Paulo Zanoni
This will be needed for Haswell, but already has its uses here.
This patch started as a small patch written patch by Shobhit Kumar,
but it has changed so much that none of its original lines remain.
Credits-to: Shobhit Kumar
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/
Ok, looks like the xaa removal from i810 was snafu. Let me split out the
common ring functions from the xaa acceleration routines...
In the meantime compile with --enable-kms-only.
-Chris
Well, after compiling with --enable-kms-only the module is still broken.
But there are always some old x
On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
wrote:
> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
> wrote:
> > Current Xorg tree builds without problems but fails to
> > load intel_drv.so. Xorg log and build script attached.
>
> Ok, looks like the xaa removal from i810 was snafu. Let
On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
wrote:
> Current Xorg tree builds without problems but fails to
> load intel_drv.so. Xorg log and build script attached.
Ok, looks like the xaa removal from i810 was snafu. Let me split out the
common ring functions from the xaa acceleration rout
Current Xorg tree builds without problems but fails to
load intel_drv.so. Xorg log and build script attached.
cu,
Knut
[ 30172.250]
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedeskt
From: Paulo Zanoni
We have some common code that we always run before calling
intel_dp_set_link_train. This common code sets the correct training
patterns to the DP variable. If we add more calls to
intel_dp_set_link_train, we'll also have to duplicate this common
code. So instead of repeating th
On Tue, 17 Jul 2012 12:12:39 +0100
Chris Wilson wrote:
> On Mon, 16 Jul 2012 11:51:55 -0700, Ben Widawsky wrote:
> > Pros:
> > * Potential for per batch, or ring watchdog values. I believe when/if we
> > get to GPGPU workloads, this is particularly interesting.
> > * Batch granularity hang detec
On 16 July 2012 19:33, Paul Berry wrote:
> On 14 July 2012 02:21, Olivier Galibert wrote:
>
>> On Fri, Jul 13, 2012 at 02:45:10PM -0700, Kenneth Graunke wrote:
>> > Sorry...been really busy, and most of us haven't actually spent much if
>> > any time in the clipper shaders. I'll try and review
On 17 July 2012 01:57, Olivier Galibert wrote:
> On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote:
> > Also, I'm not convinced that #3 is necessary. Is there something in the
> > spec that dictates this behaviour? My reading of the spec is that if the
> > vertex shader writes to gl_Ba
On 30 June 2012 11:50, Olivier Galibert wrote:
> At this point all interpolation tests with fixed clipping work.
>
> Signed-off-by: Olivier Galibert
> ---
> src/mesa/drivers/dri/i965/brw_clip.c |9 ++
> src/mesa/drivers/dri/i965/brw_clip.h |1 +
> src/mesa/drivers/dri/i965/brw
On 17 July 2012 05:50, Paul Berry wrote:
> On 30 June 2012 11:50, Olivier Galibert wrote:
>
>> This patch also correct a couple of problems with noperspective
>> interpolation.
>>
>> At that point all the glsl 1.1/1.3 interpolation tests that do not
>> clip pass (the -none ones).
>>
>> The fs co
On 30 June 2012 11:50, Olivier Galibert wrote:
> At that point, all interpolation piglit tests involving fixed clipping
> work as long as there's no noperspective.
>
> Signed-off-by: Olivier Galibert
> ---
> src/mesa/drivers/dri/i965/brw_clip.c | 10 -
> src/mesa/drivers/dri/i965
On 30 June 2012 11:50, Olivier Galibert wrote:
> This patch also correct a couple of problems with noperspective
> interpolation.
>
> At that point all the glsl 1.1/1.3 interpolation tests that do not
> clip pass (the -none ones).
>
> The fs code does not use the pre-resolved interpolation modes
On Mon, 16 Jul 2012 11:51:55 -0700, Ben Widawsky wrote:
> Pros:
> * Potential for per batch, or ring watchdog values. I believe when/if we
> get to GPGPU workloads, this is particularly interesting.
> * Batch granularity hang detection. This mostly just makes hang
> detection and recovery a bit ea
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote:
> Also, I'm not convinced that #3 is necessary. Is there something in the
> spec that dictates this behaviour? My reading of the spec is that if the
> vertex shader writes to gl_BackColor but not glFrontColor, then the
> contents of gl_C
On Thu, Jul 12, 2012 at 04:49:34PM -0300, Paulo Zanoni wrote:
> 2012/7/12 Daniel Vetter :
> > Instead of having a giant if cascade to figure this out according to
> > the passed-in register. We could do quite a bit more cleaning up and
> > all by using the port at more places, but I think this shou
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote:
> Can you split this into three separate patches? That will make it easier
> to troubleshoot in case we find bugs with these patches in the future.
I'm going to try.
> Also, I'm not convinced that #3 is necessary. Is there something i
26 matches
Mail list logo
