drm_bufs.h: order as an OS specific way of computation?
What would be the method for submiting a patch to to move this into
non-OS_specific code?
Here is the current diff from Linux to BSD...
-/**
- * Compute size order. Returns the exponent of the smaller power of two
which
- * is greater or equal to given number.
- *
- * \param size size.
- * \return order.
- *
- * \todo Can be made faster.
+
+/*
+ * Compute order. Can be made faster.
*/
int DRM(order)( unsigned long size )
{
int order;
unsigned long tmp;
- for (order = 0, tmp = size >> 1; tmp; tmp >>= 1, order++)
- ;
+ for ( order = 0, tmp = size ; tmp >>= 1 ; ++order );
- if (size & (size - 1))
+ if ( size & ~(1 << order) )
++order;
return order;
}
Aside from copying the doxygen it would be nice the spellout where the
name 'order' came from and what it means. Do these functions still
compute the same value and can the changes be synced?
___
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
This should fix it in general for all cards and make it into Linux
specific code. I gave it a minimal test and it works for me.
If it's working right cat /proc/iomem /proc/ioports will show the
driver as owning the resources. pci_request_regions() will fail if
called in stealth mode so it needs to be protected by !DRM(fb_loaded).
In stealth mode it's the other drivers responsibility to reserve the
resources.
Check it in if you like it.
--
Jon Smirl
[EMAIL PROTECTED]
= linux/drm_drv.h 1.14 vs edited =
--- 1.14/linux/drm_drv.h Sun Sep 5 21:22:06 2004
+++ edited/linux/drm_drv.h Thu Sep 9 21:51:54 2004
@@ -464,8 +464,10 @@
return -ENODEV;
dev = &(DRM(device)[DRM(numdevs)]);
- if (DRM(fb_loaded)==0)
+ if (DRM(fb_loaded)==0) {
pci_set_drvdata(pdev, dev);
+ pci_request_regions(pdev, DRIVER_NAME);
+ }
memset( (void *)dev, 0, sizeof(*dev) );
dev->count_lock = SPIN_LOCK_UNLOCKED;
@@ -568,6 +570,7 @@
pci_set_drvdata(pdev, NULL);
drm_cleanup(dev);
+ pci_release_regions(pdev);
}
static struct pci_driver drm_driver = {
= shared/radeon_cp.c 1.4 vs edited =
--- 1.4/shared/radeon_cp.c Wed Aug 25 16:55:14 2004
+++ edited/shared/radeon_cp.c Thu Sep 9 21:53:03 2004
@@ -1732,32 +1732,9 @@
return ret;
}
-static int radeon_register_regions(struct pci_dev *pdev) {
- int retcode = -EINVAL;
-
- /* request the mem regions */
- if (!request_mem_region (pci_resource_start( pdev, 2 ),
- pci_resource_len(pdev, 2), DRIVER_NAME)) {
- DRM_ERROR("cannot reserve MMIO region\n");
- return retcode;
- }
- if (!request_mem_region (pci_resource_start( pdev, 0 ),
- pci_resource_len(pdev, 0), DRIVER_NAME)) {
- DRM_ERROR("cannot reserve FB region\n");
- return retcode;
- }
- return 0;
-}
-
-static void radeon_release_regions(struct pci_dev *pdev) {
-release_mem_region (pci_resource_start( pdev, 2 ), pci_resource_len(pdev, 2));
-release_mem_region (pci_resource_start( pdev, 0 ), pci_resource_len(pdev, 0));
-}
-
/* Always create a map record for MMIO and FB memory, done from DRIVER_POSTINIT */
int radeon_preinit( struct drm_device *dev, unsigned long flags )
{
- int retcode = -EINVAL;
u32 save, temp;
drm_radeon_private_t *dev_priv;
@@ -1769,11 +1746,6 @@
dev->dev_private = (void *)dev_priv;
dev_priv->flags = flags;
- /* request the mem regions */
- if (!DRM(fb_loaded))
- if ((retcode = radeon_register_regions(dev->pdev)) != 0)
- return retcode;
-
/* There are signatures in BIOS and PCI-SSID for a PCI card, but they are not very reliable.
Following detection method works for all cards tested so far.
Note, checking AGP_ENABLE bit after drmAgpEnable call can also give the correct result.
@@ -1802,9 +1774,6 @@
DRM(free)( dev_priv, sizeof(*dev_priv), DRM_MEM_DRIVER );
- if (!DRM(fb_loaded))
- radeon_release_regions(dev->pdev);
-
dev->dev_private = NULL;
return 0;
}
Re: radeon-pre-2
> > request/release regions is what Linux drivers are supposed to do to > mark that they have a resource in use. There's a pci_request_region() > available that hides whether it is IO or memory so I should switch to > that one. All drivers should implement these functions. You can't do > this as part of add/initmap since they may only map subsets of the > regions. Do they have to be per-driver, or can the core work it out from the pci address space and do it itself?, if they are Linux specific they need to go in the radeon_drv.c or a linux specific file at any rate.. or do we just abstract them out for different OSes.. Dave. > > pci_read_config_dword(RADEON_AGP_COMMAND_PCI_CONFIG) is in the > category of user space code shouldn't be setting variables into the > driver for things user space has no control over. The driver should > know whether it's hardware is AGP or PCI. It shouldn't rely on a > command from user space to tell it what hardware it has. This code > should be on all platforms. > > Over time we should remove all cases in all drivers of user space code > telling the devices drivers what hardware they have. That's backwards, > the hardware drivers should be telling user space, not the other way > around. Eliminating code like this removes one of the reasons X needs > to run as root. > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Nightly doxygen documentation
José Fonseca wrote: Hi, Doxygen documentation of DRM and Mesa is generated every night from CVS into http://freedesktop.org/~dri/doxygen/ . Enjoy, Thanks, José. I added new sections for the glapi and shader modules and tweaked a few other things. Hopefully I didn't break anything. -Brian --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
Neither of these have anything to do with the addmap/initmap change. request/release regions is what Linux drivers are supposed to do to mark that they have a resource in use. There's a pci_request_region() available that hides whether it is IO or memory so I should switch to that one. All drivers should implement these functions. You can't do this as part of add/initmap since they may only map subsets of the regions. pci_read_config_dword(RADEON_AGP_COMMAND_PCI_CONFIG) is in the category of user space code shouldn't be setting variables into the driver for things user space has no control over. The driver should know whether it's hardware is AGP or PCI. It shouldn't rely on a command from user space to tell it what hardware it has. This code should be on all platforms. Over time we should remove all cases in all drivers of user space code telling the devices drivers what hardware they have. That's backwards, the hardware drivers should be telling user space, not the other way around. Eliminating code like this removes one of the reasons X needs to run as root. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
> I'm not sure why this stuff is directly called from radeon_cp.c (and only this > driver) and not from within the common code path. Isn't this also done via becase the DRM is undergoing experimental surgery at the moment, and the radeon is the crash test dummy ... I think two drivers need to be converted really, so that the commonalities become apparent this stuff is not being pushed to the kernel until all drivers use it at any rate, there are too many corner cases with it... I'm hoping to get some time to go over it all again (I've reviewed the patches as I've check them in) but I'm trying to see the big picture in terms of BSD, savage etc... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
On 09.09.2004, at 19:37, Jon Smirl wrote:
This is what I'm talking about with hotplug support and BSD not
supporting hotplug. On Linux there are rules for dealing with all of
the resources so that you don't get conflicts with new devices when
they are plugged in. It's the region code that is causing problems
right? If so, register/release regions needs to be moved into the
linux directory and another set of inlines created.
okay, it's two things that need to be abstracted into a OS-dependent
layer so that radeon_cp.c stays OS-independent:
+static int radeon_register_regions(struct pci_dev *pdev) {
+ int retcode = -EINVAL;
+
+ /* request the mem regions */
+ if (!request_mem_region (pci_resource_start( pdev, 2 ),
+ pci_resource_len(pdev, 2), DRIVER_NAME)) {
+ printk(KERN_ERR DRIVER_NAME ": cannot reserve MMIO region\n");
+ return retcode;
+ }
+ if (!request_mem_region (pci_resource_start( pdev, 0 ),
+ pci_resource_len(pdev, 0), DRIVER_NAME)) {
+ printk(KERN_ERR DRIVER_NAME ": cannot reserve FB region\n");
+ return retcode;
+ }
+ return 0;
+}
+
+static void radeon_release_regions(struct pci_dev *pdev) {
+release_mem_region (pci_resource_start( pdev, 2 ),
pci_resource_len(pdev, 2));
+release_mem_region (pci_resource_start( pdev, 0 ),
pci_resource_len(pdev, 0));
+}
I'm not sure why this stuff is directly called from radeon_cp.c (and
only this driver) and not from within the common code path. Isn't this
also done via addmap/initmap or are these maps different? Isn't this
code common to all drivers so that it can be placed directly into
drm_init?
+ pci_read_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG,
&save);
+ pci_write_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG, save
| RADEON_AGP_ENABLE);
+ pci_read_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG,
&temp);
+ if (temp & RADEON_AGP_ENABLE)
+ dev_priv->flags |= CHIP_IS_AGP;
as far as I understand that (and that's not much), you are checking
whether the card is AGP or not. RADEON_AGP_ENABLE == (1<<8) == 0x0100
is a common value, not specific to radeon cards, if I'm reading the BSD
kernel source right. shouldn't this be also done in the common driver
core (drm_init) and the result made available in drm_device_t?
implementing that stuff for BSD won't be hard, I'd just like to get
these (common?) code fragments into the appropriate OS dependent driver
core files.
thanks,
simon
--
/"\
\ /
\ ASCII Ribbon Campaign
/ \ Against HTML Mail and News
PGP.sig
Description: This is a digitally signed message part
Nightly doxygen documentation
Hi, Doxygen documentation of DRM and Mesa is generated every night from CVS into http://freedesktop.org/~dri/doxygen/ . Enjoy, José Fonseca --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
On Thu, Sep 09, 2004 at 05:03:27PM +0200, Philipp Klaus Krause wrote: > Brian Paul schrieb: > >Pasi Kärkkäinen wrote: > > > >>Hi all! > >> > >>>From the www.opengl.org: > >> > >> > >>OpenGL 2.0 specification available for download > >> > >>http://www.opengl.org/documentation/opengl_current_version.html > >>http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf > >> > >>Any plans for 2.0 support in Mesa? I think the biggest "todo" is the > >>sw-emulation of glsl? > > > > > >Yeah, implementing the shading language will be a huge project. It > >would be nice if a group of volunteers would work together to implement it. > > > >I'll probably start working on some of the infrastructure for 2.0 > >support in the near future. But the GLSL parser and code generator will > >be the bulk of the 2.0 work by far. > > > >-Brian > > > > Some modifications to Mesa are necessary: > -Change glColor3 behaviour, > -Seperate legacy and generic vertex attributes. > GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program2 > needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3 > allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program > (assuming both extensions present) there may be no attribute aliasing. > -I dont' know about GL_ARB_texture_non_power_of_two and > GL_ARB_draw_buffers. Are they supported already? > -The rest should be there. > > I planned to do some work towards shader support, but wanted to wait for > The 2.0 spec to be released to see what would change. I probably won't > find much time before mid-october or so. This is what I had in mind: > > Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader, > GL_ARB_fragment_program and GL_ARB_fragment_shader that create some > intermediate representation. > Then, at least four backends: One for SSE to get fast software > rendering on newer x86, one that interpretes for the architectures where > there is no compiling backend, one for the new intel chips and their > fragment program support and finally, one for the Wildcat VP > (I don't have docs for it though and doubt that I will ever get any, > I haven't asked Intel about i915 yet). > > So get get something running I would first craete the > GL_ARB_vertex_program frontend. Then the interpreting backend. If it's > at least as fast as the solution we have now, we can already put it in > Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend. > Hmm.. is it possible to use the frontend compiler which is available from 3dlabs website? Or does it help anything.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
This is what I'm talking about with hotplug support and BSD not supporting hotplug. On Linux there are rules for dealing with all of the resources so that you don't get conflicts with new devices when they are plugged in. It's the region code that is causing problems right? If so, register/release regions needs to be moved into the linux directory and another set of inlines created. On Thu, 9 Sep 2004 17:14:04 +0200, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > Hey, > > as I'm slowly ploughing through the last changes to get BSD support > working again... the radeon-pre-2 patch added linux-only code to > radeon_cp.h, somehow to establish permanent mappings for framebuffer > and mmio, as it seems. > > this is not good. is there an OS independent way to do this? maybe by > the new initmap() stuff? Am I able to still use the radeon driver with > this stuff #ifdef'd out? > > thanks, >simon > > -- > /"\ > \ / > \ ASCII Ribbon Campaign > / \ Against HTML Mail and News > > > > -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
Philipp Klaus Krause wrote: Brian Paul schrieb: Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest "todo" is the sw-emulation of glsl? Yeah, implementing the shading language will be a huge project. It would be nice if a group of volunteers would work together to implement it. I'll probably start working on some of the infrastructure for 2.0 support in the near future. But the GLSL parser and code generator will be the bulk of the 2.0 work by far. -Brian Some modifications to Mesa are necessary: -Change glColor3 behaviour, -Seperate legacy and generic vertex attributes. GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program2 needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3 allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program (assuming both extensions present) there may be no attribute aliasing. -I dont' know about GL_ARB_texture_non_power_of_two and GL_ARB_draw_buffers. Are they supported already? -The rest should be there. Right. That's some of the stuff I was planning on doing. I planned to do some work towards shader support, but wanted to wait for The 2.0 spec to be released to see what would change. I probably won't find much time before mid-october or so. This is what I had in mind: Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader, GL_ARB_fragment_program and GL_ARB_fragment_shader that create some intermediate representation. Well, I'd consider the current internal representation of vertex/fragment programs to act as an intermediate representation that can be translated into hardware/SSE/etc forms. That's what Keith did in the i915 driver. Then, at least four backends: One for SSE to get fast software rendering on newer x86, one that interpretes for the architectures where there is no compiling backend, one for the new intel chips and their fragment program support and finally, one for the Wildcat VP (I don't have docs for it though and doubt that I will ever get any, I haven't asked Intel about i915 yet). So get get something running I would first craete the GL_ARB_vertex_program frontend. Then the interpreting backend. If it's at least as fast as the solution we have now, we can already put it in Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend. Then we can take the new concept to the fragment shader side, where it should be rather easy to get GL_ARB_fragment_program and GL_ARB_fragment_shader support and get the interpreted and SSE backends running. Next would be the i915 backend, since the driver already supports fragment programs and it shouldn't be left behind. Then when someone uses the fragment shader on let's say the i915 this will happen: If the i915 compiler says it can't handle the program (due to lack of hardware support for some advanced functionality) the SSE backend with software rendeirng will be used if it's on x86. Otherwise the generic, interpreting backend will be used. This generally sounds good. Before anyone starts tearing up the current code, I'd like to see a good plan first. I'd like to at least rename and reorganize some of the sources for vertex/fragment programs before anything else. -Brian --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon-pre-2
Hey, as I'm slowly ploughing through the last changes to get BSD support working again... the radeon-pre-2 patch added linux-only code to radeon_cp.h, somehow to establish permanent mappings for framebuffer and mmio, as it seems. this is not good. is there an OS independent way to do this? maybe by the new initmap() stuff? Am I able to still use the radeon driver with this stuff #ifdef'd out? thanks, simon -- /"\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News PGP.sig Description: This is a digitally signed message part
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
Brian Paul schrieb: Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest "todo" is the sw-emulation of glsl? Yeah, implementing the shading language will be a huge project. It would be nice if a group of volunteers would work together to implement it. I'll probably start working on some of the infrastructure for 2.0 support in the near future. But the GLSL parser and code generator will be the bulk of the 2.0 work by far. -Brian Some modifications to Mesa are necessary: -Change glColor3 behaviour, -Seperate legacy and generic vertex attributes. GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program2 needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3 allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program (assuming both extensions present) there may be no attribute aliasing. -I dont' know about GL_ARB_texture_non_power_of_two and GL_ARB_draw_buffers. Are they supported already? -The rest should be there. I planned to do some work towards shader support, but wanted to wait for The 2.0 spec to be released to see what would change. I probably won't find much time before mid-october or so. This is what I had in mind: Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader, GL_ARB_fragment_program and GL_ARB_fragment_shader that create some intermediate representation. Then, at least four backends: One for SSE to get fast software rendering on newer x86, one that interpretes for the architectures where there is no compiling backend, one for the new intel chips and their fragment program support and finally, one for the Wildcat VP (I don't have docs for it though and doubt that I will ever get any, I haven't asked Intel about i915 yet). So get get something running I would first craete the GL_ARB_vertex_program frontend. Then the interpreting backend. If it's at least as fast as the solution we have now, we can already put it in Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend. Then we can take the new concept to the fragment shader side, where it should be rather easy to get GL_ARB_fragment_program and GL_ARB_fragment_shader support and get the interpreted and SSE backends running. Next would be the i915 backend, since the driver already supports fragment programs and it shouldn't be left behind. Then when someone uses the fragment shader on let's say the i915 this will happen: If the i915 compiler says it can't handle the program (due to lack of hardware support for some advanced functionality) the SSE backend with software rendeirng will be used if it's on x86. Otherwise the generic, interpreting backend will be used. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: initmap code
On 09.09.2004, at 15:02, Alan Cox wrote: So, what happens in x86-64 where sizeof(unsigned long) is 4 bytes for IA-32 apps and 8 bytes for x86-64 apps? I guess since it's a parameter to the ioctl (rather than embedded in a structure) it should be okay, but I just want to be sure... Be cautious here - a bus address is 64bits on some builds of x86-32 kernels. Only virtual addresses are 32bit limited. Also don't forget that you run 32bit apps on 64bit platforms. Linux uses __u32/__u64/__s32/__s64 to be specific about such types and to make it easier to build ioctls that don't need magic translation glue hm. this would mean to bite the bullet, break the ABI to use uint64_t instead? I don't see any easy solution there. -- /"\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News PGP.sig Description: This is a digitally signed message part
Re: OpenGL 2.0 specification available for download
Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest "todo" is the sw-emulation of glsl? Yeah, implementing the shading language will be a huge project. It would be nice if a group of volunteers would work together to implement it. I'll probably start working on some of the infrastructure for 2.0 support in the near future. But the GLSL parser and code generator will be the bulk of the 2.0 work by far. -Brian --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: initmap code
On Iau, 2004-09-09 at 00:45, Ian Romanick wrote: > So, what happens in x86-64 where sizeof(unsigned long) is 4 bytes for > IA-32 apps and 8 bytes for x86-64 apps? I guess since it's a parameter > to the ioctl (rather than embedded in a structure) it should be okay, > but I just want to be sure... Be cautious here - a bus address is 64bits on some builds of x86-32 kernels. Only virtual addresses are 32bit limited. Also don't forget that you run 32bit apps on 64bit platforms. Linux uses __u32/__u64/__s32/__s64 to be specific about such types and to make it easier to build ioctls that don't need magic translation glue --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[R200] Lockups after few time in America's Army
Hi all, I'm using a 3D prophet Radeon 8500LE and the lastest DRI drivers from CVS + S3TC patch . I've noticed that I can't play to ArmyOps , because after few time I've started the game the game image simply freeze . I can hear the sound of the game, but I can't do anything. CTRL + ALT + BACKSPACE doesn't work , CTRL + ALT + CANC neither , the system is locked up . I've already tried with AGP 4x and 1x , with and without PageFlip , but no luck. Here is my driver version: Bye Marcello [EMAIL PROTECTED]:~$ glxinfo name of display: :0.0 Mesa: software DXTn compression/decompression available display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20040906 AGP 1x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.2 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_S3_s3tc glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r
OpenGL 2.0 specification available for download
Hi all! >From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest "todo" is the sw-emulation of glsl? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
