ETA for DRI2
Hi, is the plan of having DRI2 and Kristian's efforts for redirected direct rendering for Fedora 9 still actual? At least the device independent part? Thanks! -- Johan Bilien [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14094] DRI version GIT - Intel 956GM DRI crash - Segmentation fault in intel_fbo. c:369
http://bugs.freedesktop.org/show_bug.cgi?id=14094 --- Comment #1 from vaLentin [EMAIL PROTECTED] 2008-01-16 01:25:18 PST --- Created an attachment (id=13743) -- (http://bugs.freedesktop.org/attachment.cgi?id=13743) Xorg log Xorg.log.0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14094] New: DRI version GIT - Intel 956GM DRI crash - Segmentation fault in intel_fbo. c:369
http://bugs.freedesktop.org/show_bug.cgi?id=14094 Summary: DRI version GIT - Intel 956GM DRI crash - Segmentation fault in intel_fbo.c:369 Product: DRI Version: DRI CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: high Component: libdrm AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Created an attachment (id=13742) -- (http://bugs.freedesktop.org/attachment.cgi?id=13742) Xorg conf file Hi. I have a laptop which has Intel 965GM on board video device. Recently I have reported a bug to the mesa developers: https://bugs.freedesktop.org/show_bug.cgi?id=13492 Eric Anholt fixed it and I would like to thank him about that. After I saw that the bug has been marked as resolved I decided to install the latest mesa and dri git versions on my system so I can test and eventually play games that need 3d ac celeration and OpenGL with wine. Before those were failing due to a bug in the mesa library. Ok. I re-installed MESA and DRI from the _GIT_ as per instructions available on the fo llowing web address: http://dri.freedesktop.org/wiki/Building After that the glxinfo binary and the applications which were previously dying in the mesa part of the 3d handling are now crashing in the DRI part. Here we go. In the mesa/configs/linux-dri config file I have: OPT_FLAGS = -pipe -O2 -march=prescott -mtune=prescott -fomit-frame-pointer -g DRI_DIRS = i810 i915 i965 Some other things that might be usefull: Portage 2.1.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.7-r1, 2.6.23-gentoo-r5-sunshine i686) = System uname: 2.6.23-gentoo-r5-sunshine i686 Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz Timestamp of tree: Wed, 16 Jan 2008 06:30:08 + app-shells/bash: 3.2_p33 dev-lang/python: 2.4.4-r8, 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox:1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS=x86 ~x86 CBUILD=i686-pc-linux-gnu CFLAGS=-pipe -O2 -march=prescott -mtune=prescott -fomit-frame-pointer CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc CONFIG_PROTECT_MASK=/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/terminfo /etc/udev/rules.d CXXFLAGS=-pipe -O2 -march=prescott -mtune=prescott -fomit-frame-pointer MAKEOPTS=-j3 PKGDIR=/usr/portage/packages USE=X a52 aac acl acpi alsa amr battery berkdb bitmap-fonts bluetooth bzip2 cdr cli cpudetection cpufreq cracklib crypt doc dri dv dvd dvdnav dvdr dvdread ermt exif ffmpeg fortran gdbm gif glitz gpm gtk hal iconv imlib imlib2 isdnlog jpeg jpeg2k lame lm_sensors mad midi mmx mmxext mp2 mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcmcia pcre perl pmu png pppd python qt-static qt3 quicktime radio readline real realmedia reflection sdl sensord session slang smp socks5 sound spl srt sse sse2 ssl ssse3 svg symlink t cpd tk truetype truetype-fonts truetype2 type1-fonts unicode usb vidix vorbis wifi win32codecs wxwindows x86 xgetdefault xml xorg xvid zlib ALSA_CARDS=ali5451 als4000 atiixp ati ixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci ALSA_PCM_P LUGINS=adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol APACHE2_MODUL ES=actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache da v dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif spel ing status unique_id userdir usertrack vhost_alias CAMERAS=canon ELIBC=glibc INPUT_DEVICES=keyboard mouse synaptics KERNEL=linux LCD_DEVICES=bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text LINGUAS=en bg USERLAND=GNU VIDEO_CARDS=i810 vesa vga Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY Manually compilled and installed mesa and dri from the git repo. I have restarted the X server and DRI is reported to be working correctly: charged [EMAIL PROTECTED]:/usr/local/src$ glxinfo | grep Yes Failed to initialize TTM buffer manager. Falling back to classic. direct rendering: Yes For your reference you can also check the Xorg.log and xorg.conf files attached. However when I try to run glxgears here is what I get: charged [EMAIL
[Bug 13812] quake4 crash X
http://bugs.freedesktop.org/show_bug.cgi?id=13812 --- Comment #4 from Colin.Joe [EMAIL PROTECTED] 2008-01-16 01:30:35 PST --- I have send you email , you can do it as it listed . -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13812] quake4 crash X
http://bugs.freedesktop.org/show_bug.cgi?id=13812 --- Comment #3 from Zou Nan hai [EMAIL PROTECTED] 2008-01-16 01:18:10 PST --- How to bypass the s3tc issue of Q4 demo? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 --- Comment #18 from Igor Mozolevsky [EMAIL PROTECTED] 2008-01-16 01:51:37 PST --- Applying the above patch (11334) leads to screen corruption and no refresh when running apps. Also see http://www.freebsd.org/cgi/query-pr.cgi?pr=119324 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Convert drivers/char/agp/frontend.c to use unlocked_ioctl
As of now, agp_compat_ioctl already runs without the BKL. Mutual exclusion
is enforced by agp_fe.agp_mutex in agp_ioctl() and agp_compat_ioctl().
Apply the same locking rationale to the two functions allowing BKL cleanup.
Signed-off-by: Mathieu Segaud [EMAIL PROTECTED]
---
drivers/char/agp/frontend.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c
index 7791e98..6212a9e 100644
--- a/drivers/char/agp/frontend.c
+++ b/drivers/char/agp/frontend.c
@@ -960,7 +960,7 @@ static int agpioc_unbind_wrap(struct agp_file_private
*priv, void __user *arg)
return agp_unbind_memory(memory);
}
-static int agp_ioctl(struct inode *inode, struct file *file,
+static long agp_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
struct agp_file_private *curr_priv = file-private_data;
@@ -1047,7 +1047,7 @@ static const struct file_operations agp_fops =
.llseek = no_llseek,
.read = agp_read,
.write = agp_write,
- .ioctl = agp_ioctl,
+ .unlocked_ioctl = agp_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = compat_agp_ioctl,
#endif
--
1.5.3.8
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ETA for DRI2
On Jan 16, 2008 3:07 AM, Johan Bilien [EMAIL PROTECTED] wrote: Hi, is the plan of having DRI2 and Kristian's efforts for redirected direct rendering for Fedora 9 still actual? At least the device independent part? Hi, Yes, I'm still expecting to get this done in time for Fedora 9. We have an alpha release coming up in a week (schedule over here: http://fedoraproject.org/wiki/Releases/9/Schedule) and I'm not sure we can make that. However, the final feature freeze is in march, which should be enough time to get this into the release, and upstream, of course. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8357] Rendering with r300 right of 2650px width is disstorted
http://bugs.freedesktop.org/show_bug.cgi?id=8357 Matthias Bläsing [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #19 from Matthias Bläsing [EMAIL PROTECTED] 2008-01-16 08:24:37 PST --- Ok - I'll close this bug as WONTFIX and open an new report against mesa to enable private backbuffers. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] New: r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 Summary: r300 should use private backbuffers Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Hello, As described in bug 8357 the r300 is limited to rendering to a maximal area with a width of 2650px. This also affects the use of application requirering a smaller rendering area, when using it behind the magic barrier. In the discussion of the bug mentioned above Roland Scheidegger comments in comment #17, that this could be circumvented by using private backbuffers instead of one shared backbuffer. I think the dri driver is the right place for this. Thanks in advance -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RFC: render buffer
Hi all, There have been discussion on irc and elsewhere about the need or not of an object describing a render buffer (could be scan-out buffer or or other specialized card render buffer: color buffer, zbuffer, ...). This would mostly act as a wrapper around BO. Here is what i can imagine as an interface for this: - RenderCreate(properties) - RenderMapLinear - RenderMap - RenderUnmap - Renderunreference Properties would be a set of common properties like: - width - height - bit per pixel - pitch - scan out buffer And also driver private properties like: - compressed in this weird specific format - ... At creation you give a set of properties and you can't change them afterward (well i think it's good enough rules). For what this could be use full ? Well first it would be very useful for mode setting as we can then just have a place where constraint on scan out buffer memory layout are properly checked. Right now we just blindly trust user space to provide a big enough buffer. This could also be use full for creating render buffer making cmd checking a lot easier (as we would have access to width, height, pitch or whatever information is needed to make sure that we have a proper target for our rendering command. Also we could offer common interface for scan out buffer where the driver should allocate a proper buffer using only default properties like (width, height, bit per pixel) and it would be up to driver to fill in other properties with good safe default value (alignment, pitch, compressed, ...) I believe having render buffer object concept in kernel make sense for the above mentioned reasons and because in graphics world render buffer are a key concept and every things in end have to deal with it. So to sum-up: - easy checking of proper render buffer in kernel - easy checking of proper scan out buffer in kernel - make user space easier and safer (others things than a dri driver will allocate proper buffer without having to duplicate code). Few more words on map i think it could be use full to provide two different map method one linear specifically means that you want a linear mapping of the buffer (according to width, height, pitch and bpp) the others just ask for mapping and driver could pass some informations on the layout of the mapped memory (tiled, compressed, ...). For implementation is see two possible way: - wrap render buffer around BO - make render buffer a specialized BO by adding a flag into BO and ptr to render buffer structure Second solution likely the easier one. Anyway what are people thought on all that ? Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 Jerome Glisse [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from Jerome Glisse [EMAIL PROTECTED] 2008-01-16 09:27:52 PST --- Well it'snt as easy as that. I think that what ever is the pitch (8192 is hw limit on r300/r400 hw i think) the rendering will be broken above 2650 pixels so to work around this you would have to allocate several small render buffer and then blit then in a bigger one (pitch now becoming the upper limit). I haven't time to checkout that render if broken what ever we do above 2650, to check this disable cliprect and clip things in drm at top of r300_cmd.c and try with a big enough window if things appear properly above 2650 then we might have somethings but this would imply a security risk at it would mean we need to disable clipping which we would hate to do. Private render buffer are needed if we want to have the split solution but i think this should be done in a driver independent way. As a side note iirc fglrx is broken too and can't render above 2650. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 Roland Scheidegger [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #2 from Roland Scheidegger [EMAIL PROTECTED] 2008-01-16 09:34:55 PST --- (In reply to comment #1) Well it'snt as easy as that. I think that what ever is the pitch (8192 is hw limit on r300/r400 hw i think) the rendering will be broken above 2650 pixels so to work around this you would have to allocate several small render buffer and then blit then in a bigger one (pitch now becoming the upper limit). If you really have private render buffers, those will be as big as needed and not bigger, so pitch shouldn't be above 2560 (I think this was the correct number?) if your rendering area (I assume this really means the size of your window in which 3d rendering happens) isn't larger. Blitter can copy to the larger real framebuffer just fine (up to 8k). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
Jerome Glisse wrote: Hi all, There have been discussion on irc and elsewhere about the need or not of an object describing a render buffer (could be scan-out buffer or or other specialized card render buffer: color buffer, zbuffer, ...). This would mostly act as a wrapper around BO. Here is what i can imagine as an interface for this: - RenderCreate(properties) - RenderMapLinear - RenderMap - RenderUnmap - Renderunreference Properties would be a set of common properties like: - width - height - bit per pixel - pitch - scan out buffer And also driver private properties like: - compressed in this weird specific format - ... At creation you give a set of properties and you can't change them afterward (well i think it's good enough rules). For what this could be use full ? Well first it would be very useful for mode setting as we can then just have a place where constraint on scan out buffer memory layout are properly checked. Right now we just blindly trust user space to provide a big enough buffer. This could also be use full for creating render buffer making cmd checking a lot easier (as we would have access to width, height, pitch or whatever information is needed to make sure that we have a proper target for our rendering command. Also we could offer common interface for scan out buffer where the driver should allocate a proper buffer using only default properties like (width, height, bit per pixel) and it would be up to driver to fill in other properties with good safe default value (alignment, pitch, compressed, ...) I believe having render buffer object concept in kernel make sense for the above mentioned reasons and because in graphics world render buffer are a key concept and every things in end have to deal with it. So to sum-up: - easy checking of proper render buffer in kernel - easy checking of proper scan out buffer in kernel - make user space easier and safer (others things than a dri driver will allocate proper buffer without having to duplicate code). Few more words on map i think it could be use full to provide two different map method one linear specifically means that you want a linear mapping of the buffer (according to width, height, pitch and bpp) the others just ask for mapping and driver could pass some informations on the layout of the mapped memory (tiled, compressed, ...). For implementation is see two possible way: - wrap render buffer around BO - make render buffer a specialized BO by adding a flag into BO and ptr to render buffer structure Second solution likely the easier one. Anyway what are people thought on all that ? Pretty much every buffer is potentially a render target, for instance all texture buffers when generating mipmaps, etc. In the example above, different parts of individual buffers may be rendered to with different pitches, etc, ie when targetting different mipmaps. Intel hardware uses the same pitch for all mipmaps, but this is not universal. Furthermore things like GL's pixel buffers may be used with different pitches etc according to the user's whim. In general one of the nicest things about the current memory manager is that it does *not* impose this type of thing on regular buffer management. I've worked with systems that do and it can be very burdensome. It's not like this presents a security issue to the system at large, so the question then is why make it a kernel function? You just end up running into the limitations you've encoded into the kernel in generation n when you're trying to do the work for generation n+1. One motiviation for this sort of thing might be making allocation of fenced memory regions easier (fenced in the sense used in Intel HW, referring to tiled memory). I think that might be better handled specially without encumbering the system as a whole with a fixed interpretation of buffer layout. Is there a specific issue that this proposal is trying to address? Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 --- Comment #3 from Michel Dänzer [EMAIL PROTECTED] 2008-01-16 09:47:28 PST --- With the upcoming DRI2 rework, every driver will use private renderbuffers, and doing it before then isn't very practical. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 --- Comment #19 from Robert Noland [EMAIL PROTECTED] 2008-01-16 10:02:59 PST --- I still don't see any evidence that this is related to locking or AIGLX, which is the origin of this bug. The user in the FreeBSD PR isn't even using AIGLX. This issue appears to be chipset specific and may not be drm related at all. Please file this as a new bug, including versions of xserver, mesa, ddx driver, and drm modules. Also, please verify that the problem does not exist if dri is disabled and what steps are required to demonstrate the screen corruption. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #20 from Eric Anholt [EMAIL PROTECTED] 2008-01-16 10:13:47 PST --- Re-resolve bug from invalid reopening. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
On Wed, 2008-01-16 at 17:35 +, Keith Whitwell wrote: Pretty much every buffer is potentially a render target, for instance all texture buffers when generating mipmaps, etc. In the example above, different parts of individual buffers may be rendered to with different pitches, etc, ie when targetting different mipmaps. Intel hardware uses the same pitch for all mipmaps, but this is not universal. Furthermore things like GL's pixel buffers may be used with different pitches etc according to the user's whim. In general one of the nicest things about the current memory manager is that it does *not* impose this type of thing on regular buffer management. I've worked with systems that do and it can be very burdensome. It's not like this presents a security issue to the system at large, so the question then is why make it a kernel function? You just end up running into the limitations you've encoded into the kernel in generation n when you're trying to do the work for generation n+1. One motiviation for this sort of thing might be making allocation of fenced memory regions easier (fenced in the sense used in Intel HW, referring to tiled memory). I think that might be better handled specially without encumbering the system as a whole with a fixed interpretation of buffer layout. Is there a specific issue that this proposal is trying to address? Keith Well main motivation was for mode setting and command checking, for radeon a proper command checking will need to do a lot of, (width|pitch)*height*bpp + alignment against bo size checking. I do see render buffer object as a way of greatly simplify this. But i won't fight for it, i am well aware that current bo are really nice because it doesn't enforce a policy. I guess my main concern is more about how to ask to mode setting to program card to use this kind or this kind of layout for scan out buffer. Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
Jerome Glisse wrote: On Wed, 2008-01-16 at 17:35 +, Keith Whitwell wrote: Pretty much every buffer is potentially a render target, for instance all texture buffers when generating mipmaps, etc. In the example above, different parts of individual buffers may be rendered to with different pitches, etc, ie when targetting different mipmaps. Intel hardware uses the same pitch for all mipmaps, but this is not universal. Furthermore things like GL's pixel buffers may be used with different pitches etc according to the user's whim. In general one of the nicest things about the current memory manager is that it does *not* impose this type of thing on regular buffer management. I've worked with systems that do and it can be very burdensome. It's not like this presents a security issue to the system at large, so the question then is why make it a kernel function? You just end up running into the limitations you've encoded into the kernel in generation n when you're trying to do the work for generation n+1. One motiviation for this sort of thing might be making allocation of fenced memory regions easier (fenced in the sense used in Intel HW, referring to tiled memory). I think that might be better handled specially without encumbering the system as a whole with a fixed interpretation of buffer layout. Is there a specific issue that this proposal is trying to address? Keith Well main motivation was for mode setting and command checking, for radeon a proper command checking will need to do a lot of, (width|pitch)*height*bpp + alignment against bo size checking. I do see render buffer object as a way of greatly simplify this. But i won't fight for it, i am well aware that current bo are really nice because it doesn't enforce a policy. I guess my main concern is more about how to ask to mode setting to program card to use this kind or this kind of layout for scan out buffer. Modesetting and scanout buffers are a different kettle of fish - it may be reasonable to have more policy there than we currently do, and I don't think that the negatives I'm worried about apply so much to this area. It's quite reasonable to expect that *somebody* in the display stack may have more information than the 3d client driver about the necessary format, layout, etc of a scanout buffer, and that information would be necessary in order to get eg. page flipping to work correctly. It *may* be that the memory manager/kernel module has a role to play in this -- I don't really know one way or another. I guess the argument is stronger when you're talking about cases where the drm module does modesetting itself. It should be possible to put together a proposal in this area that doesn't negatively affect the 3d driver's ability to use buffers as rendertargets in new innovative ways. I'm not sure what it would look like exactly, but I'd be happy to evaluate it in the above terms. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12570] [915 TTM] glean case depthStencil causes Assertion failure in DRI driver
http://bugs.freedesktop.org/show_bug.cgi?id=12570 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added Summary|[TTM] glean case|[915 TTM] glean case |depthStencil causes |depthStencil causes |Assertion failure in DRI|Assertion failure in DRI |driver |driver -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13837] [GLSL] glean/glsl1 fail: gl_FrontFacing var (1)
http://bugs.freedesktop.org/show_bug.cgi?id=13837 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from Eric Anholt [EMAIL PROTECTED] 2008-01-16 13:57:43 PST --- I'm failing to reproduce this one with mesa master on my 965. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
On Wed, 16 Jan 2008 19:49:34 + Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On Wed, 2008-01-16 at 17:35 +, Keith Whitwell wrote: Pretty much every buffer is potentially a render target, for instance all texture buffers when generating mipmaps, etc. In the example above, different parts of individual buffers may be rendered to with different pitches, etc, ie when targetting different mipmaps. Intel hardware uses the same pitch for all mipmaps, but this is not universal. Furthermore things like GL's pixel buffers may be used with different pitches etc according to the user's whim. In general one of the nicest things about the current memory manager is that it does *not* impose this type of thing on regular buffer management. I've worked with systems that do and it can be very burdensome. It's not like this presents a security issue to the system at large, so the question then is why make it a kernel function? You just end up running into the limitations you've encoded into the kernel in generation n when you're trying to do the work for generation n+1. One motiviation for this sort of thing might be making allocation of fenced memory regions easier (fenced in the sense used in Intel HW, referring to tiled memory). I think that might be better handled specially without encumbering the system as a whole with a fixed interpretation of buffer layout. Is there a specific issue that this proposal is trying to address? Keith Well main motivation was for mode setting and command checking, for radeon a proper command checking will need to do a lot of, (width|pitch)*height*bpp + alignment against bo size checking. I do see render buffer object as a way of greatly simplify this. But i won't fight for it, i am well aware that current bo are really nice because it doesn't enforce a policy. I guess my main concern is more about how to ask to mode setting to program card to use this kind or this kind of layout for scan out buffer. Modesetting and scanout buffers are a different kettle of fish - it may be reasonable to have more policy there than we currently do, and I don't think that the negatives I'm worried about apply so much to this area. It's quite reasonable to expect that *somebody* in the display stack may have more information than the 3d client driver about the necessary format, layout, etc of a scanout buffer, and that information would be necessary in order to get eg. page flipping to work correctly. It *may* be that the memory manager/kernel module has a role to play in this -- I don't really know one way or another. I guess the argument is stronger when you're talking about cases where the drm module does modesetting itself. It should be possible to put together a proposal in this area that doesn't negatively affect the 3d driver's ability to use buffers as rendertargets in new innovative ways. I'm not sure what it would look like exactly, but I'd be happy to evaluate it in the above terms. Keith Well we did have some more discussion on irc about this and i think that having this informations for framebuffer is the only place where this is truely needed. We already have special interface for framebuffer so i guess we could work our way from there without impacting bo. For things other than framebuffer i think the main outcome of the discussion we had is that this kind of informations should be exchanged in user space btw program who cares. For instance in an X server this kind of informations would be exchanged throught dri2, so we might just have to limit bo sharing to a group of client behind a same master (i am thinking of Dave'smulti-master work here which might bring us the foundation for this). So xserver is a drm master and each xserver client is a drm child or dependant of this master and bo can only be shared through the master. And finaly checking bo size even if we need to do some computation like (width*height*bpp) won't kill the performance and will let the user use its buffer in whatever way it sees fit as long as it doesn't go beyond the size. Cheers, Jerome Glisse [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13923] mesa unichrome crash in draw_rgba_pixels when starting torcs
http://bugs.freedesktop.org/show_bug.cgi?id=13923 Benno Schulenberg [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #2 from Benno Schulenberg [EMAIL PROTECTED] 2008-01-16 15:42:37 PST --- From the backtrace it doesn't seem to be specific to a Unichrome. Could Andrey try Mesa HEAD from git? Torcs does not segfault here on a Unichrome with the latest git. (But it freezes when ready to race -- not much better.) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13922] Failed to initialize TTM buffer manager
http://bugs.freedesktop.org/show_bug.cgi?id=13922 Michael Fu [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #10 from Michael Fu [EMAIL PROTECTED] 2008-01-16 17:02:19 PST --- *** Bug 14094 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13916] [i965 vertex program] operation SGE/SLT works incorrectly
http://bugs.freedesktop.org/show_bug.cgi?id=13916 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Shuang He [EMAIL PROTECTED] 2008-01-16 17:19:39 PST --- fixed by Eric's commit(9bae03a583fc6d2d0b916961279abe9156078d1e) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13916] [i965 vertex program] operation SGE/SLT works incorrectly
http://bugs.freedesktop.org/show_bug.cgi?id=13916 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Shuang He [EMAIL PROTECTED] 2008-01-16 17:20:01 PST --- verified, thanks -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13615] [TTM i965]mesa xdemo 'glthreads' run failed on 64bit 965
http://bugs.freedesktop.org/show_bug.cgi?id=13615 Colin.Joe [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13615] [TTM i965]mesa xdemo 'glthreads' run failed on 64bit 965
http://bugs.freedesktop.org/show_bug.cgi?id=13615 Colin.Joe [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14104] New: Assertion `intel-batch-id == intel-last_state_batch_id' failed with i915_dri.
http://bugs.freedesktop.org/show_bug.cgi?id=14104 Summary: Assertion `intel-batch-id == intel- last_state_batch_id' failed with i915_dri. Product: Mesa Version: CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: high Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Created an attachment (id=13756) -- (http://bugs.freedesktop.org/attachment.cgi?id=13756) Xorg log Invoking mesa-demos such as ipers, geartrain, gamma, cube_demo, fire then demos are aborted displaying a error message as follows. fire: intel_tris.c:114: intelStartInlinePrimitive: Assertion `intel-batch-id == intel-last_state_batch_id' failed. Aborted Environment CPU : Pentium4 2.66GHz MEM : 512MB Video memory : 8MB stolen Chipset : intel 82865G OS : Fedora core rawhide linux-2.6.24-0.156.rc8.fc9 mesa : 7.1.0 git version 20080117 drm : 2.3.1 git version 20080117 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14104] Assertion `intel-batch-id == intel-last_state_batch_id' failed with i915_dri.
http://bugs.freedesktop.org/show_bug.cgi?id=14104 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Shuang He [EMAIL PROTECTED] 2008-01-16 20:50:20 PST --- seems a duplicate of bug #14073 *** This bug has been marked as a duplicate of bug 14073 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14073] [32bit i915]3D application 'openarena' freeze tty
http://bugs.freedesktop.org/show_bug.cgi?id=14073 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #8 from Shuang He [EMAIL PROTECTED] 2008-01-16 20:50:20 PST --- *** Bug 14104 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12036] X freezes when running Wine on a P4M800 Unichrome Pro (Card ID: 3344)
http://bugs.freedesktop.org/show_bug.cgi?id=12036 Wei Mingzhi [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Wei Mingzhi [EMAIL PROTECTED] 2008-01-16 22:07:38 PST --- It seems this bug was solved in the latest 7.0.2 version of Mesa. Running glxinfo will no longer result in segfault and Wine works well to (only for non-DirectX applications, though). I've closed the bug, please reopen if it still doesn't work. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14073] [32bit i915]3D application 'openarena' freeze tty with Assertion `intel-batch-id == intel-last_state_batch_id' failed
http://bugs.freedesktop.org/show_bug.cgi?id=14073 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added Summary|[32bit i915]3D application |[32bit i915]3D application |'openarena' freeze tty |'openarena' freeze tty with ||Assertion `intel-batch-id ||== intel- ||last_state_batch_id' failed -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14073] [32bit i915]openarena freeze tty with Assertion `intel-batch- id == intel-last_state_batch_id' failed
http://bugs.freedesktop.org/show_bug.cgi?id=14073 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added Summary|[32bit i915]3D application |[32bit i915]openarena freeze |'openarena' freeze tty with |tty with Assertion `intel- |Assertion `intel-batch-id |batch-id == intel- |== intel- |last_state_batch_id' failed |last_state_batch_id' failed| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
