On 10/31/2013 04:13 PM, Keith Packard wrote:
> Instead of assuming that the size will be height * pitch, have the caller pass
> in the size explicitly.
>
> Signed-off-by: Keith Packard
One nit below. With that changed,
Reviewed-by: Ian Romanick
> ---
> src/mes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zhao, Jian J wrote:
> Hi,
>
> Recently I have made a piglit case that can test the behaviors of
> buffer swap, they are 1) test whether we can get swap events. 2) verify
> whether the swap is asynchronous 3) verify the swap frequency of swap
> interv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luc Verhaegen wrote:
> On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote:
>>
>> I've been busy trying to get a release out the door, so I haven't looked
>> at these patches yet. I won't have a chanc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen wrote:
>> So, identify the volatile interfaces, and the more stable interfaces,
>> and then isolate the volatile ones, and then you come to only one
>> conclusion.
>
> Except tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Westermann Fu wrote:
> I found that for DRI callback 'SwapContext' hook handler, seems no
> driver interested with it, except for old glint video driver do real
> work in it. Does it mean context switch concept outdated for current
> graphics hardware
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Svilen wrote:
> Ian,
>
> Thanks again. It seems that we agree on the initialization sequence, but
> there are still some details - see below.
> On 12/04/2009 10:07 PM, Ian Romanick wrote:
>>
>>> 2. You call glXGetPro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Svilen wrote:
> On 12/03/2009 09:18 PM, Ian Romanick wrote:
>>> I was also a bit confused by the glewinfo report that the driver
>>> supports both glGenBuffers and glGenBuffersARB. It seems logical those
>>> two entry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Svilen wrote:
> I was also a bit confused by the glewinfo report that the driver
> supports both glGenBuffers and glGenBuffersARB. It seems logical those
> two entry points to end-up with the same function. Besides (again from
> the glewinfo report
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
> On Wed, 02 Dec 2009 00:17:06 +, Svilen
> wrote:
>> Hi guys,
>>
>> A bug reported initially here (Fedora 12)
>> https://bugzilla.redhat.com/show_bug.cgi?id=541879
>>
>> You can see from the bug reports that it involves "Mesa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tormod Volden wrote:
> From: Tormod Volden
>
> ---
>
> For automated bug triaging hackery purposes, it can be nice to have
> these chipset labels, reported in glxinfo, more consistent.
>
> I wonder if also the "E7221G (i915)" string can be further
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index 52c4995..08633a9 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -37,6 +37,8 @@
> #include "image.h"
> #include "context
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> On Mon, 16 Nov 2009 11:51:31 -0800
> Ian Romanick wrote:
>
>> All X events are 32 bytes, but GLX_BUFFER_SWAP_COMPLETE_INTEL is 34
>> bytes. Perhaps the SBC could be only 4-bytes? Having more than 2**32
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> Kristian, Chris and I met with some of the Clutter/Mutter developers
> last week and came up with a new GLX extension to help GLX integrate
> more naturally into glib style event loops:
> http://people.freedesktop.org/~jbarnes/swa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
> Ian, thanks for your detailed comments! The patch was just guess work
> from looking at similar extensions - I couldn't see a step-by-step guide
> on how to add an extension to Mesa.
That's the tough thing about adding a new exte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> src/mesa/drivers/dri/intel/intel_buffer_objects.c | 43
> +
> src/mesa/drivers/dri/intel/intel_context.c|1 +
> 2 files changed, 44 insertions(+), 0 deletion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
One comment for future reference... I usually split up changes to the
XML and code regeneration from "real" code changes. Intermixing makes
for trying to find a needle in a haystack. There are 10,000+ lines of
changes here, but o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Noland wrote:
> I guess that I am still trying to understand the original bug... The
> demo program that was included in the bug report seems to work fine
> here, unless I don't know what the output *should* look like. It seems
> to work both b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> Robert Noland wrote:
>> Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49
>>
>> I'm not certain that this is entirely the correct fix since the demo
>> from bug #23774 seemed to work before the commit that broke th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Fri, 2009-09-04 at 12:17 -0700, Jesse Barnes wrote:
>> I've been working on coding up the server and client side of
>> SGI_video_sync, OML_sync_control and SGI_swap_control. I came up with
>> this set of new protocol (agains
On Fri, Sep 04, 2009 at 12:17:20PM -0700, Jesse Barnes wrote:
> I've been working on coding up the server and client side of
> SGI_video_sync, OML_sync_control and SGI_swap_control. I came up with
> this set of new protocol (against the dri2-swapbuffers branch) to
> support the new requests.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Fri, 2009-08-21 at 11:45 +0200, Tom Cooksey wrote:
>> When using glX, we have no guarantee over what state the back buffer will be
>> in
>> after swap buffers. So, whenever an application needs to update, it must re-
>> rend
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
XGI previously had this problem, and I suspect VIA is having the same
problem now. They want to release the code to their 3D driver, but it's
based on a version of the OpenGL sample implementation licensed from
SGI. However, the SI has since been rel
e replaced
> by the DRM_DEBUG_KMS.
>
> Signed-off-by: Zhao Yakui
Acked-by: Ian Romanick
> ---
> drivers/gpu/drm/drm_modes.c |4 ++--
> include/drm/drmP.h |7 ---
> 2 files changed, 2 insertions(+), 9 deletions(-)
>
> In
move the prefix in the macro definition of DRM_DEBUG_KMS/DRIVER/MODE.
>
> Signed-off-by: Zhao Yakui
Acked-by: Ian Romanick
> ---
> drivers/gpu/drm/drm_modes.c |8 +++-
> drivers/gpu/drm/i915/i915_dma.c | 35 +++
> driv
limit the height to the same value; there's no intrinsic
> hardware limit in the scanout engine.
Two possible explanations:
a) It seemed like a good idea at the time.
b) FUD about rotation.
> Signed-off-by: Keith Packard
Acked-by: Ian Romanick
> ---
> drivers/gpu/drm/i915/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
> Under KMS, the whole frame buffer is never allocated to the X server, and so
> accessing the frame buffer must be done by directly mapping it using
> drm_intel_gem_bo_map_gtt when it is created.
>
> Signed-off-by: Keith Packard
to have simple
> fill/blt acceleration while only falling back to software for operations
> involving the 3D engine.
>
> Signed-off-by: Keith Packard
Reviewed-by: Ian Romanick
> ---
> src/i830_driver.c |5 -
> 1 files changed, 0 insertions(+), 5 deletions(-)
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
> On Mon, Jul 06, 2009 at 01:14:14PM -0700, Alan Coopersmith wrote:
>> Julien Cristau wrote:
>>> On Mon, Jul 6, 2009 at 09:46:40 -0700, Ian Romanick wrote:
>>>
>>>> Here's an alterate
On Mon, Jul 06, 2009 at 01:14:14PM -0700, Alan Coopersmith wrote:
> Julien Cristau wrote:
> > On Mon, Jul 6, 2009 at 09:46:40 -0700, Ian Romanick wrote:
> >
> >> Here's an alterate patch the puts _XOPEN_SOURCE and _GNU_SOURCE in config.h
> >> via confi
On Sun, Jul 05, 2009 at 06:56:41PM +0300, Pauli Nieminen wrote:
> @@ -124,6 +129,10 @@ AC_CACHE_CHECK([for supported warning flags],
> libdrm_cv_warn_cflags, [
> AC_MSG_CHECKING([which warning flags were supported])])
> WARN_CFLAGS="$libdrm_cv_warn_cflags"
>
> +if test "x$STRICT_COMPILE"
On Mon, Jul 06, 2009 at 11:44:29PM +0300, Pauli Nieminen wrote:
> Hi!
>
> I killed the camel case and added documentation comment before function.
>
> It is possible to use macros to get similar error checking to all
> others system calls that would be security problem in case of failure.
I push
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pushed. Thanks.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpSMhEACgkQX1gOwKyEAw+ISgCfcedpD30PiXSDtSZqLNCCGArS
phwAoIt68Y94F/2i3du3tU+7+YX+5Jhc
=P5YO
--
On Sun, Jul 05, 2009 at 06:51:26PM +0300, Pauli Nieminen wrote:
> Attached improved patch.
>
> From cdf9faaab782f2a84ee16c27a4e7b1f70d2e6ad5 Mon Sep 17 00:00:00 2001
> From: Pauli Nieminen
> Date: Sun, 5 Jul 2009 18:31:18 +0300
> Subject: [PATCH 5/6] libdrm: Make chown check for return value.
>
_XOPEN_SOURCE and _GNU_SOURCE in config.h
via configure.ac. Comments?
commit 716e4ad01bac6fdb6e3f433300df3cf50116d3b1
Author: Ian Romanick
Date: Mon Jul 6 09:41:56 2009 -0700
libdrm: Set _XOPEN_SOURCE and _GNU_SOURCE
Several POSIX extensions are used in the libdrm code (e.g., mknod and ffs
Pushed. Thanks.
signature.asc
Description: Digital signature
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-d
On Sun, Jul 05, 2009 at 06:43:40PM +0300, Pauli Nieminen wrote:
> strcasecmp is declared in strings.h
I pushed a modified version of this. strcasecmp is only used in xf86drm.c, so
strings.h is included directly in that file.
Thanks.
signature.asc
Description: Digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
HENRY David wrote:
> Running with MESA_DEBUG=1, I can get this error just before the
> segfault:
> Mesa: User error: GL_INVALID_OPERATION in glMapBufferARB(already mapped)
>
> I works in software mode, without giving OpenGL errors.
Hmm... I wonder i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
HENRY David wrote:
> Hello,
>
> I'm using xorg-edgers' packages on Ubuntu Jaunty, so I have equivalent
> of mesa 7.5 from git (intel 945GM), up to date.
You might try building from source. Some changes were recently (last
week?) made to the mesa_7_5
updated
> with lastest drawable width & height it seems it's not the
> case anymore, isn't this a bug ? Does resizing any gl app
> work for you on intel ? What should happen is that mesa
> believe nothings get resized while ddx will allocate buffer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
> On Tue, May 5, 2009 at 12:20 PM, Jesse Barnes
> wrote:
>> On Mon, 04 May 2009 19:14:29 -0700
>> Ian Romanick wrote:
>>
>>> Having this ability would allow us to advertise some fbcon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yakui_zhao wrote:
> Add the CVT algorithm in kernel space. And this function can be called to
> generate the required modeline.
>
> Signed-off-by: Zhao Yakui
> ---
> drivers/gpu/drm/drm_modes.c | 210
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> On Mon, 04 May 2009 14:45:07 -0700
> Ian Romanick wrote:
>
>> There's a problem in dri2SwapBuffers. If a new libGL is used with an
>> old driver, psc->dri2->setBuffers won't be set, right
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> Ok, this set addresses all the shortcomings of the last set, and things
> seem quite solid, aside from output detection on my test platform which
> causes me to wait on flips from pipes with no outputs attached. Note
> that this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joel Bosveld wrote:
> I have copied the changes from intel (to radeon) regarding
> DRI2GetBuffersWithFormat. Patches for the ddx and mesa are attached. It
> requires the xserver patch here
> http://lists.x.org/archives/xorg-devel/2009-April/000779.html
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Menzel wrote:
> Dear everyone,
>
> do I need to send this somewhere else?
Probably to the fbdev mailing list. I don't think anyone on dri-devel
actively works on the fbdev-based drivers.
https://lists.sourceforge.net/lists/listinfo/linux-fbdev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pierre Willenbrock wrote:
> Ian Romanick schrieb:
>> Joel Bosveld wrote:
>>> This fixes rendering when using dri2 (so, that means, radeon-rewrite and
>>> radeon-gem-cs) and a near-master xserver (the front-buffer changes). I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joel Bosveld wrote:
> This fixes rendering when using dri2 (so, that means, radeon-rewrite and
> radeon-gem-cs) and a near-master xserver (the front-buffer changes). It
> is mostly just copied from the changes to intel.
Strong work. :)
There's a bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
>
> That's the case I was describing in the last sentence. When the DDX
> gets the set of buffers to allocate it doesn't know whether to
> allocate 16 or 24 bit depth buffer. What I'm suggesting is that we
> add a new buffer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xavier Bestel wrote:
> On Tue, 2009-02-17 at 16:10 -0800, Ian Romanick wrote:
>> Are vblanks | Is anyone |
>> happening? | listening? | What to do?
>>
>> YesYes Update MSC based on vblank interr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> On Tuesday, February 17, 2009 4:10 pm Ian Romanick wrote:
>> Stepping back, there are two separate axes (Are vblanks happening? Is
>> anyone listening?) that give four separate cases. I think we can derive
>&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> As to your example, I wasn't looking for theoretical issues, but real apps
> that would depend on this behavior. I haven't played with many video apps,
> so I'm not sure if what you outlined is common behavior, or if apps typi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Mon, 2009-02-16 at 10:42 -0800, Jesse Barnes wrote:
>> On Sunday, February 15, 2009 11:33 pm Michel Dänzer wrote:
>>> On Fri, 2009-02-13 at 10:27 -0800, Jesse Barnes wrote:
>> Can you think of a case where those frames wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Hellström wrote:
> I think the XGI driver only used TTM fences, and provided an alternative
> implementation when
> TTM was stalled.
Correct. I basically did the same thing for XP10 that I had done years
before for G400.
-BEGIN PGP SIGNA
On Thu, Jan 08, 2009 at 10:45:16AM -0800, Jesse Barnes wrote:
> Dunno if this is a good idea or not, but it would have helped with some of the
> recent bugs.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pasi Kärkkäinen wrote:
| It seems OpenGL 3.0 will be (finally) released at Siggraph!
Yes, finally. :)
|
http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california//
|
| OpenGL BOF
|
| SIGGRAPH 2008 | Wednesday, 13 August | 6:00 p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Dösinger wrote:
|> So ALL Radeons can do decompression. Right now we have a system where
|> we
|> only upload S3TC textures if they were precompressed (NWN, UT2K4, etc.)
|> and we have to force the extension on in order to do it.
| This may be s
On Tue, Jul 08, 2008 at 08:29:57AM -0400, Mark Asselstine wrote:
> On Sun, Jul 6, 2008 at 7:31 AM, Alexander Beregalov
> <[EMAIL PROTECTED]> wrote:
> > From: Alexander Beregalov <[EMAIL PROTECTED]>
> >
> > #if __OS_HAS_AGP
> >
> > -#include
> > -
>
> Why remove this one and not the one at the to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
| On Fri, 2008-06-13 at 13:18 +0300, Timo Jyrinki wrote:
|> 2008/6/12 Eric Anholt <[EMAIL PROTECTED]>:
|>> I'm really having a hard time caring until someone comes up with
|>> something other than a microbenchmark that has issues wit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Hellström wrote:
| Ian Romanick wrote:
|> Jerome Glisse wrote:
|> | On Mon, 19 May 2008 12:04:16 -0700
|> | Ian Romanick <[EMAIL PROTECTED]> wrote:
|> |
|> |> The GLX spec says, basically, that the results of changes to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
| We haven't touched the texsubimage path, having not found it in a
| profile yet. It'll probably be doing map/write/unmap, which (as noted
| elsewhere in the thread) is pretty much the worst thing you can do. If
| you have a rele
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| On Mon, 19 May 2008 12:04:16 -0700
| Ian Romanick <[EMAIL PROTECTED]> wrote:
|
|> The GLX spec says, basically, that the results of changes to a shared
|> object in context A are guaranteed to be visible to co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 17:27 -0700, Ian Romanick wrote:
|
|> Apps are using and will increasingly use the glMapBuffer path. With the
|> information currently at hand, doing the alloc/copy/upload/free in the
|> driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote:
|
|> It depends on the hardware. In the second approach the driver has no
|> opportunity to do something "smart" if the copy path isn't the fast
|>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
|
|> glBindBuffer(GL_ARRAY_BUFFER, my_buf);
|> GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
|> if (data == NULL) {
|>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| On Mon, 19 May 2008 10:25:16 -0700
| Ian Romanick <[EMAIL PROTECTED]> wrote:
|
|> | Does in GL3 object must be unmapped before being use ? IIRC this
what is
|> | required in current GL 1.x and GL 2.x. If so i think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
| Nothing can solve Ians
| problems where the app gives you a single working set that is too
large at
| least with current GL.
Eh? It's called fallback to software. It's the only thing the GL spec
allows you to do. We've been do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
|> Ian Romanick wrote:
|>
|> | I've read the GEM documentation several times, and I think I have a
good
|> | grasp of it. I don't have any non-trivial complaints about GEM, but I
|> | do have a coupl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| Thanks Ian to stress current and future usage, i was really hopping that
| with GL3 buffer object mapping would have vanish but i guess as you said
| that the fire-and-forget path never get optimized.
I think various drivers ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 00:14 -0700, Ian Romanick wrote:
|
|> - - I'm pretty sure that the read_domain = GPU, write_domain = CPU case
|> needs to be handled. I know of at least one piece of hardware with a
|> kooky
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
| I've read the GEM documentation several times, and I think I have a good
| grasp of it. I don't have any non-trivial complaints about GEM, but I
| do have a couple comments / observations:
|
| - I'm prett
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
I had a whole bunch of other stuff written, but I deleted it. I started
~ having Jon Smirl deja vu. Life is hard for us because King Solomon cut
our drivers in half. He gave half to usermode and half to the kernel.
~ Wah! W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
|> I honestly don't see a problem with having multiple memory managers. We
|> have different hardware with different functionality and different
|> performance characteristics. The probability of one memory manager
|> fitting every
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
| Yes, that was really my point. If the memory manager we use (whatever
| it is) does not allow this kind of behaviour, that'll force all cards
| to use a kernel-validated command submission model, which might not be
| too fa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Wed, 2008-05-14 at 21:41 +0200, Thomas Hellström wrote:
|
|> As you've previously mentioned, this requires caching policy changes and
|> it needs to be used with some care.
|
| I did't need that in my drivers as GEM handles th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
|> | Please pull the 'drm-patches' branch from
|> | ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
|> drm-patches
|>
|> I just realized that the XGI DRM never got pushed upstream. Could that
|> happen? The DDX
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
| Please pull the 'drm-patches' branch from
| ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
I just realized that the XGI DRM never got pushed upstream. Could that
happen? The DDX for that card i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Victor Stinner wrote:
| Here is my first patch for Nouveau project: a fix for 3D software
| rendering using SSE2 instruction set.
|
| The problem is that Gallium doesn't save/restore used registers (eax,
| edx, ecx, esi in my case). So I added push/po
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
| Ok, anyone else interested (ATM it's Jerome - Idr - Alex - me) ?
|
| The deadline for project applications is wednesday so we'll have to
| write the proposal for DRI quick now. Hopefully it works out.
Link missing in previo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
| Ok, anyone else interested (ATM it's Jerome - Idr - Alex - me) ?
|
| The deadline for project applications is wednesday so we'll have to
| write the proposal for DRI quick now. Hopefully it works out.
There's a straw-man pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johan Bilien wrote:
| On Fri, Jan 18, 2008, Ian Romanick wrote:
|> Johan Bilien wrote:
|> | Is it possible to share an (indirect) GL context accelerated with
AIGLX?
|> | The idea would be to have several clients render to FBOs and a
|>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johan Bilien wrote:
| Is it possible to share an (indirect) GL context accelerated with AIGLX?
| The idea would be to have several clients render to FBOs and a
| compositor client rendering the final scene.
Technically, it should work. In fact, that'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
> Yes, it should be backward compatible. The req is smaller than the rep,
> so adding new members won't change the alignment. Also, as the flag
> indicates whether the additional data is present, older clients won't
> accidentally
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert P. J. Day wrote:
> is there something special about the drm_order() routine in
[snip]
> that it can't simply be replaced by an appropriate call to ilog2()
> defined in include/linux/log2.h? just curious.
I guess the bigger question is why
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> The other option is to calculate how many vblank interrupts have
> occurred between off and on periods. You could do this by recording
> the time when interrupts were disabled, figuring out how much time has
> passed between
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp Klaus Krause wrote:
> Some time ago Vector Quantisation (VQ) texture compression was
> implemented in some chips like the PowerVR series or the ATI MAch64 and
> R128.
> Is this still supported by today's hardware?
As far as I know, only DXTC i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Wed, 2007-10-03 at 14:08 -0700, Ian Romanick wrote:
>> diff --git a/linux-core/xgi_cmdlist.c b/linux-core/xgi_cmdlist.c
>> index 261f4e1..35f7e1b 100644
>> --- a/linux-core/xgi_cmdlist.c
>> +++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maarten Maathuis wrote:
> Please check the first patch, the second is only to give you an idea
> why i would want this. Only implemented for linux, since i lack a bsd
> system.
>
> Anything wrong with this?
I guess I don't understand the need for th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> On Friday, September 28, 2007 11:02 am Ian Romanick wrote:
>> Jesse Barnes wrote:
>>> On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
>>>> I do have one question now. What happens (or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
>> I do have one question now. What happens (or is intended to happen)
>> if the currently bound drawable is not a window?
Any thoughts on this?
>&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> Per the discussion in the other vblank thread, this patch does several
> things:
> - adds a new getMSC hook to __DRIdrawableRec
> - updates glXGetVideoSyncSGI to use the new hook if present
> - adds new vblank fields to __DR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
>> It seems that drivers that set their MSC routines to NULL will return
>> GL_BAD_CONTEXT from calls like glXWaitVideoSyncSGI(), and if e.g.
>> drmWaitVBlank() failed clie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> Both the generic DRM vblank-rework and Intel specific pipe/plane
> swapping have uncovered some vblank related problems which we discussed
> at XDS last week. Unfortunately, no matter what we do (including
> the "do nothing" o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Instead of adding drm_zalloc, why not just use drm_calloc? At the very
least just make drm_zalloc a macro that calls drm_calloc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG1H5pX1gOwKyEAw8RAuXrAJ9W+Oyaimcedg0LdDqwqfMgX9Gl2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jacek Poplawski wrote:
> Would you recommend i830 or Radeon M6?
> Stability is most important, then performance.
>
> I use Beryl on i845 (8 hours per day, 5 days per week) and it works
> perfectly, how i845 driver compares to i830?
> How M6 driver co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jacek Poplawski wrote:
> I want to buy an old notebook with video card supported by DRI.
> I know that Intel 810 is perfectly supported, but I want to buy
> something cheaper (and older).
>
> Most of the pentium3 notebooks use S3 Savage and ATI Rage M
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
> Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for
> d3d-only hardware). The different appearance is caused by the 965 driver
> mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to
> GL_CLAMP_TO_ED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger wrote:
> Indeed this show up every once in a while. A driconf option might be a
> good idea, but it doesn't solve the problem really for the hardware
> which indeed does support GL_CLAMP, unless you'd also introduce an
> option to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a question and a possible bug.
What is a driver supposed to do if its emit function is called for a
fence that is already complete? In particular, there are some quirks
with the way the XP10 does command lists that make it non-trivial to get
a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
>> On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
>>> ick. just read the registers and return the value here. We should place
>>> wrap-detection in the core code by r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> We've had some IRC and off-list discussions about how to improve the
> DRM's vblank code to be a bit more power friendly. The core requirement
> is that we only enable vblank interrupts when a client is actually waiting
> for a v
1 - 100 of 1312 matches
Mail list logo
