This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.
Signed-off-by: Keith Packard
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi_display.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/src/intel
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_private.h | 11
NULL parameter to drmCrtcQueueSequence ioctl as we
don't care what sequence the event was actually queued to.
v3: Adapt to pthread clock switch to MONOTONIC
v4: Fix scope for wsi_display_mode andwsi_display_connector allocs
Suggested-by: Jason Ekstrand
Signed-off-by: Keith Pa
d-by: Eric Engestrom
Move mode list from wsi_display to wsi_display_connector
Fix scope for wsi_display_mode and wsi_display_connector allocs
Suggested-by: Jason Ekstrand
Signed-off-by: Keith Packard
---
configure.ac| 32 +++
m
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_private.h | 4
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 12
2 files changed, 13 insertions(+)
diff
This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application to the anv driver.
v2:
Simplify addition of VK_USE_PLATFORM_XLIB_XRANDR_KHR to
vulkan_wsi_args
Suggested-by: Eric Engestrom
Signed-off-by: Keith Packard
This adds support for the VK_GOOGLE_display timing extension.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 33 -
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan
Eric Engestrom writes:
> Cc: Keith Packard
> Signed-off-by: Eric Engestrom
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedeskt
Eric Engestrom writes:
> I'm still slightly bothered by the build options inconsistency between
> autotools: reuse --with-platform=drm
> meson: new -D platform=display
>
> I'd be happy with either one being used everywhere, but from what you
> said last time I think you'd prefer to reus
Jason Ekstrand writes:
> On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard wrote:
>
> Once we're sure that's what we want, create an MR against the spec that
> just adds enough to the XML to reserve your extension number. That will
> get merged almost immediately. Then m
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT
v3: Fix wayland WSI, regularize spelling
Misspelled 'surface' in get_capabilities2ext
Remove extra _ from get_capabilities_2ext in a couple of places
v4: Add anv support
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/
NULL parameter to drmCrtcQueueSequence ioctl as we
don't care what sequence the event was actually queued to.
v3: Adapt to pthread clock switch to MONOTONIC
v4: Add support for anv
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_priv
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.
Signed-off-by: Keith Packard
This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application. For DRM, we use the
Linux resource leasing mechanism.
Signed-off-by: Keith Packard
---
configure.ac | 25 ++
meson.build| 17
familiar with those systems and
should not require any additional device-specific code.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 32 +
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi.c | 29
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi_display.c | 11 +++
src/intel/vulkan/anv_extensions.py | 1 +
src/intel
Here's a series of extensions necessary to perform reasonable direct
display operations, either directly through DRM with no window system,
or using RandR and Linux leases.
There's one new extension, MESA_query_timestamp which performs the
same operation as glGetInteger64v(GL_TIMESTAMP, ×tamp) --
This adds support for the KHR_display extension to the anv and radv
Vulkan drivers. The drivers now attempt to open the master DRM node
when the KHR_display extension is requested so that the common winsys
code can perform the necessary operations.
Signed-off-by: Keith Packard
---
configure.ac
Eric Engestrom writes:
> copy/paste error: s/drm/display/
That's actually intentional -- any system which supports 'drm' can
support the display backend as it's based on that. Maybe it should use a
different test? (note that I haven't been using the autotools backend
recently, so it may not be g
Emil Velikov writes:
> A few top level comments:
Thanks much for looking over this code. I realize it's a large amount of
change and hence more work to review.
> - using card/primary node and (missing) authentication
> Current code opens the primary node when VK_KHR_display is available.
> Thu
Lionel Landwerlin writes:
> I'm assuming the correlation is done outside the vulkan driver? With a
> clock_gettime() maybe?
>
> If that's the case, I'm afraid this will be highly inaccurate.
> The kernel might execute other tasks when the ioctl() happens and that
> might introduce (in my experi
This adds support for the KHR_display extension to the anv Vulkan
driver. The driver now attempts to open the master DRM node when the
KHR_display extension is requested so that the common winsys code can
perform the necessary operations.
Signed-off-by: Keith Packard
---
src/intel
This adds support for the KHR_display extension to the radv Vulkan
driver. The driver now attempts to open the master DRM node when the
KHR_display extension is requested so that the common winsys code can
perform the necessary operations.
Signed-off-by: Keith Packard
---
src/amd/vulkan
This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application to the anv driver.
Signed-off-by: Keith Packard
---
src/intel/Makefile.vulkan.am | 7 +++
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan
Dave Airlie asked me to split these up so that the core and anv/radv
bits were all in separate patches.
There are no code changes here aside from fixing the KHR_display
version from 1 to 23. I also fixed the indentation in the changes to
the radv driver from spaces to tabs as per convention.
-kei
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.
Signed-off-by: Keith Packard
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
src/vulkan/wsi/wsi_common_display.c | 17 +
src/vulkan/wsi/wsi_common_display.h | 5 +
2 files changed, 22 insertions(+)
diff --git
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi_display.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/src/intel
This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application. For DRM, we use the
Linux resource leasing mechanism.
Signed-off-by: Keith Packard
---
configure.ac| 32 +++
meson.build | 17
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_private.h | 4
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
v4: Add anv support
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi.c | 12
2 files changed
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.
Signed-off-by: Keith Packard
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_private.h | 11
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi_display.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/src/amd
This adds support for the VK_GOOGLE_display timing extension.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 32
2 files changed, 33 insertions(+)
diff --git a/src/amd/vulkan/radv_extensions.py
b
This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application to the radv driver.
Signed-off-by: Keith Packard
---
src/amd/vulkan/Makefile.am| 7 +++
src/amd/vulkan/meson.build| 7 +++
src/amd/vulkan/radv_extensions.py
NULL parameter to drmCrtcQueueSequence ioctl as we
don't care what sequence the event was actually queued to.
v3: Adapt to pthread clock switch to MONOTONIC
Signed-off-by: Keith Packard
---
src/vulkan/wsi/wsi_common.h | 9 ++
src/vulkan/wsi/wsi_common_display.c
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 12
2 files changed, 13 insertions(+)
diff
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT
v3: Fix wayland WSI, regularize spelling
Misspelled 'surface' in get_capabilities2ext
Remove extra _ from get_capabilities_2ext in a couple of places
Signed-off-by: Keith Packard
---
src/vulkan/wsi/wsi_common.c | 11 +++
src/
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.
Signed-off-by: Keith Packard
This adds support for the VK_GOOGLE_display timing extension.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi.c | 29 +
2 files changed, 30 insertions(+)
diff --git a/src/intel/vulkan/anv_extensions.py
b
This adds support for the KHR_display extension support to the vulkan
WSI layer. Driver support will be added separately.
Signed-off-by: Keith Packard
---
configure.ac|1 +
meson.build |4 +-
src/amd/vulkan/radv_wsi.c |3
familiar with those systems and
should not require any additional device-specific code.
Signed-off-by: Keith Packard
---
src/vulkan/wsi/wsi_common.c | 254 +++-
src/vulkan/wsi/wsi_common.h | 24
src/vulkan/wsi/wsi_common_display.c | 143
Jason Ekstrand writes:
> It seems a little odd to me to default to opening the master node and then
> fall back to the render node if it doesn't work. I suppose that's probably
> ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR
> returns no displays if we're on the render nod
Eric Engestrom writes:
> Can be simplified a bit:
>
> _xlib_lease = get_option('xlib-lease')
> if _xlib_lease == 'auto'
> with_xlib_lease = with_platform_x11 and with_platform_display
> else
> with_xlib_lease = _xlib_lease == 'true'
> endif
>
> (We also usually try to avoid changi
quote from the
Vulkan spec.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
b/src/amd/vulkan/radv_entrypoints_gen.py
index 377b544c2aa..69e6fc3e0eb 100644
--- a/src/
Jason Ekstrand writes:
> Actually, I think anv is doing the right thing too. Now I have no idea why
> Keith was having problems.
anv is happily returning a valid pointer and radv is not?
In any case, I've switched to using vkGetInstanceProcAddr for the
VkPhysicalDevice function and it works fi
Five tests:
1) Check for non-null function pointers
2) Check for in-range time domains
3) Check monotonic domains for correct values
4) Check correlation between monotonic and device domains
5) Check to make sure times in device domain match queue times
Signed-off-by: Keith Packard
Offers three clocks, device, clock monotonic and clock monotonic
raw. Could use some kernel support to reduce the deviation between
clock values.
v2:
Ensure deviation is at least as big as the GPU time interval.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_device.c | 84
Jason Ekstrand writes:
> We're using MRs for crucible. Please create one and make sure you check
> the "Allow commits from members who can merge to the target branch" so it
> can be rebased through the UI by someone other than yourself.
OOo. Shiny!
--
-keith
signature.asc
Description: PGP s
AX2 and DIV_ROUND_UP instead of open coding these.
Delete spurious TIMESTAMP in radv version.
Suggested-by: Jason Ekstrand
Suggested-by: Lionel Landwerlin
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_device.c | 81 +++
src/amd/vul
Jason Ekstrand writes:
> You need to add this to anv_gem_stubs.c as well or else the unit tests
> won't build. Sorry for not catching it earlier. I'm always missing this
> too.
Well, that's a bit hard to test as -Dbuild-tests=true fails in a bunch
of glx tests, but I think I've got it.
> Wit
AX2 and DIV_ROUND_UP instead of open coding these.
Delete spurious TIMESTAMP in radv version.
Suggested-by: Jason Ekstrand
Suggested-by: Lionel Landwerlin
v4:
Add anv_gem_reg_read to anv_gem_stubs.c
Suggested-by: Jason Ekstrand
Signed-off-by: Keith Pack
Bas Nieuwenhuizen writes:
>> + end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
>> +
>> + uint64_t clock_period = end - begin;
>> + uint64_t device_period = DIV_ROUND_UP(100, clock_crystal_freq);
>> +
>> + *pMaxDeviation = MAX2(clock_period, device_period);
>
> Should th
Jason Ekstrand writes:
> I think what Bas is getting at is that there are two problems:
>
> 1) We are not sampling at exactly the same time
> 2) The two clocks may not tick at exactly the same time.
Thanks for the clarification.
> If we want to be conservative, I suspect Bas may be right that
Jason Ekstrand writes:
> You've got me almost convinced as well. Thanks for the diagrams! I think
> instead of adding 1 perhaps what we want is
>
> max2(sample_interval_ns, gpu_tick_ns + monotonic_tick_ns)
>
> Where monotonic_tick_ns is maybe as low as 1. Am I following you correctly?
Not qu
Bas Nieuwenhuizen writes:
> Well the complication here is that in the MONOTONIC (not
> MONOTONIC_RAW) case the CPU measurement can happen at the end of the
> MONOTONIC_RAW interval (as the order of measurements is based on
> argument order), so you can get a tick that started `period` (5 in
> thi
Bas Nieuwenhuizen writes:
> You can make the monotonic case the same as the raw case if you make
> sure to always sample the CPU first by e.g. splitting the loops into
> two and doing CPU in the first and GPU in the second. That way you
> make the case above impossible.
Right, I had thought of t
Jason Ekstrand writes:
> The result is that we're looking at something like "end - start +
> monotonic_raw_tick + max(gpu_tick, monotonic_tick)" Have I just come
> full-circle?
Yes. As monotonic_raw_tick and monotonic_tick are both 1...
--
-keith
signature.asc
Description: PGP signature
_
Jason Ekstrand writes:
> Doing all of the CPU sampling on one side or the other of the GPU sampling
> would probably reduce our window.
True, although as I said, it's taking several µs to get through the
loop, and the gpu clock tick is far smaller than that, so even adding
the two values togethe
ion computation to max(sampled_clock_period) +
sample_interval.
Suggested-by: Bas Nieuwenhuizen
Suggested-by: Jason Ekstrand
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_device.c | 119 +++
src/amd/vulkan/radv_extensions.py |
Jason Ekstrand writes:
> I like it
When the comments are longer than the code, you know you're done?
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
Bas Nieuwenhuizen writes:
> Reviewed-by: Bas Nieuwenhuizen
Thanks to you, Jason and Lionel for reviewing the code and helping
improve it.
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
Adapt to changes in MESA_query_timestamp extension
v5:
Squash core bits and anv/radv wrappers into a single patch
Suggested-by: Jason Ekstrand
v6:
Switch from MESA_query_timestamp to EXT_calibrated_timestamps
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_ext
Michel Dänzer writes:
Thanks for taking time to review this patch!
>> + int64_t refresh = (int64_t) refresh_timing.refreshDuration;
>> + int64_t frames = (delta_nsec + refresh/2) / refresh;
>
> desiredPresentTime has "no sooner than" semantics, so I think this should
This means
rounding the target frame up, rather than selecting the
nearest one.
Suggested-by: Michel Dänzer
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 33 +++
src/intel/vulkan/anv_extensions.py |
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.
Signed-off-by: Keith Packard
v2
Here's an updated version of the extension to get GPU timestamps. This
version returns both CPU and GPU timestamps which could (in theory) be
more tightly correlated than just getting the time of one and then the
other sequentially. The idea is that we'd eventually add a suitable
kernel ioctl to ge
, all of our backends
use CLOCK_MONOTONIC, so there's nothing actually doing
conversions, but it seemed best to put the infrastructure in
place so that I could validate the extension interface would
work if that became necessary.
Signed-off-by: Keith Packard
--
both device and
surface timestamps.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_gem.c | 13 +
src/intel/vulkan/anv_private.h | 3 +++
src/intel/vulkan/genX_query.c | 30 ++
4
Pekka Paalanen writes:
> On Sat, 23 Jun 2018 12:13:53 -0500
> Jason Ekstrand wrote:
>
>> I haven't thought through this comment all that hard but would it make
>> sense to have three timestamps, CPU, GPU, CPU so that you have error bars
>> on the GPU timestamp? At the very least, two timestam
Pekka Paalanen writes:
> I did not mean you would be solving that problem. I meant that it would
> be good to figure out what people actually want from the API to be able
> to solve the problem themselves.
Thanks for the clarification. I'd suggest that we not try and solve that
problem until we
"Mao, David" writes:
> Hi Keith,
> If I read the patch correctly, the plane has been interpreted as the same as
> connector, and the stackIndex is the index of connector of current device.
> Is it by intentional?
> If the hardware don't have underlay/overlay supported, is it better to
> always r
omplete to make
the functionality clearer.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 33 +++
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi.c | 31 +++
src/vulkan/wsi/ws
I spent some time over the last week experimenting with a different way
of doing frame timing.
Instead of specifying *when* a particular frame should be displayed, how
about we specify how *long* a particular frame should be made visible
to the user?
This has a couple of advantages over the appr
Michel Dänzer writes:
> Instead of rounding to the nearest upcoming frame, should it round to
> the earliest frame after the specified period has passed? As written, it
> seems to contradict the next paragraph below:
Sorry for the poor wording; let me describe what I want informally here.
For n
"Matias N. Goldberg" writes:
> I read your article.
Thanks!
> What I feel are missing are just minor pesky details:
Yes, it's definitely a rough draft at best. Figuring out the right words
to make it do precisely what we want is hard, and I'm hoping we can
first figure out what we want, then f
Michel Dänzer writes:
> Hmm, I didn't fully realize this in my reading of the draft, thanks
> Matias for pointing it out!
>
> That the timing of frame N+1 has to be specified when submitting frame
> N for presentation is odd to me TBH. While I can imagine this might be
> suitable for some apps su
Michel Dänzer writes:
>> actual_period = n * r - ε
>
> Is that still an issue if the (minimal) length of a vertical blanking
> period is subtracted from the computed period?
What you're doing is defining a 'window' of times which match the
desired frame -- any time within 'length of vertical bla
Michel Dänzer writes:
> With variable refresh rate, it could certainly be useful for the kernel
> to have this information as early as possible. It shouldn't make any
> difference with fixed refresh though, since the kernel should always be
> able to hit the next refresh in that case as long as t
Michel Dänzer writes:
> I think at least the following needs to happen first:
>
> * At least a prototype of plumbing through this information to the
> amdgpu kernel driver (or another one which may grow VRR support) and
> making use of it for adjusting the refresh periods to allow hitting
> the t
Michel Dänzer writes:
> Should this extension specify how it interacts with the various
> VK_PRESENT_MODE_* modes?
Yes. It needs to be clear on how this extension interacts with all
existing display stuff. Thanks for pointing out one pretty important
interaction.
> For one example: With VK_PRES
Austin Shafer writes:
> I'm just curious if there is a technical reason why blending isn't
> allowed, as the vulkan spec seems to permit it.
Just not implemented yet.
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa
Michel Dänzer writes:
> I assume 2. refers to the case of a single late frame, where the next
> frame hitting the original absolute target would result in a second
> visible stutter. While writing
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234
> , it occurred t
On Tue, 20 Sep 2011 15:37:20 -0400, Matt Turner wrote:
> - checking for the appropriate Xrandr version.
> XRRGetScreenResourcesCurrent is a 1.3 function. It's not totally
> clear to me what the difference between it and XRRGetScreenResources
> is. (These aren't docum
On Mon, 3 Oct 2011 16:26:20 +0200, Luc Verhaegen wrote:
> Keith, at XDC you mentioned filling half a day with wayland stuff. Do
> solidify this ASAP so i can make sure that we get saturday as well.
I'm working on this -- as you might imagine, getting funding for an
event this far in advance is
On Tue, 3 May 2011 12:21:24 -0700, Jesse Barnes
wrote:
> We only spec a 32 bit swap count, so drop the high sbc field.
You're missing the explicit 16-bit padding field after 'event_type'
The documented encoding
http://www.opengl.org/registry/specs/INTEL/swap_event.txt needs to be
fixed to mat
On Tue, 3 May 2011 14:08:58 -0700, Jesse Barnes
wrote:
> Fixed version below.
Reviewed-by: Keith Packard
(assuming that the GLX protocol specification gets updated to match :-)
--
keith.pack...@intel.com
pgpmw6kAybqOk.pgp
Description: PGP signat
On Fri, 17 Jun 2011 17:43:14 -0700, Dan McCabe wrote:
> break; // implicit exit from loop at end of switch
> } while (true);
Seems like this could just be
} while (false);
as I don't see any way the loop could go around more than once.
--
keith.pack...@intel.com
On Mon, 27 Jun 2011 17:23:30 -0700, Dan McCabe wrote:
> Since I am just about to start modifying the IR generation, I'm open to
> suggestion.
I'd write the simplest possible code that works now and then consider
optimizing it later. This has the advantage that you can get a bunch of
tests worki
On Tue, 15 Mar 2011 13:52:40 +1000, Dave Airlie wrote:
> a) undo ajax's cleanup, fix generator scripts to work again (not sure
> how possible that is
> since Olv's mapi changes), import latest GLX into server on a
> semi-regular basis.
The X server generator seems like it'll bit-rot if not used
On Tue, 4 May 2010 08:34:00 -0400, Ben Gamari wrote:
> a standard non-recursive makefile structure, as is used
> in, say, Keith Packard's notmuch[1] project.
That's Carl Worth's notmuch project, and it was his idea to build using
make alone. I'd have to say that while it makes the build system e
201 - 294 of 294 matches
Mail list logo
