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 kei...@keithp.com
One nit below. With that changed,
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
-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
interval
-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 chance to look at the patches
until at least late
-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:
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 points to end-up with the same function
-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 glXGetProcedureAddress to get the valid existing
-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
Tormod Volden wrote:
From: Tormod Volden debian.tor...@gmail.com
---
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
-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.h
-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:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
On Mon, 16 Nov 2009 11:51:31 -0800
Ian Romanick i...@freedesktop.org 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
buffers
-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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 43
+
src/mesa/drivers/dri/intel/intel_context.c|1 +
2 files changed, 44
-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 the build.
-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
-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 (against the
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.
We
-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-
render the
-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
the prefix in the macro definition of DRM_DEBUG_KMS/DRIVER/MODE.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Acked-by: Ian Romanick ian.d.roman...@intel.com
---
drivers/gpu/drm/drm_modes.c |8 +++-
drivers/gpu/drm/i915/i915_dma.c | 35
be replaced
by the DRM_DEBUG_KMS.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Acked-by: Ian Romanick ian.d.roman...@intel.com
---
drivers/gpu/drm/drm_modes.c |4 ++--
include/drm/drmP.h |7 ---
2 files changed, 2 insertions(+), 9 deletions(-)
Index: linux-2.6
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 kei...@keithp.com
Acked-by: Ian Romanick ian.d.roman...@intel.com
---
drivers/gpu/drm/i915
/blt acceleration while only falling back to software for operations
involving the 3D engine.
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/i830_driver.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git
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
Pushed. Thanks.
signature.asc
Description: Digital signature
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
configure.ac. Comments?
commit 716e4ad01bac6fdb6e3f433300df3cf50116d3b1
Author: Ian Romanick ian.d.roman...@intel.com
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).
Set
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 suok...@gmail.com
Date: Sun, 5 Jul 2009 18:31:18 +0300
Subject: [PATCH 5/6] libdrm: Make chown check for
-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 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 pushed
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 = xyes;
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 configure.ac. Comments?
maybe use
-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 patch the puts _XOPEN_SOURCE and _GNU_SOURCE in config.h
-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 if
-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
will allocate buffer
of new size.
You are 100% correct. Good catch.
Acked-by: Ian Romanick ian.d.roman...@intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-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 yakui.z...@intel.com
---
drivers/gpu/drm/drm_modes.c | 210
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
On Tue, May 5, 2009 at 12:20 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 04 May 2009 19:14:29 -0700
Ian Romanick i...@freedesktop.org wrote:
Having this ability would allow us to advertise some fbconfigs
-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
Jesse Barnes wrote:
On Mon, 04 May 2009 14:45:07 -0700
Ian Romanick i...@freedesktop.org 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?
Yes. I should probably
-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.
-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
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). It
is mostly just copied from
-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 in
-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 interrupts
YesNoDisable IRQ
-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 would matter?
-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
-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
sensible behavior in all
-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
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
-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
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 linux/vmalloc.h
-
Why remove this one and not the one at the top of
-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 with
-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 context B when
| context
-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
-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 a shared
| | object in context
-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!
-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 pretty sure
-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 command buffer
-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
-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 couple comments / observations
-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
-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 i can still
use
-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) {
| /* fail
-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
| path. Applications are being
-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 might
-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
-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
-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 the
-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
-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
-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
-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
-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
-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
| | compositor client
-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,
-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 is
-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
+++ b/linux-core/xgi_cmdlist.c
@@ -45,7
-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 the
-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?
Also, the current code
-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 is intended to
happen) if the currently
-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 clients
-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
-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
-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)
-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
-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
-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
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_EDGE.
-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
-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 reporting
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
Hi,
I've been working on updating the DRI interface
(GL/internal/dri_interface.h) the last few days and I though I'd post
a heads up to the lists to get some feedback. The work I've been
doing starts out with the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger wrote:
So, when trying to implement ARB_point_parameters and ARB_point_sprite,
I came across some problem (this tnl stuff is hard to follow). The
problem is, I need to set some hardware state dependant on the primitive
being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger wrote:
Roland Scheidegger wrote:
I thought there was a mechanism that allowed the driver to be
notified at glBegin (or similar) time. It seems like you ought to be
able to emit some extra state at that time to change to / from
1 - 100 of 1168 matches
Mail list logo
